Iterating on block styles to make themes easier

[karmatosed]

This is an issue I wanted to create for discussion that I caught on Twitter. If we can loop in or close this for any specific issues, let's do that.

One thing that seems to be a common thread is how overriding block styles isn't the easiest it could be. Now, this in part is documentation, but it's also something to iterate on. It also can help the components themselves to be easier to work with if easier to manipulate. It feels like a powerful seed planted but one we're not yet seeing as a full flower.

In viewing a recent thread the following points came up:

• It's complicated and messy to override the editor styles for themes.
• There are a lot of nested containers in the editor for a block.
• There is still too much or too little opinionated styling in places (it varies).

With regards to nesting, finding where you are is a key point. Now that's being explored with the new navigator and also ids being surfaced. I wonder what else could be done?

• Those of you that make themes what would you love to see as features?
• What is missing right now?
• What issues can we link into this discussion to work on together?

[allancole]

• It's complicated and messy to override the editor styles for themes.
• There are a lot of nested containers in the editor for a block.
• There is still too much or too little opinionated styling in places (it varies).

I’ve found that customizing editor styles is really tough because the editor is a blend of both frontend HTML and the editor’s own UI markup. When you replace or override the core editor styles you’re constantly having to readjust your CSS to adapt to changes in core which is tedious to maintain block-by-block over time. In the past, themes could simply revise markup whenever it was necessary and then write CSS for that theme-specific markup. But with Blocks we don’t really have that same control. This feels like a restriction at first but it’s actually quite the opposite.

For me, it’s been much easier to work with the default styles in core where you exclusively override the parts of the default block styles that speak to the aesthetics of your theme’s design. This means you really only need to override the “opinionated” styles that relate to font-family, font-size, or text-color and background-color, etc. All other styles related to a Block’s behavior or layout still come from core which means a Block’s behavior will stay the same across themes leaving only the fonts, colors, etc to be influenced by the theme. This approach means your selectors don’t need to be as deep or complex, making it easier to maintain as Gutenberg grows and changes.

In my opinion, if you’re finding yourself in the editor digging into all the deeply nested wrappers to figure out how to make a block do something different than it already does, you might be creating problems for yourself later. If you’re looking to change the default appearance/behavior of any block, creating a theme-specific Block Style is much more appropriate and you get the added control over styles and some markup at the same time. In Gutenberg 6.5 you can even set the theme’s custom Block Style as the default to save time for users.

• Those of you that make themes what would you love to see as features?
• What is missing right now?

For me, I see themes evolving into something that requires far less code and configuration which would benefit both theme designers and end users. I like the idea of the editor becoming a new creative space with a “design mode” as described by @mtias in this post.

But before we get there, I think the idea of “Global Styles” is probably the best starting point toward that future. With Global styles, Themes would be able to predefine a set of fonts, colors and general design rules that influence how a block appears but doesn’t change its behavior which comes from core. Combine that with a Theme “Template” (meaning a configuration of Blocks that look like a full web page in the editor) and you end up with something where the majority of the theme work doesn’t necessarily require theme template tags or any hand-written CSS at all. This is admittedly a bit radical as it would be a totally different kind of work than what we’re used to with themes up to this points. But with Gutenberg, the customization and configuration benefits to users could make it all worth it, especially when you consider how much less maintenance this approach requires compared to now.

[youknowriad]

Do you think it's possible to add a README/guidelines/example of a custom style per block and surface these in the handbook? It's probably not the ultimate solution but something that can help theme authors get 90% of the work done quickly while we figure out ways to improve the system.

[youknowriad]

I'm going to close this as duplicate of #19611 and #9534 as they address the same issue.