[css-cascade] Where do Cascade Layers fit in the cascade?

[mirisuzanne]

This is in relation to #4470 custom-origin proposal, and Cascade 5.

While originally based on the concept of “origins” as a useful way to balance larger-scale cascade layers, this feature isn’t necessarily tied to the current rules for origins and importance — which exist to balance power at an even larger scale between authors and users/user-agents. Instead,

In order to address the use-cases described in early conversations (Reset < Design System < Overrides, Reset < Defaults < Patterns < Layouts < Components, CMS Core < CMS Extend < Base Theme < Site Styles, Old Styles < New Styles), “custom origins” only need a higher weight than specificity. Given that, I think it would work best as a new cascade layer between scope & specificity.

That would mean:

• Authors get a new “top-level” cascade option above specificity, and not limited by selector practicalities, but still confined to origin & scope.
• The feature would not impact existing origin/importance and scope/shadow-dom rules, potentially rendering [css-cascade] How do Cascade Layers interact with Shadow DOM #4984 moot.

[css-meeting-bot]

The CSS Working Group just discussed Where do "custom origins" fit into the cascade.

The full IRC log of that discussion

<Rossen_> Topic: Where do "custom origins" fit into the cascade
<Rossen_> github: https://github.com//issues/5003
<myles> miriam: 503 was me starting to think through where it might fit. I propose here in the issue it could be nested under scoping, though TabAtkins raised a question around the use cases in a different issue that would contradict that. I'm not sure the proposal her fits every use case.
<dbaron> s/503/5003/
<astearns> tab's comment: https://github.com//issues/4981#issuecomment-621975440
<myles> miriam: In this proposal, I was thinking for most of these use cases like a layering of a framework, a theme, design system, component, it wouldn't need to be at a high level. TabAtkins pointed out it would need to be to layer new styles over old styles, where you want importance to have more impact
<AmeliaBR> q+
<myles> TabAtkins: You do not want th onion layering inner/outter thing, you want oldstyle normal & oldstyle !important to be together, then you want newstyle normal and newsytle !important to go tobether. This would require reinterpreting what !important means in a custom origin. Styles in the normal case would be importaed as necessary. If you're in a custom origni, you get anew style place that's above origin. !important is a toggle in there that puts you in a new
<myles> layer
<myles> Rossen: Would `revert` be scoped to the origin
<myles> miriam: It seems `revert` would be useful in this, so that's worth asking.
<myles> TabAtkins: My first thought, i would think we would still want revert to clear the entire author relation. If that's how it's used today, and you migrated to custom origins, it would be bad to have that stop and leak some old styles around.
<myles> TabAtkins: Then i'm not super clear on what use cases there would be to clear out the styles just form one custom origin
<myles> Rossen: I'm thinking of forced colors, overrides that are there for UA reasons
<myles> Rossen: today they revert all the way back. If we only did that in a custom origin, like you said, that would lead to a lot of weird other styles
<myles> florian: If one of your layers is a reset, using revert to go back to the revert isn't crazy
<fantasai> +1 to jensimmons
<myles> jensimmons: Maybe we need two different controls. One that lets you go back all the way, and one that lets you go back to just one layer
<dbaron> +1 to jensimmons on multiple reverts
<AmeliaBR> +1 to Jen's comment; both use cases are valid
<myles> fremy: I recently on twitter I was a thread with a company misunderstanding `revert` or `initial` and people trying to explain it, and it was still wrong. We need to stop worrying about how many reverts and initial because eventually people are not going to undersatnd it any more
<myles> miriam: Authors got the idea that initial would work more like revert does, and were used to it before revert became available. Authors are using initial thinking it takes them to browser defaults, and it doesn't.
<myles> TabAtkins: That's why the keyword we have, ignoring future keywords, should do the same it does today, so it can do the same thing to does today of reverting to the UA stylesheet
<myles> florian: Today we can't determine the difference between "going back to the browser" and "blowing away all user styles"
<myles> TabAtkins: It should blow away all the styles in the world of custom origins
<myles> jensimmons: Avoiding complexity is a value that we hold and should apply, so maybe revert-foobar and that is the more precise tool, and just revert as we have it today blows everything away
<myles> jensimmons: That makes sense to me
<Rossen_> q?
<fremy> (correcting the minutes a bit, I think we need to *start* worrying about how many "revert"-like keywords we have)
<myles> florian: One question: Now we're xploring whether custom origins should be per origin or something in between .... is there a specific problem here? Why are we looking into alternatives?
<TabAtkins> qq+
<TabAtkins> (I do have an asnwer to that question)
<myles> miriam: I wasn't here for the initial conversation, so I was going off the notes. There were issues raised in that thread. I wasn't there for that thread. it also seemed like maybe we could avoid the issues with imiportance and scoping shadow dom. SO i was looking into that. I don't have a strong reason for that.
<Rossen_> ack TabAtkins
<Zakim> TabAtkins, you wanted to react to a previous speaker
<tantek> present++
<myles> TabAtkins: The reason why using origins might be problematic, in an issue by emilio, shadow dom scopes impose another level between specificity and origins. Right now, that's not too bad because there are only 2 origins today. But if we add more origins, we now have an interleaving of shadow scoping and custom origins. A linear list of things turns into a matrix of specificity complications, which is bad for both authors and implementations. This isn't fatal,
<myles> but if we could do this below shadow dom scoping, it would help.
<Rossen_> ack AmeliaBR
<tantek> agreed re: specificity has been far too complex for authors, especially teams
<myles> AmeliaBR: The idea of how does this interact with the cascade and importance. It's important to keep this as simple as possible. The biggest author complaint is how complex specificity is and importance, and how you get a lot of unexpected consequences and interactions. keeping this as tightly contained with as few cross interactions as possible is important.
<myles> AmeliaBR: Having this new origin or cascade level whatever it is, completely contain all of its contents so that even if there's an !important rule it's only more important than other things there, that makes sense. If you really want override, then you take a different cascade origin custom origin which is your origin for your override. We don't need to interact them all together.
<florian> q+
<myles> AmeliaBR: Just so its really explicit. Before you have this layering of custom origins as well, so authors are thinking about how these interact intentionally, let's not have interactions that are hard to control
<myles> fantasai: I disagree with ^^^
<Rossen_> ack fantasai
<jensimmons> the !important debate is on https://github.com//issues/4971
<myles> fantasai: I think the origin that we have is really good, and the interaction we have between normal rules and !important have a reverse stacking effect, we do that for scoping right now. For the reasons you want override. If your problem is you want something to have more specificity in a layer, then solve that in that layer. !important is more suited for override. If you want more control over specificity, we can add more control over specificity
<myles> fantasai: Interaction is useful because you can get overriding behavior. Many examples do need that. Like you'll set up a set of base styles, and there are some other rules that make the design work, and those should be !important. These are my slide deck's styles. That's an important feature in the custom cascade origins.
<myles> fantasai: If you think the stack as a level with its own !important next to it, then we can consider a nesting structure, but the override and the inverted priority of !important rules i important in the cascade and it should stay the saem fhere
<Rossen_> ack florian
<myles> florian: I'm in agreement. A lot of the confusion we see about specificifity is that people don't want specificity, but they want custom origins. Specificicity is the wrong tool. People struggle !important because they want specificitity. We should just give them the right tools.
<fremy> (likes what florian said, but it's tricky to get this right I think)
<Rossen_> ack fantasai
<myles> miriam: THis is idealistic, but some idea in my mind that people can learn how importance and origins work from having access to it
<myles> Rossen_: That's novel.
<leaverou> Another reason specificity is confusing is that it's a bad heuristic. It tries to predict importance based on querying logic, and it's frequently wrong (with :not() being a common case of that)
<jensimmons> q+
<myles> fantasai: I like that. I agree with florian. Specificifity is arbitrary. it doesn't always owrk. There are features that people want such as origins and scoping int he cascade. "The stuff here always wins over the stuff that's defined for the page as the whole" so peole try to do this with specificity but it's not strong ehough.
<TabAtkins> Proposal for this issue: https://github.com//issues/4981#issuecomment-622090790
<myles> Rossen: A lot of the conversation is around reaffirming the fact that we do want custom origins and we want to get them wroking. This is another confirmation based on jensimmons's awesome demo and talk back in the real F2F in january.
<myles> Rossen: The actual current topic is "where do they fit?" Can we make some decision here?
<florian> q+
<myles> Rossen: We need something more concrete to play with
<TabAtkins> q+ to talk about the comment
<Rossen_> s/novel/nobel/
<myles> jensimmons: There is a debate to be had about how !important works. It's ticket 4971
<Rossen_> q?
<Rossen_> ack jensimmons
<myles> jensimmons: I want to switch to 4969. Where do custom origins fit reminds me of a conversation I had with miriam a couple weeks ago
<myles> jensimmons: (custom origins aren't my idea, i just got to present them)
<myles> jensimmons: It was a conversation about 4969
<castastrophe> https://github.com//issues/4969
<myles> Rossen: before we switch topics, this is going to get dumped into a different issue. But we have a queue. Let's flush the queue. I agree this is more of a umbrella feature issue rather than .... [missed]
<myles> florian: TabAtkins earlier said that shadow dom is a source of complexity. Is there a way to recast the current shadow dom thing into custom origins once we have them, so we owuldn't need two layers, and just merge them and stop worrying about hte interaction?
<Rossen_> ack *
<Rossen_> ack florian
<Rossen_> ack TabAtkins
<Zakim> TabAtkins, you wanted to talk about the comment
<myles> TabAtkins: We can't reasonably recast existing shadow dom styling into custom origins. The interaction is "outer styles that get put in via ::part pseudos vs the styles that are defined inside the shadow root"
<myles> TabAtkins: Given there's infinite nesting, it's not possible to recast in terms of custom origins
<myles> AmeliaBR: On this topic, this issue, where do they fit in the cascade. We had agreement that there's a natural cascade when it comes to comparing with browser and user styles and !important, but shadow dom is the complication, and the other one is animations and transitions, where are currently defined in terms of a separate origin that overrides
<myles> AmeliaBR: That's another weird set of possible interactions that needs to really be written out and the shadow dom thing neesd to be written out so the use cases are logical for shadow dom especially, there are very clear use cases of defaults and overrides, and these need to interact in a useful way.
<myles> Rossen: These are great additions to things that need to be taken into account.
<myles> Rossen: I want us to move forward and make progress on other issues.
<myles> Rossen: we have about 20 minutes remaining here for custom origins.
<myles> Rossen: We barely started making any progress
<myles> Rossen: jensimmons wanted us to go to 4969
<myles> jensimmons: yes
<myles> jensimmons: it's a big chunk
<TabAtkins> Agree that we should hit the various issues to bring the talking points into people's heads; we shouldn't expect final progress on this here at this meeting.

[mirisuzanne]

The working proposal for adding layers to the cascade sort order is:

1. Origins & Importance
2. Context (eg Shadow DOM)
3. Layers
4. Specificity
5. Source Order

This avoids a lot of implementation complexity around Shadow DOM context, while still giving authors a way to group and layer selectors at a level above specificity.

[mirisuzanne]

This has been drafted in Cascade 5 with one small variation to define how layers interact with the style attribute. The resulting sort order is:

1. Origins & Importance
2. Context (eg Shadow DOM)
3. Style Attributes
4. Layers
5. Specificity
6. Source Order

Which results in style rules remaining at the top of a given origin for both important and normal styles:

1. ❗️Author
   1. ❗️Style Attribute
   2. ❗️Defined Layers (in reverse order)...
   3. ❗️unlayered
2. Animations
3. Author
   1. Style Attribute
   2. unlayered
   3. Defined Layers (in declared order)...

[tabatkins]

Yeah, this seems reasonable to me overall.

[mirisuzanne]

This is the model that we resolved to move into Cascade level 5 and the FPWD. Closing as resolved. If anyone has more specific issues with this approach, that can be discussed in a new thread.