[css-cascade] How do Cascade Layers interact with !important?

[mirisuzanne]

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

The predefined origins are stacked such that important origins reverse the order of their normal counterparts:

• !important
  • User Agent
  • User
  • Author
• normal
  • Author
  • User
  • User Agent

Not Intertwined:

When adding custom origins (subset in the author origins), I think it’s clear that important and normal layers should remain the outer layer, rather than being subset layers within an origin:

• !important
  • custom (?)
  • custom (?)
• normal
  • custom 2
  • custom 1

Not:

• custom 2
  • !important
  • normal
• custom 1
  • !important
  • normal

The !important flag is not meant for that kind of internal layering (we have specificity for that), but for balancing power between and across origins.

Reverse or maintain order?

It’s less clear if reverse-ordering should be maintained, or if that should be customizable. When origins are static and represent different concerns, the reversal ensures that lower origins can get final say when necessary. Since custom origins are not preset, and new origins could be added at either end, I think:

• Neither approach is dangerous. If a third-party framework provides both normal and important styles, I can work within either system to override what I want as an author. I can create origins below or above, and add !important flags in either case. Because of that, I’m also not sure there’s a strong need for user-customization of the important order, which would add both inconsistency between projects, and additional syntax.
• Reversed order is consistent with existing origins. If custom origins worked the same way, it might help teach the concept. I'm not sure this approach has much else going for it in use-cases I've seen.
• Maintained order matches current author experience. Because author normal & important layers are side-by-side, authors rarely think about other origins, let alone reversal of important layers. Adding !important feels more like a linear change in specificity. This is much more likely expected behavior.

[mirisuzanne]

In #4981 (comment), @tabatkins points out that the old styles < new styles use-case would require importance to follow the "intertwined" structure above…

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade] How do custom origins interact with `!important`?.

The full IRC log of that discussion

