Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mirisuzanne opened this issue Apr 21, 2020 · 11 comments
Closed

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

mirisuzanne opened this issue Apr 21, 2020 · 11 comments

Comments

@mirisuzanne
Copy link
Contributor

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
Copy link

benface commented Apr 23, 2020

What about "scopes"?

@mirisuzanne
Copy link
Contributor Author

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
Copy link
Member

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
Copy link

benface commented Apr 30, 2020

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
Copy link

benface commented Apr 30, 2020

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
Copy link
Collaborator

@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
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Contributor

FremyCompany commented Apr 30, 2020

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
Copy link
Member

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.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-cascade] Better name for "custom origins"?, and agreed to the following:

  • RESOLVED: Call these "cascade layers"
The full IRC log of that discussion <dael> Topic: [css-cascade] Better name for "custom origins"?
<dael> github: https://github.com//issues/4981
<dael> miriam: Term origin has a meaning. If this is falling anywhere different or interacts in a different way it maybe desrives a name without that meaning.
<dael> miriam: Some discussion. Proposal for scope but that's loaded. Payling with "layers" or "intents" but don't know if there's one that stands out.
<dael> TabAtkins: I favor cascade layers. Distinguishes but gives right idea
<dael> jensimmons: Talking with other folks the word layer is good. Invokes photoshop for some authors and way it's used in graphic design. Layer speaks for itself, it's a good word to have in there
<jensimmons> cascade layers is :)
<dael> fantasai: How about we call them cascade layers and if we have a bette ridea in the future we file and issue
<dael> miriam: Like that
<dael> AmeliaBR: Interest in expanding so existing things in spec as origins are also cascade layers? Same arg that origin has other meanings.
<dael> fantasai: I am cautiously in favor. Have to see how this shakes out, but if similar mechanism we should rename. If they're different we have to rethink.
<dael> astearns: I think it would be cool if we could redefine things in terms of this. I don't think we should take that as a design constraint. Nice if but not a requirement
<dael> fantasai: Yeah. Switch to cascade layers and once ew figure out the proposal more if it makes sense to combine we rename origins
<dael> astearns: Hearing consensus on cascade layers. Anyone opposed?
<dael> RESOLVED: Call these "cascade layers"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

7 participants