[css-cascade-5] Reconsider placement of unlayered styles, for better progressive enhancement?

[mirisuzanne]

In the spec for Cascade Layers we define default unlayered styles as being at the top of the normal layer stack, and the bottom of the !important layers. Any explicit layers are added below the normal unlayered styles, with layered important styles above unlayered important styles.

• first layer !important -- highest cascade priority
• second layer !important
• default !important
• default (normal)
• second layer (normal)
• first layer (normal) -- lowest cascade priority

I'm not sure this matches either developer instinct, or the best path for authors to start integrating cascade layers as a progressive enhancement.

• I expect authors first instinct will be to reach for layers when they want to add cascade priority to a style
• Until layers are broadly supported, authors will want to integrate them selectively as a progressive enhancement

When I think about serving a simpler set of styles to older browsers, I would want those browsers to get the most broad defaults, along with anything most important in those defaults. But with unlayered styles at the top of the normal stack, authors are instead encouraged to move their most broadly-applied , lowest-priority styles (resets, global typography, etc) into layers first -- hiding them from old browsers. If default styles were at the bottom of the normal layers, authors could instead begin adding layers for more narrowly targeted styles.

So I'm proposing we change the way unlayered styles stack:

• default !important -- highest cascade priority
• first layer !important
• second layer !important
• second layer (normal)
• first layer (normal)
• default (normal) -- lowest cascade priority

[tabatkins]

I don't think I had too much of an opinion on whether unlayered styles were above or below the other layers. Your argument seems pretty reasonable to me.

[jensimmons]

Honestly, I can imagine usecases where it'd be best for unlayered styles to have more specificity, and usecases where it'd be best for less specificity. Especially when thinking about transitioning from existing projects; considering progressive enhancement needs; how devs might slowly detangle a large preexisting project by moving code in new layers over time; and putting 3rd party code in a layer while keeping custom code unlayered.

Would it be possible to allow Authors to set for themselves where in the cascade the "unlayered layer" resides? Maybe they even want to sandwich it in-between. A mechanism that's part of however they define the named layers & determine which layer is "first" & "second", etc.

There will need to be a default, in case they don't set this. And perhaps the default should switch as described above. But I'm not sure the default will work for all usecases.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-5] Reconsider placement of unlayered styles, for better progressive enhancement?, and agreed to the following:

• RESOLVED: accept the new reorder layering as detailed in the issue

The full IRC log of that discussion

<dael> Topic: [css-cascade-5] Reconsider placement of unlayered styles, for better progressive enhancement?
<dael> github: https://github.com//issues/6284
<dael> miriam: This came up in a few convos about cascade layers and migration path onto it. Potential for polyfill. As people move styles to layers they become invisible to older browsers.
<dael> miriam: Might work better if styles hidden from older browsers were more targetted styles rather than lower target defaults. Matches a bit better to how I think about progressive enhancement. Better defaults and then enhance details
<dael> miriam: jensimmons had a comment about letting authors decide and say where unlayered styles go which is also interesting idea
<dael> Rossen_: Feedback from group?
<dael> TabAtkins: As I said on issue, no preference. Fine with what group decides
<dael> Rossen_: Silence suggests group is fine with either. What is prop miriam?
<dael> miriam: If we want to explore jensimmons option I could put time into that and see if good way to make it explicit. Happy to do that before resolving
<dael> fantasai: Even if we allow author to define we need a default
<dael> fantasai: I think it does make sense the way miriam suggested.
<bkardell_> +1 I was thinking what fantasai just said
<dael> fantasai: When you have layers pulling in from an imported doc they are usually overwritten by outer style. If doing layers in sep files it's natural for ones in doc to have higher priority
<miriam> +1 that makes sense
<dael> fantasai: I think her proposal makes sense overall as a good default
<dael> Rossen_: Anyone else?
<dael> fantasai: I think it's more confusing when consider !important b/c they will not override. A little mixed feelings
<dael> miriam: !important in the unlayered styles we're putting at bottom of the normal stack. It's backwards
<dael> fantasai: Can't put !important below
<dael> miriam: By default normal styles are below layered styles. !important becomes above
<dael> fantasai: So my explaination is opposite. Layer pulls it higher. !important overrides. Overall makes sense. Not a strong opinion but logic makes sense
<fantasai> S/Layer pulls/So proposal is layer/
<dael> Rossen_: Hearing still support for the proposal. Will ensure good defaults and default !import override the first layer. Don't know if this needs further discussion or if we're okay
<dael> fantasai: Lean toward accepting
<dael> Rossen_: There's more consensus then I hear other or different opinions.
<dael> Rossen_: Let's call for objections and we can always revisit
<dael> Rossen_: Objections to accept the new reorder layering as detailed in the issue
<dael> RESOLVED: accept the new reorder layering as detailed in the issue

[mirisuzanne]

Updated in 183a548

[FremyCompany]

FWIW now that I saw an example of this in practice, I am under the impression that this reversal of order doesn't serve the use cases that layers were supposed to address.

The main use cases I can see for layers are resets, frameworks, and framework themes. Having these styles above the site's styles just doesn't work.

See the example at the start of this thread, it just doesn't make any sense to me:
https://twitter.com/fremycompany/status/1445126893037031425?s=21

I think it would be worth having a redo of this conversation in the light of this example to confirm this is still a decision the group is confortable about.

In my opinion, if you start using layers, the only type of polyfill that will work to support older browsers will be to just wrap every rule in :where() to nuke its priority and rewrite the files so that rule order match the priority order after layers have been taken into consideration.

I don't think one can simply decide some styles just don't get received by a supported browser, whether that style is a reset or a specific style shouldn't matter much, it is necessary all the same. So the reasoning at the start of the thread doesn't speak to me.

But this is just my opinion of course, I just want to make sure this gets a review before implementations ship.

[mirisuzanne]

Agenda+ to review this. I wonder if we can add it to the special call tomorrow? I know that time might not be a great time for you @FremyCompany, but I think there might be some urgency since three browser engines support layers behind a flag already.

[FremyCompany]

Additional comment here: #6323 (comment)

Another approach I have been thinking about is to have two lists independently, all layers that must be above the unlayered styles, and all who need to be below. [...]

[css-meeting-bot]

The CSS Working Group just discussed Reconsider placement of unlayered styles, for better progressive enhancement?, and agreed to the following:

• RESOLVED: Prop: Reverse the prior resolution. Unlayered styles are highest priority

The full IRC log of that discussion

<dael> Topic: Reconsider placement of unlayered styles, for better progressive enhancement?
<dael> github: https://github.com//issues/6284
<dael> miriam: Introducing, but fremy may want to jump in
<dael> miriam: In initial proposal had layers under default styles. At some point I proposed we change to have them at bottom of stack. Better matches user expectations. But does not match main use cases as fremy points out
<dael> miriam: People may want some of both. Have separate issue for that. Question is did we get the default right
<fremy> q+
<astearns> ack fantasai
<TabAtkins> q+
<dael> fantasai: I think somewhat useful to think about 2 positions as innermost and outermost. Outermost is lowest priority rules. Innermost is highest priority.
<astearns> ack fremy
<fantasai> s/rules/rules unless !important, in which case highest priority/
<dael> fremy: I reopened this because somebody that used to work at stripe posted example. At first thought browser was wrong b/c order seemed weird.
<fantasai> s/is highest priority/is highest priority unless !important in which case lowest priority
<florian> q+
<dael> fremy: Idea is you have layers that are base and theme. Then you add normal styles and declaration in the style was specific but overwritten by base.
<dael> fremy: Main reason layers nice I thought is CSS resets where you can't reset something because specificity of rule not easy to have resets
<dael> fremy: If the reset is above style of site it doesn't work. That's reason I think not right call. most obvious example to me would prefer styles to be lower than main styles of site.
<jensimmons> q+
<dael> fremy: It would be useful to see examples of other way
<astearns> ack TabAtkins
<astearns> ack florian
<dael> TabAtkins: I don't have a strong opinion on default. Important we prioritize issue to let you put unlayered at a spot. If we do that default doesn't matter as much
<dael> florian: Agree with prioritizing. I lean toward fremy b/c if we keep new unlayered is just a fallback. Unlayered is legacy and it feels weird that main way to write css is a fallback. My intuition is same as fremy.
<astearns> ack jensimmons
<dael> jensimmons: I agree. Sounds like we're mostly agreed. Unlayered should be most specific. Be confusing to write code as we have for 20 years and have it not work. Layered will be most organized and messy will be more specific and need to override
<florian> +1 to jen
<dael> jensimmons: Agree with fremy
<fantasai> +1
<astearns> ack fantasai
<dael> fantasai: I wanted to note seems that for files layered that are imported it def. seems expected behavior is lower priority
<jensimmons> and yes to having a way for Authors to change this default!
<dael> fantasai: Inline @layer blocks intuition might go other way where making more specific. I think if we have to pick a default I think fremy argument makes sense with jensimmons explaination of why
<dael> fantasai: Could go different with @import and @layer but might be more confusing
<dael> fantasai: Would be useful to create one off roles and decide if it goes above or below a layer
<dael> fremy: I think I agree. IN the other issue about how to spec ordering I made a similar proposal. This layer is priority and this is normal. That's the other issue, though
<dael> miriam: Swayed by this. In terms of other issue we don't want to go into details but do we want to keep it as defer to next level or do we want to try and solve?
<dael> fantasai: Sounds like we want to solve
<dael> jensimmons: Agree
<dael> TabAtkins: Only think that's difficult is figuring out when [missed] should be
<dael> jensimmons: Useful in transition to let authros decide what happens. Waiting for that tool could be painful
<TabAtkins> s/when [missed]/what name it/
<dael> astearns: Prop: Reverse the prior resolution. Unlayered styles are highest priority
<dael> astearns: Obj?
<dael> RESOLVED: Prop: Reverse the prior resolution. Unlayered styles are highest priority