<dael> Topic: [css-cascade] How do custom origins interact with `!important`?
<dael> github: https://github.com//issues/4971
<dael> miriam: Touched on this at F2F
<dael> miriam: This ties in closely with question of where cascade layers fit in cascade. Interact with origins or some layer below.
<dael> miriam: Question is how for normal in !important styles work in these layers. INtertwine in a way that single layer contains both normal and important styles so normal and important can overrider a different layer. My sense was no, but it would help with some use cases like new styles overriding old
<dael> miriam: Other is all important override all normal styles and you get 2 layers for each custom cascade and then need to answer if they reverse
<dael> miriam: Alternative is it's somewhat customizable and you can determine which of these you wan
<dael> fantasai: Definite use cases for inverted order that we have. THis is the way scoped styles work. There is a layer inbetween normal and !important which is animation layer. If someone needs a second layer they can have another custom layer and don't need !important. Specificity problesm should be addressed directily. Reverse order improtant shoudl be what we do. Only strong use case is I have old styles I want to be lower.
<TabAtkins> q+
<jensimmons> q+
<dael> miriam: Sense is with any of these if you can create custom origins you should be able to create any outcome from layering as needed.
<dael> miriam: Changes ordering of layers
<astearns> ack TabAtkins
<florian> q+
<dael> TabAtkins: I have an alterative. fantasai explianation is good in many, but an independant library you don't want its !important to leak out and overrider. Alternative is within a cascade layer there are no !important. We ignore or syntax error and that way we don't answer this. You just make a higher level if you want a higher level
<dael> fantasai: I don't think that quite works.
<dael> fantasai: You as a library don't control the ordering of layers. THat's dependant on how things are imports and master doc. Reasonable for something to express these are my styles and these rules need to exist or it breaks. THat would go into an important layer.
<dael> fantasai: I don't think that works super well if you have to create layers and importer has to know the order. We havea. mech for !important. If a library is using it for not important things that's bad on the library
<dael> TabAtkins: Your model is outer page is direct controller?
<dael> fantasai: I think it's possible for things to pull through multi level. All levels should have idea that if something is !important it's because it will be broken if I don't have it.
<dael> TabAtkins: Common practice for !important is not the best hting here.
<dael> fantasai: People doing it wrong are already making brokens stuff. Example is !important is overriding animations already.
<dael> TabAtkins: Seems to be one of the largest bits there. Distinguishable from saying layers with no importance is anyone using cascade layers couldn't override animation. HOw important is that?
<astearns> ack jensimmons
<dael> florian: Reversing your argument if people want multi layer in library to override they should create layers and !important is to go on top of the rest.
<florian> q-
<dael> jensimmons: You took conversation to where I was going. One of the underlying debates is how much do we design this new thing to be the best idea of a new thing or how much to design to deal with how authors think they understand origins and cascade and !important.
<dael> jensimmons: We could decide to design an API to match author current understanding and doens't require them to re-learn.
<florian> +1 to jensimmons
<dael> jensimmons: But I think we should believe that authors will learn and we can teach. It will be abreath of fresh air and people will be okay. THe story will be clear. This was old cascade, this is new, and here's a new meaning. I think it will be fine.
<dael> jensimmons: We shouldn't worry and think about if we can jump 10 years ahead when authors know what they're doing, what is the ideal.
<fantasai> jensimmons++
<astearns> ack dbaron
<dael> jensimmons: In this moment debating if important should go on top. It could be useful to them. I think think this is a big enough change that it will lead to a new understanding.
<dael> dbaron: I wanted to throw an idea out. TabAtkins was talking about what would happen if we didn't have !important. Some discussion about what people would do to get it. One answer is custom origins could let you do what !important does today in a different way. You can say these rules are where !important use to be in the old way.
<jensimmons> I agree with dbaron — and want to say it's super interesting to think about not having !important anymore. (sort of). Or doubling down on it & making it work still....
<dael> florian: Depends on specific of proposal. What I find hard to do is in world where you set !important you don't know how many layers there will be becuase you haven't been placed. Beauty of the model is whereever you end up your !important is on the other side
<dael> fantasai: We have inverted order for scoped style so being consistant is good because it helps reinforce. We have it for origins and scoping, we should have it for layers.
<dael> myles: Wonder if you could use TabAtkins idea of no !important allowed if we allow negative orderings o if you're in L3 you can also control level -3 and put things there. Allows both worlds
<dael> florian: Put rules in negative of self or negative whatever you choose?
<dael> myles: Former
<dael> florian: How different from !important?
<dael> myles: From impl pov it's a collection of layers. It has simplicity I assume TabAtkins looking for
<dael> astearns: Building on myles instead of haveing ! mean invert we can have explicit teachable syntax that says whereever this layer goes the rule is in the inverse. We can come up with something better than !important syntax
<dael> jensimmons: Makes me think it's hard to answer this until we have other answers like is there nesting rules, how are they layers declared- list or numbers or link tag? What's the other parts. Than do we need !important?
<dael> jensimmons: I think the idea of getting rid of it is fascinating. Or we realize that to keep things simple we need it.
<dael> jensimmons: I think people will need a way to do use case of !important. Override animation or shift bootstrap 17 under but a couple you need above.
<dael> jensimmons: Maybe we need it going forward but not in !important syntax. Hard to know without knowing how other part looks
<dael> miriam: I agree there's a need to escape your layer. That's a strong use case to say this one style is required for this to work so you have to go to extra effort to override it which is what !important is for.
<dael> astearns: Not hearing consensus, I suggest we keep this open and work on a syntax where we can have examples and try out the use cases in a syntax.
<dael> astearns: Sound alight?
<dael> TabAtkins: Yep
<dael> jensimmons: Great discussion; fascenating.
<miriam> very, thank you all!
<dael> astearns: Yep, cool stuff. Great this is being considered.
<dael> astearns: Anything else on cascade layers?
<fantasai> +1 to miriam's use case

[mirisuzanne]

The current Cascade 5 draft follows the initial syntax proposal on this.

Important layers reversed, with unlayered styles highest in the normal origin, and lowest in the !important origin:

1. ❗️Author
   1. ❗️@layer Reset
   2. ❗️️@layer Base
   3. ❗️️@layer Patterns
   4. ❗️️@layer Components
   5. ❗️unlayered
2. Animations
3. Author
   1. unlayered
   2. ️@layer Components
   3. ️@layer Patterns
   4. ️@layer Base
   5. ️@layer Reset

[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.