Early design review of Cascade Layers

[mirisuzanne]

HIQaH! QaH! TAG!

I'm requesting a TAG review of Cascade Layers.

In the same way that Cascade Origins help to balance styling concerns across stakeholders -- layering browser defaults, user preferences, and document styles -- it can be useful to have similar layering of concerns within a single origin. Author styles often start with browser normalization or resets, then layer in default typography, broad patterns (sometimes from design systems or frameworks), and more specific component styles. Cascade Layers would allow authors to define their own layering scheme and avoid specificity or source-order conflicts across concerns.

• Explainer: https://github.com/oddbird/css-sandbox/blob/main/src/layers/explainer.md
• Specification URL: https://drafts.csswg.org/css-cascade-5/
• Security and Privacy self-review: This proposal does not expose anything new, and has no impact on security or privacy
• GitHub repo (if you prefer feedback filed there): https://drafts.csswg.org/
• Primary contacts (and their relationship to the specification):
  • Miriam Suzanne, @mirisuzanne, Invited Expert, author
  • Elika Etemad, @fantasai, Invited Expert, contributor
  • Florian Rivoal, @frivoal, Invited Expert, contributor
  • Tab Atkins Jr., @tabatkins, Google, contributor
  • Rune Lillesveen, @lilles, Google, implementor
  • Rossen Atanassof, @atanassov, Microsoft, co-chair
  • Alan Stearns @astearns, Adobe, co-chair
• Organization(s)/project(s) driving the specification: CSSWG
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • Initial CSSWG thread
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Request for Mozilla Position

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification:
  • No known opposition
  • Layers terminology bikeshed
• This work is being funded by: Google

You should also know that...

The CSSWG has approved this specification for publishing as a First Public Working Draft, and also recommended that I submit the design for early review -- as the spec still has a number of open issues.

We'd prefer the TAG provide feedback as 🐛 open issues in our GitHub repo for each point of feedback

[LeaVerou]

@atanassov, @plinss and I discussed this in our VF2F breakout today. Overall, we are happy to see this work and we acknowledge that it is addressing very real author needs.

One thing we noticed is that it appears that there is no way that frameworks can declare their styles as having lower priority than (author) unlayered styles. Since frameworks were listed as one of the primary use cases, we were wondering if some mechanism for achieving this should be added.

We also agree with existing concerns about the name @layer, which has an existing well established visual interpretation, and look forward to the relevant issue being resolved.

[mirisuzanne]

Thank you all!

there is no way that frameworks can declare their styles as having lower priority than (author) unlayered styles.

We do define all layered styles as having lower priority than any unlayered styles – so that behavior is already built in. I'm not sure what an explicit syntax would add to that default behavior. Can you clarify?

[LeaVerou]

Thank you all!

there is no way that frameworks can declare their styles as having lower priority than (author) unlayered styles.

We do define all layered styles as having lower priority than any unlayered styles – so that behavior is already built in. I'm not sure what an explicit syntax would add to that default behavior. Can you clarify?

That's good to hear, though was unclear from the explainer. The following parts gave me the impression that all layers have higher priority than unlayered styles:

The resulting layers & layer-order are:

1. unlayered
2. default
3. framework
4. framework default
5. framework theme

In order to address the use-cases described, layers need more cascade weight than the selectors they wrap.

Author-defined layers are listed in the document order where they are first introduced. For the purpose of this step, any declaration not assigned to an explicit layer is added to an implicit final layer.

When comparing declarations that belong to different layers, then for normal rules the declaration whose cascade layer is last wins,

Results in the following layer orders:

1. Important Author Origin
   1. Important reset layer
   2. Important base layer
   3. Important patterns layer
   4. Important components layer
   5. Important un-layered styles
2. Animations
3. Normal Author Origin
   1. un-layered styles
   2. components layer
   3. patterns layer
   4. base layer
   5. reset layer

[mirisuzanne]

Ah yes - I tried to follow the way origins are often listed from highest to lowest priority, but I'll clarify that better. Thanks!

[LeaVerou]

We discussed this again in a breakout today. Overall we're happy with the direction this is going and quite excited about this work. We are going to close this, and will continue to monitor open issues for future review requests once the spec is more mature.
Thank you for working with us!