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

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

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.

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.

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

[css-cascade-5] Move unlayered styles below explicit layers by default …

Updated in 183a548

[css-cascade-5] Fix missed edit for reversing order of unlayered decl…

[@layer] Change layer order from preorder to postorder

Cascade layer styles should be lower priority than unlayered styles

[@layer] Change layer order from preorder to postorder

Bug 1734939 [wpt PR 31169] - [@layer] Change layer order from preorde…

[@layer] Change layer order from preorder to postorder

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;
}

Update Unlayered styles always winning over Layered styles

@OVERRIDES

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

@andremarcondesteixeira

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

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.

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)

Bug 1734939 [wpt PR 31169] - [@layer] Change layer order from preorde…

Navigation Menu

Repository navigation

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

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

tabatkins commented on May 13, 2021

jensimmons commented on May 14, 2021

css-meeting-bot commented on May 26, 2021

mirisuzanne commented on May 28, 2021

12 remaining items

jridgewell commented on Jan 6, 2022

andremarcondesteixeira commented on Jul 2, 2024

mcareydsgn commented on Jul 3, 2024

mirisuzanne commented on Jul 3, 2024

mirisuzanne commented on Jul 3, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions