[css-cascade] Better name for "custom origins"?

[mirisuzanne]

This is in relation to #4470 custom-origin proposal.

This needs bike-shedding. The term "origin" is already a loaded term. This is really a layer of cascade between origins and specificity. There is some similarity to design layers, though it's not an exact comparison. Another suggestion was "sources".

[benface]

What about "scopes"?

[mirisuzanne]

The word "scope" is already loaded, and I think there's a distinct difference in the purpose:

• A scope generally relates to DOM structure, where an author wants something like:
  • styles that only apply in a specific nested component DOM
  • or the "first layer" of that component DOM, but not nested components
  • extra weight given to the most "proximate" ancestor selector
• These "custom origins" represent layers of intent, not specifically related to DOM structure:
  • weighting a "theme" over a "framework" over a "reset", even when all three are applied globally
  • might reflect literal "source" of styles (app, design system, 3rd-party framework, etc) but not always

[tabatkins]

This is really a layer of cascade between origins and specificity.

Is it? I mean, we could invent another category to slot in there, but what benefit do we gain from that?

I think we'd actually lose some functionality by doing so. Considering it as a separate layer means that normal vs !important still works per the normal origin rules, meaning that an !important rule definitely wins over an normal rule, regardless of the relative orders of the custom "layers". I think at least some of the use-cases for custom origins want this to not be the case, and instead for a set of rules to have both its normal and !important rules scoped together and "weaker" than another set of rules - in particular, the "upgrading CSS, so we put the legacy CSS into a weaker origin and let the new CSS live in a stronger origin" seems to want that.

[benface]

These "custom origins" represent layers of intent, not specifically related to DOM structure

You're right, "scope" implies a different concept.

The way I see it, it would definitely be extending the first layer of the cascade (currently named Origin and Importance), rather than creating a new layer. However, I think "origin" should only be referring to one of "user agent", "user", and "author", while "importance" should be either "important" or "normal". What if, on top of these two concepts, we added the concept of "priority" for stylesheets / declarations (possibly only for the "author" origin, but could be for any origin). So effectively this would be adding entirely new "buckets" in the "Origin and Importance" layer, which should be renamed to "Origin, Importance, and Priority" or something else. It would look something like this (assuming this is for the "author" origin only):

• Transition declarations
• Important user agent declarations
• Important user declarations
• Repeat the following for each value of "priority" used, in descending order:
  • Important author declarations
  • Animation declarations
  • Normal author declarations
• Normal user declarations
• Normal user agent declarations

So, if in a project there are two stylesheets, one with a priority of 0 (the default) and one with a priority of 10, the buckets would look like this:

• Transition declarations
• Important user agent declarations
• Important user declarations
• Important author declarations of priority 10
• Animation declarations of priority 10
• Normal author declarations of priority 10
• Important author declarations of priority 0
• Animation declarations of priority 0
• Normal author declarations of priority 0
• Normal user declarations
• Normal user agent declarations

[benface]

What if, on top of these two concepts, we added the concept of "priority" for stylesheets / declarations (possibly only for the "author" origin, but could be for any origin).

I just realized this doesn't work. It couldn't be for any origin, it would only be for the "author" origin, but I think that satisfies all the use cases that prompted this proposal.

Also worth mentioning that "priority" could be negative.

[fantasai]

@jensimmons and I discussed the idea of renaming "cascade origins" to "cascade layers", generally. Another option could be "levels".

I agree with @tabatkins that this new feature should be the same function as the existing cascade origins function.

[tabatkins]

I'm not certain I think it necessarily needs to be the same as cascade origins, if we're okay with slightly reinterpreting !important in a custom cascade layer.

Here's my mental model for how this could work: specificity gains a fourth value, above IDs, which is the cascade layer.

When you set up the cascade layers for your page, you specify where both the normal and the important rules go in the ordering. (Possibly if you don't specify an !important version, we can default it to inside-out ordering.)

Then, any rule in a custom layer always lives in the author origin, and get shifted into one layer or another based on !important or not. Custom-layer styles never go into the author-important layer.

Then because this is a specificity alteration, not an origin alteration, we avoid the proliferation of origins that would make shadow-scoping complicated.

[fantasai]

Custom-layer styles never go into the author-important layer.

This wouldn't layer correctly with animation styles, which are below !important rules and should continue to be so even for rules inside a custom cascade layer.

[FremyCompany]

I globally find Tab's proposal attractive.

One addition maybe would be a specially reserved "reset" level, which would always be first in the list, and be applied even if the final style is revert (these origins cannot use revert this is considered an error)

Custom-layer styles never go into the author-important layer.

This wouldn't layer correctly with animation styles, which are below !important rules and should continue to be so even for rules inside a custom cascade layer.

We can have !important and !origin-important if that's an issue. !important works likes today (onion-like) while !origin-important works per origin,

[tabatkins]

This wouldn't layer correctly with animation styles, which are below !important rules and should continue to be so even for rules inside a custom cascade layer.

Unfortunately this would conflict with the "new styles win over all old styles" use-case. :/

It's not a problem for most (all?) of the other use-cases tho, granted.