Proposal: Use cascade layers for all Gutenberg generated CSS

[krokodok]

As a third party developer, I often find myself in situations where I have to write overly specific selectors to overwrite Gutenberg generated CSS. For example:

/* CSS from Gutenberg */
body .is-layout-constrained > * + * {
    margin-block-start: var(--wp--preset--spacing--vertical);
    margin-block-end: 0;
}

/* My CSS */
body .is-layout-constrained > .my-custom-element {
    margin: 0;
}

If all CSS generated by Gutenberg would be wrapped inside the new CSS concept of cascade layers, life would be much easier for me and my colleagues. For example:

@layer gutenberg, custom;

/* CSS from Gutenberg */
@layer gutenberg {
    body .is-layout-constrained > * + * {
        margin-block-start: var(--wp--preset--spacing--vertical);
        margin-block-end: 0;
    }
}

/* My CSS */
@layer custom {
    .my-custom-element {
        margin: 0;
    }
}

Cascade layers are a new technology that are supported since Chromium 99 and FireFox 97. In May 2023 it is supported by most modern browsers. The global usage is 90.19%.

---

Summary of previous discussions

This is not a new proposal, but rather the opportunity to have a discussion that was lead in multiple sub-discussions earlier on different topics. See:

• https://github.com/WordPress/gutenberg/issues?q=is%3Aissue+%22cascade+layers%22
• Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability #38998
• Style engine: functionality and design #42028
• [WIP] Style engine: register styles for enqueuing and rendering #41424

Source: #19611 (comment)

It is also worth noting that this feature was planned as "Phase 3" of an initiative to improve block editor styles launched last summer:

• https://make.wordpress.org/core/2022/06/24/block-editor-styles-initiatives-and-goals/

Pros

• Help to reduce overly specific CSS selectors.
• Make third-party development much easier.
• Help to have a nicer, cleaner CSS structure also within Gutenberg/Wordpress.
• Make Gutenberg less intimidating for developers and users, thus lowering the barriers and reservations against it.

Cons

• Cascade layers are not widely supported enough. But bear in mind that the last time those discussions were held was roughly a year ago. Support is way better now.
• There still needs to be a fallback for browsers that don't support cascade layers. All layered CSS will be unreachable for them.
• All un-layered CSS overwrites all layered CSS. There needs to be a way to control this or unforeseen theme & plugin interactions could overthrow the whole styling system.

Ideas

• There should be a way to check if the current client's browser supports cascade layers. Only then they should be applied. Otherwise a fallback CSS without layers should be used.
• Developers should have to opt-in to using CSS layers on their own responsibilities. Only then they want to benefit from using them and they make it their duty to ensure all used third-party plugins work correctly in this environment.

---

I feel this issue should not be a discussion on "if" to use this feature at all, but rather a "how and when". One year ago, this discussion was rather speculative. But now technology has changed, block editor styles advanced and many issues from back then are closed. We should prepare for "phase 3"! 🚀

[getdave]

@MaggieCabrera @scruffian I wonder if you have any opinions on this given your experience with Themes? Is there anywhere else we could surface this for further discussion or more input?

[mrwweb]

I feel this issue should not be a discussion on "if" to use this feature at all, but rather a "how and when".

I think that's a great approach.

unforeseen theme & plugin interactions could overthrow the whole styling system

Plugins are my biggest concern and question when it comes to using cascade layers. In many ways, I feel like cascade layers would be most useful for helping manage plugin styles. While it would require some experimentation, I could easily imagine wanting to load plugin styles in the lowest layer of the cascade (e.g. @layer plugins, gutenberg, custom;

When writing custom themes, customizing plugin styles is an important task and often one of the bigger challenges of a project. Unfortunately, to the best of my knowledge, there's no easy web platform way to declare that a stylesheet's styles belong to a layer when loading styles with a link element. If WordPress could provide a way to force enqueued stylesheets into a layer, that could be pretty amazing.

[fellyph]

That is really cool, I have mentioned it at WordCamp Europe. I think we should consider add the CSS from site Editor on the list, now it uses a lot of !important Layers will be a good way to avoid it:

(e.g. @layer core, themes, plugins, site-editor, custom)

I don't know when you mean Gutenberg are you including site-editor?

[krokodok]

I saw your talk. :) Of course, site-editor should be using layers as well. As stated earlier: Because unlayered CSS always beats layered CSS, for the whole idea to work every CSS has to be layered.

