backward compatibility for add_editor_style()

[joyously]

Problem: thousands of existing themes call add_editor_style()
The current method of supplying styles to the editor is easy and used by thousands of themes. One call to add_editor_style() is all that is needed to make the editor look similar to the front end. Styles for fonts, colors, padding, etc. for HTML elements are the basis for what the theme provides, with the user choosing a lot of those in the Customizer.

Solution
For backward compatibility, the new editor should continue to load styles using add_editor_style().

considerations
Discussions on #4001 indicate that there could be a problem using existing styles because of styles bleeding into the rest of the page, because the old editor loads in an iframe.
Much talk on #5360, but only from the viewpoint of new themes, not old themes.

The consensus in Theme Review is that themes should not create blocks. But they still need to style the page, including in the editor.
@danielbachhuber

[danielbachhuber]

Thanks @joyously. I'm not sure whether we'll be able to immediately act upon this issue, but it's good to have it open for visibility.

[mtias]

We won't be loading add_editor_styles from older themes as the expectations are vastly different, and the content is not within the boundaries of an iframe. A theme can load a style on the editor but it has to be a deliberate action as they need to target new elements in different ways.

In general, the way of styling the editor is going to be phased out in favor of styling blocks (through mechanisms like block variants).

[mtias]

Closing this for now.

[danielbachhuber]

I'd like to make sure this is documented appropriately.

[joyously]

In general, the way of styling the editor is going to be phased out in favor of styling blocks (through mechanisms like block variants).

I think it's a mistake to view the theme styles this way. Themes should not be supplying blocks, and so their styles need to be fairly generic. It makes sense for core blocks to have standard classes similar to alignleft, alignright that the theme would style. Additionally, the theme would be styling the general case of HTML tags and fonts and colors that should make the editor look like the front end looks.
This should still be done with add_editor_style().
This has nothing to do with blocks, and if you can't see that you might be too close to the project.

[danielbachhuber]

I've documented this in my Gutenberg migration guide https://github.com/danielbachhuber/gutenberg-migration-guide/blob/master/feature-editor-stylesheets.md

Additionally, the theme would be styling the general case of HTML tags and fonts and colors that should make the editor look like the front end looks.
This should still be done with add_editor_style().

For reasons mentioned before, the theme developer would need to first verify their existing editor stylesheet doesn't break Gutenberg. Once they've done so, if they choose to continue to use a global editor stylesheet, they can enqueue it on the enqueue_block_editor_assets action.

function wpdocs_theme_add_editor_styles() {
	wp_enqueue_style( 'my-editor-stylesheet', get_stylesheet_directory_uri() . '/editor-style.css' );
}
add_action( 'enqueue_block_editor_assets', 'wpdocs_theme_add_editor_styles' );

[joyously]

the theme developer would need to first verify their existing editor stylesheet doesn't break Gutenberg

How is that backward compatible? The new editor should make sure that a theme's styles do not affect the admin page adversely, not the other way around. I'm referring to thousands of existing themes that might be supplying fonts or colors for the editor page. They shouldn't all have to change just because you guys decided to not use an iframe.