Incorporate outside styles sooner rather than later

[joyously]

In the discussion for what to include on #356 (Allow editing actual posts and pages), it seems that only half of the editing experience is being addressed. The actual post content is needed to have something to edit, but the context of presentation of that content is missing.

The current WP editor allows the presentation of the Visual mode to be adjusted using additional stylesheets. Themes can add this using add_editor_style(), which by default is named editor-style.css.

I expect that capability still needs to exist in the new editor, and allowing for it at the beginning will keep clear what styling belongs in the editor and what is left to the theme, and how they might interact.

I suggest that the minimum of styling would be a content font and background color so transitions between blocks are easy to spot. Then the WordPress standard classes similar to as defined on https://codex.wordpress.org/CSS would show how the edits are applied as classes. I know it's early to expect that whole flow to work, but I think it's important to start with it in order to keep the goal in mind. You also won't be able to control what styles are fed in, so if a theme uses a generic selector like div, will that break your look?

[nylen]

It would probably be good to do this as a separate stylesheet (gutenberg-style.css), at least at first so that we can learn more about the necessary differences between classic editor-style.css and the equivalent for the new editor.

Further reference:

• https://codex.wordpress.org/Editor_Style
• https://developer.wordpress.org/reference/functions/add_editor_style/

[ellatrix]

I'm still not sure if adding editor styles to WP core was a good idea. @azaozz may have thoughts on this too.

[BE-Webdesign]

That is a great point. I have made lots of use of editor styles in my themes, but with where Gutenberg is going, it is pretty easy to render the editor in the front end of the theme and just use it that way. So potentially editor styles won't really be necessary.

[joyously]

it is pretty easy to render the editor in the front end of the theme and just use it that way.

This makes no sense to me. Isn't the editor a page in the admin, regardless of the theme perhaps rendering it somewhere else? And the goal is to make the Visual mode look like the front end will look? If this will just be an iframe like the Preview is now, I understand that the theme is doing all the styling. But if not, isn't the theme going to need to put dynamic styling in so the Visual mode looks like it will on the front end?

[BE-Webdesign]

Isn't the editor a page in the admin, regardless of the theme perhaps rendering it somewhere else?

To me the editor is wp.editor. It is currently rendered in an admin page for this plugin.

And the goal is to make the Visual mode look like the front end will look?

Maybe, I think the goal is to provide an easier way to edit for those who do not know HTML. I do agree that editor styles currently are very useful, but maybe there is room here to make maintenance of the WordPress project easier by not introducing them for the new editor, and instead provide an even better experience by having live editing in the theme, which could be introduced in a separate plugin.

But if not, isn't the theme going to need to put dynamic styling in so the Visual mode looks like it will on the front end?

It's currently possible to do this right now, if you really wanted to. I don't think the main goal of Visual mode is to match the front end, it simply provides an easy to use editor instead of working with HTML directly. Rather than rushing to adding editor-styles 2.0 we could explore better alternative solutions.

[jasmussen]

One "problem" with editor styles, which we probably don't want to tackle with this focus, is that it's a separate stylesheet for theme authors to create and maintain. Just philosophically it would be nice if a theme author did not have to create a separate style, but that the editor could infer the styles from the main style.css file automatically.

[joyously]

With the theme supplying styles for the Customizer, the theme usually has a function that emits the dynamic styles, so at least that part could be "registered" with the editor. However, the selectors might not be quite right, which is why the editor-style is separate in the first place.
And again, I think the theme has more to consider in terms of layout and screen size than the editor should be concerned with.

[nylen]

Quoting from a Slack conversation with @aduth

there’s been some chatter about how themes could define support for blocks or block controls (like image full bleed). maybe something with that and add_theme_supports ?

seems we might need to allow a base stylesheet for a block, plus editor and/or front-end specific extras

So, this likely means that more blocks will need to register themselves on the server side, and we'll need to allow the register_block function to accept values for these stylesheets.

Edit: also worth considering: themes themselves will probably want to add styles for individual blocks.