Custom Gutenberg editor styles break the Dashboard

[pyronaur]

The classic editor was rendered in an iframe, which meant that theme developers could easily do this:

add_editor_style( get_template_directory_uri() . '/style.css' );

Something similar can now be done with the enqueue_block_editor_assets hook:

add_action( 'enqueue_block_editor_assets', 'custom_enqueue_function' );

However, because there is no longer an iframe - the styles are applied globally, so applying the main theme stylesheet is going to break the dashboard.

Does this mean that theme developers will have to write and maintain an entirely separate stylesheet just for the editor?

[youknowriad]

Does this mean that theme developers will have to write and maintain an entirely separate stylesheet just for the editor?

I don't think so, I expect theme developers to extract the "blocks" and "common typography" styles to a dedicated stylesheet loaded both in the editor and in the frontend. So it's just a matter of reorganization, not adding something new.

[pyronaur]

In the past, the clean way to do this would be to do exactly what you said - extract a few styles and font sizes out of your stylesheet, use add_editor_style(). The editor would look just a bit more like the website. I don't think that's going to be sufficient for Gutenberg though.

Gutenberg-view currently is still very different from what you get on your site. I want to narrow that gap, at the same time I don't wan't to do the work twice.

Loading an extra stylesheet on the front-end just because of Gutenberg doesn't seem like a solid solution to me.
Besides - how would a stylesheet compatible both in dashboard and the front-end look like? For example the font families of body and headings?

A band-aid solution I can come up with is to have 2 top-level pre-processor stylesheets: style.scss and gutenberg.scss. Then write styles in subdirectories, and use the 2 scss files to import necessary styles the frontend and backend separately. But that gets complicated because if I import too specific styles in gutenberg.scss it might affect the overall dashboard design. On the other hand - not specific enough and I can't change the heading size ( for example with .editor-block-list__block[data-type="core/heading"] h2 )

I can't wait for the twentyeighteen (or is it twentyninteen?) theme development to start. This is going to be an interesting issue for me to track.

[karmatosed]

You can do the following in Gutenberg:

function gutenbergtheme_editor_styles() { wp_enqueue_style( 'gutenbergthemeblocks-style', get_template_directory_uri() . '/blocks.css'); }

add_action( 'enqueue_block_editor_assets', 'gutenbergtheme_editor_styles' );

Closing as this isn't broken, you can do that above and get styles in the editor.

[pyronaur]

Hey @karmatosed - notice that in my first post I said I can do something similar with enqueue_block_editor_assets - I am aware of that hook existing.

Please reopen the ticket, as the issue I'm talking about is theme styles are bleeding into the dashboard styles and not "how to enqueue" theme styles.

At the moment, it is very hard for a theme developer to achieve WYSIWYG with Gutenberg, and I really hope that changes until WordPress 5.0 is released, because WYIWYG is what Gutenberg is all about, isn't it?

[karmatosed]

I absolutely am ok opening it, I will admit it read as though you weren't doing the same as had issues I was not experience in testing, but totally let's dig in more. That's the awesome thing with tickets, we can reopen :)

I am not seeing my own editor styles bleeding, so can you perhaps link fully what styles you are doing and we can see. Maybe you have a sneaky one we need to tie down.

[samikeijonen]

@justnorris Those are all very good points and I've been mentally trying to figure out the best current approach for writing CSS.

For existing themes it's going to be a little bit different and harder so I personally start from a new theme. Let's share the ideas how to optimaze CSS workflow for editor and front-end. I don't have anything concrete before I actually start building something.

[richtabor]

👋. I have a few thoughts to chime in from my experience applying theme styles to Gutenberg recently.

The issue stems from improper editor styles that wouldn't necessarily cause a problem within the pre-Gutenberg visual editor (as they're contained), but will in Gutenberg.

For example, quite a few WordPress themes (mostly commercial) are importing entire stylesheets into the current visual editor, which is obviously not a good practice. When developers start add theme styles to Gutenberg using the enqueue_block_editor_assets action, they'll likely end up bonking the whole dashboard, like this:

Instead of having a full-fledged theme-styled Gutenberg editor as seen in the screenshot below:

I personally started writing an entirely separate stylesheet for Gutenberg (apart from editor-styles.css), targeting elements/block/content within the .editor-visual-editor class.

Is this something that's up left entirely up to developers do to right? Should there be some catches to prevent this sort of behavior? Do you think a lot of developers will just opt-out of styling Gutenberg because of the issues?

[pyronaur]

Do you think a lot of developers will just opt-out of styling Gutenberg because of the issues?

This is exactly the reason I'm bringing this up. I'm excited that Gutenberg is going to bring an almost WYSIWYG editor in core WordPress. But for a WYSIWYG experience we need theme developers to style for Gutenberg. I think that most developers are not going to write a separate Gutenberg stylesheet if it's not easy enough.

By the way, is there somewhere a discussion already on the various elements and how to style them? For example, Gutenberg buttons, quotes ?

[mtias]

@justnorris great points, I agree completely. The process for themes would be:

• Style blocks (ideally in a separate stylesheet).
• Editor loads block styles.

We need to make sure the process of styling blocks is easy and polished. Once we agree on that, making it available for the editor is trivial.

We are going to need some additional ways to style other pieces of the editor (main column width, bg, etc) that is not directly (as of this moment) block related. It might be in the future with full-on customization (a Post block, etc). So we need to take those into account as well.

The biggest challenge there is how to style the container easily without having to know too many classes, or dealing with wp-admin cascade. We cannot use an iframe, but we might be able to employ Shadow DOM for it.

[mtias]

Related: #5360

[mtias]

Several improvements to this flow have been made, notably #9008.

A larger umbrella issue to coordinate things and lead into phase 2 lives at #9534