Unfortunately, to the best of my knowledge, there's no easy web platform way to declare that a stylesheet's styles belong to a layer when loading styles with a link element. If WordPress could provide a way to force enqueued stylesheets into a layer, that could be pretty amazing.

This would be a great step forward. Apparently there is also a discussion about this need: w3c/csswg-drafts#5853

[jasmussen]

It's nice to see CSS evolve, and it's wonderful when the block editor can adopt these technologies to improve the software.

When we do adopt new tech it's important we either do so in a progressively enhancing way, where it adds to modern browsers without fundamentally breaking older browsers. This is not always clear and cut, for example we've used the where selector to reduce specificity in a few places, and while that works for many of the stylistic contexts, it was briefly used to add drop-down menu functionality to the navigation block which broke pretty important functionality for basic navigation in older browsers, so we had to revert that.

In the case of cascade layers, it seems likely that it is the right solution long term. But due to the broad spectrum for where it's meant to be applied, it seems important to apply this only when we have some confidence that the browser support is broad enough.

When we do that, it's also important to map it to the existing hierarchy of layers we have. The "How", to Mark's point.

[cbirdsong]

Unfortunately, to the best of my knowledge, there's no easy web platform way to declare that a stylesheet's styles belong to a layer when loading styles with a link element. If WordPress could provide a way to force enqueued stylesheets into a layer, that could be pretty amazing.

Hypothetically, Wordpress could switch from generating link tags to generating <style> tags containing a bunch of @imports?

<style id="wp-css">
@layer core, plugin, theme, user; /* or whatever these would be */

@import '/wp-content/plugins/gutenberg/build/block-library/style.css' layer(core);

@media screen {
  @import '/wp-content/themes/theme/style.css' layer(theme);
}
/* etc, etc */
</style>

Reiterating that this needs to be carefully implemented as progressive enhancement with fallback scenarios accounted for and the ability for a site to opt out. Even if worldwide browser support for cascade layers is greatly improved by the time it is ready there will still be sites that need to be conservative about dropping support for older browsers.

[krokodok]

Might be interesting: #49915

[ddryo]

I strongly agree with the introduction of @layer(cascading layers).

Every theme developer I am familiar with is forced to adjust CSS every time there is a major WordPress update.

This is because the CSS Specificity that the core is loading (or outputting) changes.

Every time we have to go through every block and check the display, and every time we have to adjust some CSS Specificity.

It would be easier to introduce @layer at some point and make a major adjustment than to continue this kind of barren work forever.

[ddryo]

Looking at the status of browser support, I understand that it is still too early to implement this.

Therefore, I think it would be very good if there is a mechanism to choose whether or not to load styles with @layer.

[eric-michel]

I would love to see this implemented really soon with an option to opt-in early. Our work tends to be in a place where >90% browser compatibility means a green light for feature use, so we're already using layers for our CSS reset. Our biggest pain point with WP right now is CSS specificity change during WP major release updates and this would massively alleviate that issue.

[kkalvaa]

[…] now it uses a lot of !important Layers will be a good way to avoid it:

(e.g. @layer core, themes, plugins, site-editor, custom)

The problem with putting !important earlier in the layers is that you can’t override them later. !important works the other way where an !important in an earlier layer overrides an !important in a later layer. That means if you put any !important in any early layer it cannot be overriden in a later layer, unless you inline !important.

I support the issue though, it would be a lot easier to override styles if WordPress adopted css cascade layers, but then there should be an effort to remove !important statements from the WordPress css.

[CookiesForDevo]

Worth noting that Tailwind is adopting native cascade layers in 4.0, scheduled to be released later this year.

Would be ideal to have WordPress support it (even as an opt-in) for those of us building themes with tools that have implemented cascade layers to avoid (more) specificity headaches.