-
Notifications
You must be signed in to change notification settings - Fork 679
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
Comments
What about "scopes"? |
The word "scope" is already loaded, and I think there's a distinct difference in the purpose:
|
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. |
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):
So, if in a project there are two stylesheets, one with a priority of
|
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. |
@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. |
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. |
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. |
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
We can have !important and !origin-important if that's an issue. !important works likes today (onion-like) while !origin-important works per origin, |
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. |
The CSS Working Group just discussed
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" |
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".
The text was updated successfully, but these errors were encountered: