Cascade Layers

[jensimmons]

Description
Cascade Layers provides a powerful way to architect CSS code into “layers”, where the specificity of each layer is calculated independently of other layers — and where the web developer can define which layer will override which.

Specification
Cascade 5

Tests
Current tests

Rationale
Web developers often complain about CSS as a whole, especially about the CSS cascade. They increasingly inline all their CSS via JS, or use a framework of flat classes to style everything. Developers avoid using ID or element selectors, argue about !important, and basically try to avoid the CSS Cascade altogether. Cascade layers is recent effort by the CSSWG to fix these pain points for web developers by giving developers more powerful tools to handle complex modern websites. The idea is to lean into a more powerful cascade, instead of avoiding it.

Cascade Layers allows developers to create separate “layers” in their cascade — where everything in one layer will “beat” everything in another layer, no matter what the specificity of the code inside each layer. It builds on the way CSS Origins have always worked (where UA styles, User styles, and Author styles have all lived in separate origins – or layers — where specificity is calculated separately).

From the Cascade 5 Specification where Layers is defined:

Authors can create layers to represent element defaults, third-party libraries, themes, components, overrides, and other styling concerns—and are able to re-order the cascade of layers in an explicit way, without altering selectors or specificity within each layer, or relying on source-order to resolve conflicts across layers.

This is a powerful tool for re-architecting how a project’s CSS is structured that will not be useful until it’s in all browsers. Cascade Layers cannot be progressively enhanced or polyfilled client-side.

It’s also an example of a technology that’s well underway — all three engines have implementations behind a flag in preview browsers.

• Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1095765
• Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1699214
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=220779
• Working Draft: https://www.w3.org/TR/css-cascade-5/#layering
• Editor's Draft: https://drafts4.csswg.org/css-cascade-5/#layering

Cascade Layers will benefit from being included in Interop 2022, where extra attention to cross-browser testing will make sure the implementations are thoroughly interoperable.

[jgraham]

Apologies, I just added an issue template for porposals, which I should have done much earlier.

Would you be able to rewrite the issue description to match that template?

[gsnedders]

Tests: https://wpt.fyi/results/css/css-cascade?label=master&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bstable%5D&product=webkitgtk%5Bexperimental%5D&aligned&q=layer has a variety

@anttijk @xiaochengh given the ongoing implementation in both WebKit and Blink where these seem to come from, what's the coverage like? AIUI it's good?

[xiaochengh]

The test coverage looks good to me, other than below:

• [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order w3c/csswg-drafts#6323 is still unresolved yet. It may define a new behavior that needs new tests.
• CSSOM API, which is still pending on the exact spec text to be written down. All major spec issues have been resolved, though (see [css-cascade-5] Cascade Layers need CSSOM support w3c/csswg-drafts#6576)

[xiaochengh]

The CSSOM API has just been specified: https://drafts.csswg.org/css-cascade-5/#layer-apis
I'll add tests to cover it.

[xiaochengh]

CSSOM API tests have been added.

Also w3c/csswg-drafts#6323 has been resolved as rejected. So I think the test coverage is complete.

[foolip]

Thanks @xiaochengh! I think web-platform-tests/wpt#31726 + web-platform-tests/wpt#31823 are the PRs that added the tests, and that it's these two tests:

• /css/css-cascade/idlharness.html
• /css/css-cascade/layer-rules-cssom.html

Is that right?

[xiaochengh]

Exactly!

[foolip]

A proposed list of tests has been labeled with interop-2022-cascade. It would be great if someone from each browser engine team can look over this list and comment if there are any issues.

[xiaochengh]

My comments regarding the list:

• css/css-cascade/idlharness.html should be included
• layer-stylesheet-sharing.html and layer-stylesheet-sharing-important.html are less significant tests, because they test a specific edge case where the same stylesheet is inserted into a tree scope for multiple times. I don't see any real use case of doing it
• layer-property-override.html, layer-counter-style-override.html and layer-scroll-timeline-override.html are also less significant tests, because they test that @layer can reorder @property, @counter-style and @scroll-timeline rules. Not all browsers support these at rules, and also their usages are much lower (all <1%) compared to @font-face (70%+) and @keyframes (80%+) according to chromestatus.com

Other tests look good to me.

[gsnedders]

• layer-stylesheet-sharing.html and layer-stylesheet-sharing-important.html are less significant tests, because they test a specific edge case where the same stylesheet is inserted into a tree scope for multiple times. I don't see any real use case of doing it

These pass everywhere so I don't see much reason to exclude them, may as demonstrate the edge cases are interoperable.

• layer-property-override.html, layer-counter-style-override.html and layer-scroll-timeline-override.html are also less significant tests, because they test that @layer can reorder @property, @counter-style and @scroll-timeline rules. Not all browsers support these at rules, and also their usages are much lower (all <1%) compared to @font-face (70%+) and @keyframes (80%+) according to chromestatus.com

We should either: simply remove these from interop2022, or make them pass with assert_implements_optional when the other at-rules aren't supported. Probably the former?

[Loirooriol]

Additionally to the tests mentioned by Xiaocheng, revert-layer-011.html also depends on @property.

The last case in layer-statement-before-import.html depends on constructable stylesheets, but other cases seem relevant so I would keep this one in interop-2022-cascade.

[anttijk]

layer-cssom-order-reverse.html also contains a @property subtest. It would be nice if that was separate and excluded.

[gsnedders]

I've removed the tests in web-platform-tests/wpt-metadata#2492; this doesn't do anything about those with subtests though.