[css-cascade] What is the migration path for Cascade Layers?

[mirisuzanne]

This is in relation to #4470 custom-origin proposal. To quote @frivoal in the transcript from our original discussion:

florian: One thing I'm a little concerned is how we figure out the syntax to have a migration path toward this from legacy CSS.
florian: In particular, a syntax ignorable by old browsers is bad because the cascade will be all mushed up; but making it hide rules from old browsers means they'll just miss a lot of code.
florian: Writing everything twice is bad, but not having an upgrade path is bad.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade] What is the migration path for custom origins?.

The full IRC log of that discussion

<dael> Topic: [css-cascade] What is the migration path for custom origins?
<dael> github: https://github.com//issues/4985
<dael> miriam: Based on convo last time some of these issues maybe should be handled with bigger questions. Some discussion of TF or community group.
<dael> miriam: First one stands out as something we could get feedback on
<dael> miriam: If we're updating cascade how are they handled in terms of migration path
<dael> miriam: Issue explained by florian well. If syntax ignorable it's bad but hiding rules from old browsers they'll miss code
<dael> miriam: No solution in mind. Playing around I can mimic rough behavior using custom properties. Don't know if it gets us anywhere, but interesting I could mimic
<dael> miriam: Open to discussion on this
<dael> myles: What did custom prop do?
<dael> miriam: Create a stack of custom prop with fallback values. Each of those acts as a level of cascade so I can decide at which point in fallback stack I make a change. ANything more forward in the stack overrides anything further down. Allows me to pass in information from different intents I set up
<dael> miriam: I do use them in other ways we talked about for custom cascades.
<AmeliaBR> `var(--overridecolor, var(--themecolor, var(--defaultcolor)))`
<fremy> I find that idea very funny fwiw :)
<dael> astearns: florian since you just joined any feedback?
<dael> florian: I'll read offline and feedback later
<dael> AmeliaBR: miriam was introducing question on the migration path for custom origins and authors being about to write stylesheets that make sense in browsers that do and don't support
<dael> AmeliaBR: miriam had said it is both bad if old browsers treat declarations as normal and bad if they ignore the declarations (quoting florian ) Agree botha re true if they're required, but one solition is to make sure both things are available in that authors can write their code in a way so that things would fallback to be regular css cascade or write code so if custom origins not supported it's ignored
<dael> astearns: If we design such that old browsers can read but not have custom origins than we can do it and put things in @supports if want ignore in older
<dael> AmeliaBR: We'd need a way of doing an @supports rule that has that option if you don't understand don't use but also have a way thtat they syntax doesn't get blocked off as unrecognized/invalid. THe options gives authors flexibility about how initial behavior is and interacts with a polyfill that uses classes to create same effect
<dael> florian: One worry is if htere's a syntax that lets browser ignore and applya s if not custom origin this is fragile depending on who ships first. If dominant market doesn't ship there's a change people will put it in there and have it not work and than it'll be that we can't update. Not working may require polyfills b/c requires authors to be careful.
<dael> myles: Another strategy is JS. It could work.
<dael> fantasai: I think either way good to have @supports so people can figure out way to handle lack of support
<dael> fremy: It could work in JS, but in JS when all stylesheets loaded you look at all css rules, count IDs, and append notes with IDs. you can know in JS make IDs in a selector so you can create an origin that way
<fremy> s/append notes with IDs/append :not() with IDs/
<dael> florian: Thing iwth @supports is we have to use it as exists today and if we introduce a new @support syou have to wait for that. Depends on how proposal works out. Maybe a property to order and you test the property
<dael> fantasai: I think we should have a more solid proposal first. Have some kind of @supports but anything beyond it's not worth discussing in the abstract. I think this is a major feature so I don't think we should try best for backwards, we should try our best to make this as good as possible and than create fallback
<jensimmons> +1 to what fantasai just said
<fremy> I agree, polyfills are possible, I am not worried, so +1 to fantasai
<dael> miriam: Polyfills rely on this falling between existing origins and specificity. It's a bit harder if they interact with existing origins to polyfill.
<dael> astearns: Sounds like we keep this open and in consideration as we work on the feature and than answer once there's a more solid proposal.
<dael> miriam: sgtm.
<dael> miriam: Same true of other agenda items
<dael> astearns: Introduce them or skip?
<dael> miriam: Either
<dael> astearns: Why don't you introduce?

[mirisuzanne]

The initial syntax proposal provides a path for polyfilling the proposed layer behavior with selectors:

Since this proposal defines Cascade Layers directly above Specificity in the cascade, but below inline style attributes, it should be possible to polyfill the entire feature using ID tags to boost specificity. Most simply stated:

#reset a { /* reset layer */ }
#base#base a { /* base layer */ }
#components#components#components a { /* component layer */ }

In order to avoid requiring a match with ID attributes in the HTML, that specificity can be generated using the :is() pseudo-class:

:is(#r, a) { /* reset layer */ }
:is(#b#b, a) { /* base layer */ }
:is(#c#c#c, a) { /* component layer */ }

The reality will require some additional finesse to avoid conflicts with existing ID selectors, but those details can be left to individual polyfills.