[jridgewell]

I represent the AMP library, and wanted to chime in that we believe the decision to revert this was the correct choice. AMP wants to provide a set of default styles as a framework that end users can then add their own styles on top of. We've had issues in past where changing a framework selector in anyway causes it to become more specific than the end user's selector, and now our default styles are overriding their intended styles.

We're looking to use @layer to solve this, so that all of our styles are truly defaults and any unlayered end user styles will override our @layer styles. We fully expect our end users to continue to write unlayered styles just out of habit. Now we can be free to make our @layer selectors extremely specific without worrying that we'll win over the end user's selector.

@layer AMP {
  /* We should be able to change this selector to any specificity */
  amp-foo p {
    /* This default style should be easy to override */
    color: red;
    font-size: 100px;
  }
}

/* End users will write unlayered out of habit */
p {
  /* This should win, even though `p` is less specific than `amp-foo p` */
  color: green;
}

[andremarcondesteixeira]

IMHO this was a bad decision.
It would be very easy to instruct the developers to create a new @OVERRIDES layer instead.
Because of this decisions, most sites just cannot use layers. This decision made the layers basically useless until all stylesheets in the whole internet decide to wrap their styles into a layer.
Websites using old libraries, like old Bootstrap versions, just cannot use layers because of this.

https://stackoverflow.com/questions/78252415/is-there-a-way-to-have-layered-css-styles-have-a-higher-priority-than-unlayered

https://www.bram.us/2021/09/15/the-future-of-css-cascade-layers-css-at-layer/#comment-851270

[mcareydsgn]

@andremarcondesteixeira 100% agree. I would support the reversal of these changes.

[mirisuzanne]

We cannot reverse this, it's already widely used. But we knew it was a tradeoff between short-term and long-term goals. The fact that it's frustrating during this transition period is not a surprise, it's exactly the tradeoff we decided to make in favor of the long-term design of the feature.

[mirisuzanne]

The primary deciding factor (for anyone who hasn't been part of the conversation from the start) was this:

• One of the primary use-cases is to give site authors final control over where external tools fit into their cascade. That doesn't only include third-party libraries, but also design systems, etc. The author of the site should have final say.
• It's possible to import an external stylesheet into a layer (name-spacing it, and placing it as desired). But it's not possible to import a stylesheet and remove all the layers inside it.
• If layers had priority by default, it would be impossible to override any layers in third-party tools without layering everything essential on your site. That's a bad situation to put site authors in.

Because it's possible to add and nest layers, but not possible to remove or un-nest layers, this is the only solution that gives site authors long-term control over the entire system. Does that mean it's perfect? No. But the alternative seemed (and still seems to me) worse. We made a tradeoff, as we often do.

We can't change that decision. But we can add to it. Documenting the pain-points that remain, and looking for ways to address them is what we're here for! I think the main one is to give authors some ability to place layers above the unlayered styles. We have an active thread for that. It's a complex problem, but I think we can get to something that works.

I think tool-makers (like WordPress) should also think of ways to let site authors put their tool-provided styles into layers. That doesn't have to be WP adopting layers for everyone, but providing a way that authors can opt-into layering WP styles would be great. (WP is just one example of many)