add_theme_support( 'editor-styles' ); doesn’t work with styles added via enqueue_block_editor_assets

[florianbrinkmann]

Describe the bug

I tried to use the new editor styles feature and followed the steps in the Handbook (https://wordpress.org/gutenberg/handbook/extensibility/theme-support/#editor-styles). I thought that using

function mytheme_block_editor_styles() {
    wp_enqueue_style(
		'slug-block-editor-styles',
		get_theme_file_uri( 'assets/dist/css/editor.css' ),
		false
	);
}

add_action( 'enqueue_block_editor_assets', 'mytheme_block_editor_styles' );

and calling the add_theme_support( 'editor-styles' ); would enable it for the file added in the mytheme_block_editor_styles function, but I get it only working via add_editor_style( 'assets/dist/css/editor.css' );. Is this the wanted behavior? If not, am I doing something wrong?

To Reproduce
Steps to reproduce the behavior:

1. Add a stylesheet via wp_enqueue_style() in a function hooked to the enqueue_block_editor_assets.
2. Add add_theme_support( 'editor-styles' );.
3. Insert .wp-block { width: 1250px; } into the stylesheet.
4. Open Gutenberg and notice that the width of the editor is not 1250 Pixels but the default width.

Expected behavior

The new behavior from #9008 should be applied to styles added via enqueue_block_editor_assets if add_theme_support( 'editor-styles' ); is set.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Firefox
• Version 64.0a1 (2018-09-11) (64-Bit)

Additional context

• Gutenberg 3.8.0.

[Netzberufler]

I also tested it today and it was a bit confusing at first. But I think it is the wanted behaviour.

A theme developer might still want to add CSS code to the editor without auto-injecting namespaces, for example some styling for metaboxes or sidebar plugins which are outside of the content area.

I ended up with two stylesheets for now, one loaded with enqueue_block_editor_assets and the second one with add_editor_style(), because there were some things I couldn't do within the editor-style.css.

[florianbrinkmann]

Ah, good point, that could be right.

[fklein-lu]

I ended up with two stylesheets for now, one loaded with enqueue_block_editor_assets and the second one with add_editor_style(), because there were some things I couldn't do within the editor-style.css.

That's how I set it up too. All the CSS that gets passed in via add_editor_style() gets transformed. But I still needed some untransformed CSS to fine tune the initial styles, so I use a second stylesheet for that.

So I don't think it makes sense to auto-transform all CSS. It's two different use cases.

[justintadlock]

So that we're clear and I'm not misunderstanding, it requires two separate add_theme_support() calls to make this work:

add_theme_support( 'editor-styles' );

add_editor_style( 'path/to/editor.css' );

add_editor_style() is a wrapper for add_theme_support().

add_editor_style() also loads up CSS for the old, non-Gutenberg editor. I'd think any theme authors wanting to support that would use an entirely different stylesheet since there's nothing in the two that's seems to be remotely the same other than the base HTML elements.

Plus, any theme author utilizing this method would now have their block assets set up in two different places: once on the after_setup_theme hook and once on enqueue_block_editor_assets. Of course, there's no getting around this if going with a theme-support solution.

This implementation seems overly complex for something that was supposed to make things easier on theme authors.

One call to add_theme_support() or a new function like add_block_editor_style() should suffice.

[pshemek]

Also, I'm not sure, how to address things like editor width in CSS today as styles added via add_editor_style() are transformed while styles added via enqueue_block_editor_assets() are overriden by inline styles. Oh, wait: !important ;)

Reported but closed: #9894

[onetrev]

I have the same issue @florianbrinkmann, but what I discovered is it is "working" technically but styles are being overwritten now, whereas they didn't use to be. So you have to add !important now to make those max-width's work that the Gutenberg docs you referenced mention.

[weavertheme]

I'm working on this.
I think the solution is what twenty-nineteen seems to be doing - mix the tinymce and block-editor styles in one file that will get inline-loaded with the editors.

I also believe (not 100% tested yet...) that it is possible to prefix block-editor specific rules with .block-editor and tinymce specific rules with .mce-content-body (which will then be also used for Classic blocks in Gutenberg to maintain "classic" styling).

So, in theory, it should be possible to maintain a single editor style file. And you can add several editor style files at a time with something like (taken from new twenty-thirteen):
add_editor_style( array( 'css/editor-style.css', 'genericons/genericons.css', twentythirteen_fonts_url() ) );

And I also think it is probably time to add all the theme specific block styles into the standard style.css file. Really minimize number of style files.

[onetrev]

Good news on this to @justintadlock and others... Gutenberg 4.2 will include, I believe, this pull requests which means we can simplify theme dev and maintain a single file and one function call to just add_theme_support( 'editor-styles' ).

Also, @weavertheme I think this is what Twenty Nineteen is now doing, so ya you're on the right track I think to follow what it's doing.

[chrisvanpatten]

@onetrev even with that PR you will still need to call add_editor_style and add_theme_support as two separate function calls.

[youknowriad]

Yes, the two function calls are needed. With 4.2, you should be able to style everything using this technique and avoid enqueuing your own styles into the editor.

I'm closing this issue for now as nothing actionable.