Intent to Prototype: CSS cascade layers

[Xiaocheng Hu]

Contact emails

xiaoc...@chromium.org

Explainer

https://gist.github.com/xiaochengh/58c793e3bf06a1bb0f7d472ebb170feb
https://github.com/oddbird/css-sandbox/blob/main/src/layers/explainer.md

Specification

https://drafts.csswg.org/css-cascade-5/#layering

Summary

CSS cascade layers (@layer rule and layered @import syntax) provide a structured way to organize and balance concerns within a single origin. Rules within a single cascade layer cascade together without interleaving with style rules outside the layer. This allows authors to achieve a certain cascade ordering for same-origin rules in a proper way.

Note: We will not implement the 'revert-layer' keyword due to its high complexity and likely negative performance impact.

Blink component

Blink>CSS

Motivation

Cascade layers allow authors to create layers to represent element defaults, third-party libraries, themes, components, overrides, and etc.—and are able to re-order the cascade of layers in an explicit way. Without cascade layers, currently authors need to tweak, e.g., selector specificity, !import or source ordering to achieve a certain cascade ordering, which is cumbersome and error-prone.

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/4470

Search tags

css, cascade, layer, cascade-layer

TAG review

https://github.com/w3ctag/design-reviews/issues/597

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

As a few feature, the only interoperability risk is that other browsers may not agree or follow up to implement.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1699215)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-June/031911.html)

Web developers: Positive (https://bugs.chromium.org/p/chromium/issues/detail?id=1095765)

Debuggability

@layer rules will be surfaced to DevTools in the Style panel to indicate which layer the style rules are in.

Is this feature fully tested by web-platform-tests?

No. Will add a test suite.

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1095765

Estimated milestones

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5663362835808256

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

I saw +Andy Davies raise an extremely valid concern regarding this, that I share.

This feature seems to encourage developers to add late-discovered and render-blocking CSS @import or @layer statements. That's likely to cause significant performance degradation.

This aligns with concerns I had regarding CSS modules, but without the path forward to eliminating them (interim transpilation, import maps to provide caching benefits, and WebBundles in the future).

I think it'd be better to design this feature with loading performance in mind and make sure that the URLs are readily available to the HTML parser and the preload scanner before it. As we're the first ones to prototype this, now seems like a good time to make such changes.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhbK0nY6ioO31J-Jx3bsbQ-j1N1%3DZDo5kA1g1DktubmKEA%40mail.gmail.com.

[Xiaocheng Hu]

+Miriam Suzanne to see if we need any spec revision

That's indeed a serious concern. Thanks!

I think we need to make sure the preload scanner works for layered @import as you suggested, and find a solution to https://github.com/w3c/csswg-drafts/issues/5853 so that developers don't need to worry about serial downloading of stylesheets.

[Miriam Suzanne]

I don't see any Cascade Layer spec changes that would be helpful here. The concern seems to be with the `@import` rule itself, which already exists, and *is not required* for using Cascade Layers. I expect that most authors will prefer the `@layer` block rule for exactly this reason. But it makes sense to also ensure that authors using `@import` have access to the feature when needed. We don't need to encourage that, but it would be strange not to provide it, the same way we provide media-queries in `@import`. Is the argument that "we should never add new features to the existing `@import` rule, because `@import` is bad"? If so, it seems like a proposal to deprecate `@import` entirely?

[Yoav Weiss]

Maybe I misunderstood the explainer. Looking at the layer rule, it seems to be introducing a brand new way to create imports, which is not obviously restricted to being the first rule in the stylesheet (as import is restricted).

If that's not the case, and such rules are restricted to be the first rules, that makes matters slightly less performance-negative. The concern would then shift to this feature encouraging developers to use imports in places where they previously avoided it, which seems solvable by better documentation, and moving to a pattern of having styles for the different layers declared in the HTML, where they are discoverable.

[Miriam Suzanne]

I didn't see that the old explainer is linked here. We've made a lot of changes since then, as Cascade Layers moved into the official specification. The Editor's Draft (https://drafts.csswg.org/css-cascade-5/#layering) is the most up-to-date, though the Working Draft is also pretty reliable at this point (https://www.w3.org/TR/css-cascade-5/#layering). I'll add a note to the top of my explainer making that clear. If you look at the spec, you'll find that there is no new importing functionality at all. Instead there is an optional layer function added to the `@import` rule, along side the media-query options that already exist on `@import`.

[Xiaocheng Hu]

On Fri, Aug 20, 2021 at 9:49 AM Miriam Suzanne <mir...@oddbird.net> wrote:

I didn't see that the old explainer is linked here.

I probably made a mistake by linking it here, because it says "explainer". Hope it didn't confuse too many people.

I'll unlink it from the chromestatus entry, and only refer to the spec.