[css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order

[mirisuzanne]

Regarding CSS Cascade 5 (cascade layers), @jensimmons commented on another thread about layer ordering:

Would it be possible to allow Authors to set for themselves where in the cascade the "unlayered layer" resides? Maybe they even want to sandwich it in-between. A mechanism that's part of however they define the named layers & determine which layer is "first" & "second", etc.

By default unlayered style come first (lowest cascade priority) in the source order, but this would allow more explicit placement. Roughly (pseudo-code):

EDIT: That's no longer the case. In #6284 we reversed the behavior, and now unlayered styles have the highest priority. This explicit placement would still be useful, since there are use-cases for both approaches.

/* the default behavior */
@layer -styles>, reset, framework, components, utilities;

/* placed "in-between" layers */
@layer reset, framework, -styles>, components, utilities;

/* placed at the top/end of the layer order */
@layer reset, framework, components, utilities, -styles>;

I think that feature makes a lot of sense, and I would likely use it as an author. A few considerations to keep in mind, as we develop a mechanism for this:

• I would expect it to be repeatable for implicit sub-layers, as well the implicit outer layer
• Since all layer names are currently custom-idents, we either need a reserved name, or some way of distinguishing the provided implicit-layer ident from author-provided idents.

[Alohci]

Definitely welcome to have that level of control. If you didn't want a reserved name you could use different @ name. e.g.
@layer reset, framework;
@unlayered;
@layer components, utilities;

[fantasai]

Idk if it's a good idea, but one possibility would be to just leave out the identifier.

@layer reset, framework;
@layer;
@layer components, utilities;

[mirisuzanne]

Thinking about this a bit more: every layer (including but not limited to the default/root layer) has the potential for both direct style-rules and nested sub-layers. So this feature might be useful in nested context, not only in the root/default situation:

@layer one;
@layer;

@layer one {
  @layer two;
  @layer;
}

On the other hand, the root/default layer is the only place where authors might not be able to add explicit layering – for the sake of backwards compatibility. Once styles are layered, there is no harm in layering them further. So from that perspective, control is only needed for fully-unlayered styles.

Is it confusing if authors can specify different defaults inside each layer context? Is it more confusing if this only works at the top level, and does not work in nested contexts?

[Alohci]

It would be a shame in my opinion if it didn't work the same in nested layers.

I'm also not sure how @import url(links.css) layer(mylayer); would work if @layer; didn't work the same when it becomes nested by the import as it does when the import doesn't inject it into a layer.

[css-meeting-bot]

The CSS Working Group just discussed Allow authors to explicitly place unlayered styles in the cascade layer order, and agreed to the following:

• RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases

The full IRC log of that discussion

topic: Allow authors to explicitly place unlayered styles in the cascade layer order
github: https://github.com//issues/6323
miriam: this one is another coming from an earlier resolution
... we resolved that unlayered styles are lower pri
present-
... jen asked about whether it'd be useful to tweak the unlayered styles priority
... there's some syntax proposals in the issue
q?
... and I'd expect it to work at each level of layering
... are we happy with an empty layer rule syntax? Does this become too complex?
florian: I could see use cases for top/bottom, has any non-theoretical use case come up for in the middle?
miriam: yeah, you want components at the top and resets on the bottom, so you might want most of your styles between them
TabAtkins: Like florian I see the use case but I'm not sure we need to solve it right now
... we could resolve the CSS wide keywords as layer names in case we want to solve them
miriam: does that become a problem if additional wide-keywords are added?
ack fantasai
TabAtkins: theoretically? But we haven't added many over the years
s/resolve/reserve/
fantasai: we could also do something that isn't a keyword
... I don't have strong opinion on having to solve this now, and I'd be ok reserving the wide-keywords
s/keyword/keyword, like an asterisk/
florian: maybe I need to re-read the minutes for when we decided to switch top/bottom, I wasn't there and it seems !important could take care of jumping to the top
miriam: main reason for that was that putting them at the bottom allows progressive enhancement
... sort of like when not all browsers had media queries you'd write the specific styles in there
... but lots of people think of layers as a way to hide their resets
florian: I guess I see it more like the later but that also doesn't give me a strong use case for having unlayered styles in the middle
... I'd be fine reserving the wide keywords though
fantasai: so there's the question of whether we add it now, if we don't we might want to just reserve the keywords
miriam: if we're not sure if it's needed I'd be ok with reserving the keywords and delaying
... since it adds a fair amount of complexity
florian: what do we need by reserving the keyword? Just making them syntactically invalid?
fantasai: yeah, if you define @layer with that keyword the whole block is in invalid
florian: is that progressively-enhanceable? If you add a layer that doesn't work and then it starts working...
fantasai: why would you type it in if it doesn't work?
florian: would it be wholly invalid or just ignored?
TabAtkins: could we bring that detail back to the thread?
Emilio: fwiw it seems simpler to make the whole block invalid at parse time
RESOLVED: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases

[frivoal]

Given the resolution above, I think we all agree that @layer initial { } is simply invalid and the whole block is rejected. However, what of @layer foo, initial, bar;? Is that whole rule rejected too, or do we simply order foo and bar and ignore the non-existing initial layer?

I'm not sure, but I suspect making the whole rule invalid is safer. Otherwise, we might have people who introduce a @layer initial { } block, fail to notice that that doesn't do anything, order that layer into the middle of the stack with @layer foo, initial, bar;, and some day, if we do make the initial keyword apply in that situation, that changes the ordering of their whole page. I think this scenario would be less likely to happen if we ignore the whole rule, as then the author would be confronted with the fact that the ordering of their foo and bar layer don't work either, making it easier to notice.

[mirisuzanne]

I'm happy with that approach, and drafted some spec language around it. Not sure if we need to get an official resolution, or not?

[FremyCompany]

I noted while thinking about this in the context of #6284 that explicitly pinning "initial" as a layer name isn't very convenient, because this has to happen once, and so that first declaration needs to be aware of all the layers that need to be above or below the initial layer (which might not be possible if you are using themes / unrelated add-ons).

Another approach I have been thinking about is to have two lists independently, all layers that must be above the unlayered styles, and all who need to be below.

A strawman would be as follow (`!important following an at-layer name means to put in the list after unlayered styles):

@layer reset { article h1 { margin: 0; } }
@layer theme { h1 { margin-top: 1.2em; } }
@layer special-overrides !important { h1:first-child { margin-top: 0 } }
.main-title { margin-top: 0.2em; } }

That would yield the following order for the layers : reset < theme < /initial/ < special-overrides.

Adding !important to individual values has an effect as usual, the !important on @layer only changes the order of layers in the list, but does not propagate to the values themselves (but the change in order for the layer will make the declaration be more important).

[FremyCompany]

The advantage I see is that we are not prescribing anything here about the specifics of the default, authors can get one or the other depending on their needs.

[fantasai]

I think it's going to be useful and important to be able to have one-off layer declaration blocks that are above or below the default-layer styles, so we should have a syntax built into the @layer rule that says whether it goes above or below. Something like:

@layer [ up | down ]?  { ... }

where

• up increases the priority of normal rules (and decreases priority of !important rules)
• down decreases the priority of normal rules (and increases priority of !important rules)

[mirisuzanne]

I like the goal here, but have a few questions.

As I understand this, we would basically be creating two layer stacks — one above and one below the default — and then use the keywords to append layers to the top of either stack? What's the result of these cases?

@layer up one;
@layer down one;

Does that give us two layers with duplicate names (upper one & lower one)? Or do we only allow this keyword when the name is first used (in which case the second rule is invalid)? Another option is that we only provide this one-off syntax for truly one-off unnamed layers? In which case we likely need both the explicit placement, and the one-off option.

@layer   | [ up | down ] { ... }

I assume we don't want to allow moving layers around retroactively, so the second rule should not impact the layers defined in the first rule. That's what up/down imply to me. So if that's not what we mean, I think we should name the two layer stacks, and use their names as the keywords: something more like upper/lower or default/important or …?

[FremyCompany]

Given my proposal is to have two independent lists, I guess it's fine to have two layers named "one", one in each list.

Another way of seeing this is that one layer would be named "one" and the other "one!important" without préjudice to each other.

(Or, you know, "up one" and "down one" if we adopt fantasai's syntax)

[tabatkins]

I'm not a big of this "two lists" idea - it makes ordering less obvious (no longer order-of-appearance, but two simultaneously-calculated orders of appearance), and it brings up identity questions like what @FremyCompany referenced without good answers.

"One-off" layers that are before/after a specific significant layer are already something authors might want for any layer, but we don't allow that because it's better for the page to declare its layer order up-front; it makes the entire feature more understandable and manageable over time. I don't think the default layer is in any different in this respect.

(We do at least let styles arbitrarily inject themselves after a given layer via nesting; an @layer foo.bar{...} comes after all the "foo" layer styles. We could allow nesting under initial (assuming that's what we call the default layer) to let people achieve some of this, in a way that's consistent with any other layer.)

[FremyCompany]

Why not. I would be totally fine with

@layer initial.overrides {
   ... /*above unstyled*/...
}

But then maybe "initial" is a strange name for that layer. What are our other options? Unset?

[Alohci]

I don't follow that.

 @layer initial.overrides {... }

is the same as

@layer initial {
    @layer overrides { ... }
}

except that

 @layer initial { ... }

is implicit, so is the same as

 @layer overrides { ... }

which is (now) an underpin (down) layer, not an overrides (up) layer.

[tabatkins]

No, the point is that, because the initial layer is explicitly named, it's not implicitly removed from the layer stack.

[Alohci]

So one could do @import url("tabs.css") layer(initial); and all internal layers defined within tabs.css would then override the unlayered rules in the same file?

[tabatkins]

I suppose that would be the implication, sure?

[mirisuzanne]

Are we moving towards a consensus here?

• Accept option 2, with a custom syntax for naming 'override' layers, which are sorted above unlayered styles
• Use # as the initial syntax (and optionally bikeshed further if needed)

[bramus]

Are we moving towards a consensus here?

• Accept option 2, with a custom syntax for naming 'override' layers, which are sorted above unlayered styles

To those looking: here’s the link with the comment with all options: #6323 (comment)

• Use # as the initial syntax (and optionally bikeshed further if needed)

Would prefer to use ! for the syntax as the ! has a link with !important.

[benface]

Definitely +1 to !. I don't understand where the # proposal comes from. Well, I see it was proposed by @tabatkins here:

So yeah, never mind, I'm all for Option 2 now. I just suggest spelling it somewhat more obviously, like with #, which is both "weightier" as a glyph and already indicates important things in a selector.

But to me, # implies "ID" a lot more than it implies weight or importance.

[mirisuzanne]

Would prefer to use ! for the syntax as the ! has a link with !important.

This is the entire reason I would avoid !. Importance is a distinct feature that works differently. I'm worried that if we conflate them, we only add confusion about the differences. People are already unfamiliar with the reversing behavior of importance, and often surprised by how that interacts with Cascade Layers. I'd very much like to avoid adding to that confusion. These are not important layers. They work different from important layers.

The way this works is more similar to ID selectors being the stronger of the selectors.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order.

The full IRC log of that discussion

miriam: We've discussed this before, authors have been asking for ways to explicit place their styles cascade layer order
Miriam: The other way to think about that, is that people want to have layers above their unlayered styles
miriam: after different proposals, we sorted them into 3 categories
https://github.com//issues/6323#issuecomment-2207341923
miriam: one was an explicit name for unlayered styles
miriam: one was an explicit naming convention for putting your styles above unlayered styles
miriam: starting with a bang, up or down
miriam: the third was some explicitly prenamed layer that uses a special layer
miriam: we rejected the first option
miriam: in the discussion, we realized that options 2 & 3 are the same but with different names
q+
miriam: what the issue thread came to was option 2
q+
miriam: the proposal was that layers can start with a hash, and they would go above
miriam: hash because they don't work like importance
+1
q+
miriam: spelling can be discussed further if needed
miriam: but the gist is that layers can be named differently and they would go above
ack bramus
q+
q+
bramus: big +1, author requests all over the place, personal pref is not using the hash, but to use ! to denote that it's a strong layer.
bramus: the argument for hash is that it's an ID, but layers already have a name
ack emilio
emilio: this looks reasonable, but I wonder, what is the order of these layers relative to each other?
ack hober
emilio: seems fine, i don't care too much about syntax
hober: I like solving the use case, I have 2 issues with syntax
hober: the first is that the hash seems particularly, hash is linked to fragments
hober: more broadly, I like naming conventions for author, but I don't like naming conventions that the platform imposes
+1
hober: I'd rather have syntax that doesn't intrude into names
ack oriol
oriol: I wanted to say that this hash sign seems too related to ID selectors, I'm not advocating for ! necessarily, but hash seems weird
oriol: would that just be for named layers? would it be possible to have an unnamed layers over named ones?
miriam: this hasn't been discussed
ack kbabbitt
^
kbabbitt: I support the proposal, I would prefer not using hash, fantasai proposed a slash
miriam: the slash proposal is quite different, and it gets complicated, and it would be simpler if it stayed in the name
fantasai: not sure I understood that, it would work the same as !
fantasai: you could declare I have 2 layers that go above, 2 layers that go below, pretty easily with slash
q+
ack fantasai
fantasai, you wanted to suggest https://github.com//issues/6323#issuecomment-971910037
fantasai: and if you want to do only 1, you can just prefix with the slash
s/^/I'll also suggest ^ as an alternative to #/
ack bramus
@layer / bar { stuff }
fantasai: thinking about it as a syntax, rather than as an attachment to the name, would give more flexibility
bramus: in prev discussions we had, there was a remark that we didn't want to introduce random ASCII characters to denote special things, so I'd rather want to stick to pre-existing ones like hash or !
q+
s/syntax/separate syntax/
q+
between # and ! I would prefer !
bramus: when referring to nested layers, you can use the . notation, with the slash, I don't see how that would work
ack bramus
ack astearns
bramus: whereas with the # / !, it would work, bc it sticks with name
astearns: in my quick reading of the slash proposal, I was confused
I was assuming lists would look like `above / unlayered / below`
fantasai: this is what I had in mind
fantasai: actually it's the other way round
so it’s `below / unlayered / above`
`name/` `/name`
astearns: if we used slash, or any other char, do we have different behavior if it comes before or after?
miriam: I think with fantasai's proposal you'd get a bit of that
q?
astearns: with fantasai's proposal, we're always building a list
miriam: in the issue, i thought we had consensus, we can take it back to the issue?
q+
q+
miriam: I tend to agree with bramus, that we lose a lot of flexibility around syntax, for the reasons stated previously
fantasai: why can't you do this with slash?
@layer #name { … } vs @layer / name { … }
fantasai: I might not be understanding this well, but would exclamation at the start/end be the same thing?
ack bramus
this: https://github.com//issues/6323#issuecomment-2433062569
bramus: !important exists, it works in weird ways, it's considered a design mistake, but it's there so maybe we should embrace it
q+
but I might have misunderstood it
bramus: a lot of the authors don't understand the cascade well, if we use the exclamation point to denote strong layers, then authors could make the link
miriam: I agree with that except the conclusion. We can't brush away the fact that they don't understand layers. So we have to teach them properly importance
ack astearns
miriam: we shouldn't confuse that for users, because they work very differently
astearns: I want to disagree with the point made about avoiding random ASCII. It's not to avoid re-using random ASCII, but rather to make things explicit with words
dbaron: and a word you can search for
ack kizu
kizu: one thing I want to mention, we can probably resolve on choosing option 2 about adding _something_ to the name
+1
I'd be happy with the caret
s/avoiding random ASCII. It's not to avoid re-using random ASCII/avoiding adding random ASCII. It’s not that we should re-use existing random ASCII/
Not blocking on caret
kizu: I would prefer the current symbol, to avoid overloading symbols
s/current/caret/
kizu: ! often denotes negation in other languages too, in addition to the current meaning in CSS
As long as it’s not the #, I’m fine :)
q+
astearns: ^ might be something to start with
ack hober
Q+
fantasai: caret also points up
hober: caret as syntax vs caret as name?
hober: in the CSSOM, I don't want the caret in the name if I ask for the name
Q?
miriam: i'm ok with that, but adding a space might make it complicated for nested
TabAtkins: we need the caret to distinguish right?
hober: how about a function syntax?
qq+
`@layer foo, ^foo;`is valid
need to be able to tell them apart
ok, can we not have separate namespaces?
miriam: the issue that Tab was getting at, if we put a layer in the name foo, and one outside name foo. We have no way to distinguish them
I think that's not a good idea
hober: maybe that would be good because it would encourage explicit names
TabAtkins: but then you can't declare
miriam: it's very common to declare
ack bramus
bramus, you wanted to react to hober
bramus: I agree that the caret shouldn't be part of the name when reading it back, but it should expose it through an attribute in CSSOM
An attribute on CSSLayerBlockRule
@layer foo(strong)
point of order, maybe? this is just us bikeshedding over syntax space we've already spent time bikeshedding over in previous meetings. we had previously reached a reasoanble consensus and just needed to decide a final detail.
ack lea
lea: it seems like we're converging towards caret. Why are we optimizing for conciseness? Any symbol will be less explicit than an explicit description. What if we add more ways to control layers?
lea: if we follow this pattern, are we going to explode syntax?
lea: I'd prefer an explicit named description
+1 (weakly, at least) to keywords or functions rather than symbols
miriam: I don't think it's true that there's a lot of possible expansions, including for shadow DOM
miriam: shadow DOM cascading happens before layer cascading
miriam: we likely need something completely new
miriam: layers as a feature exists in the cascade after shadow contents in teh cascade
miriam: there is no way for stuff internal to layering that would impact something external to layering (like shadow DOM)
lea: this is about what other ways of ordering we may want to define? not about a specific proposal
miriam: I don't think there's any other ones internal to layering
fantasai: I'm basically agreeing with miriam that this idea of concept of above/below always existed, just without a syntax
fantasai: it's a feature much more fundamental, so I think it's ok if the syntax very baked
you do that by just not using a layer
lea: is there any point at defining a layer at the same level?
astearns: I don't think there is consensus, there are a bunch of new ideas. There's objection around re-using the chars. We need to go back to the issue
miriam: we have done this many times, and keep rehashing the same discussions
+1
+1
miriam: when we do reach consensus on the issue, we have new people coming up with the same discussions
TabAtkins: we need to resolve on something.
hober: a resolution would probably fail right now
astearns: the only thing that we might be able to resolve on is the caret
TabAtkins: is everyone ok with the exact proposal from miriam?
hober: idk
save with ^ isntead of #
astearns: use a single character in front of the name was the proposal
hober: the question about whether the symbol is part of the name is very relevant
hober: it's the contentious part of this
miriam: is this only for CSSOM?
hober: it's more general
miriam: it would be attached to the name, like the dot is for nested layer
s/it would be attached to the name, like the dot is for nested layer/it would be attached to the name, like the dot is for a classname
miriam: so you couldn't have a strong/weak version with foo
astearns: if it's not part of the name, and we restrict layer names to non-conflict names (strong or weak), we need some kind of processing rule
miriam: this would be a new rule
emilio: conflicting names with conflicting strongness, what happens there?
hober: I could live with overriding
miriam: neither of the options are desirable, why are we doing this?
hober: we shouldn't mess with semantics of author defined names
hober: double dash was a hack
miriam: what do we gain from this ?
`CSSLayerBlockRule.attributeThatIndicatesIfItsStrongOrNot = true | false`
astearns: I would like the CSSOM discussion to be separate from this issue
hober:This is about semantics more fundamentally, not just CSSOM
astearns: we are done with this discussion
:(

[mirisuzanne]

@hober can you make any argument here that doesn't rely entirely on theoretical purity? Is there any actual advantage to be had for authors, users, implementors, or anyone else if we separate the sigil from the name?

[bramus]

I believe we were close to settling on ^, save for the CSSOM part.

As mentioned in the call, the strongness of a layer can be exposed in CSSOM through a new attribute on CSSLayerBlockRule. That way you can have layers with the same name, but a different strongness. This makes the ^ (or whatever sigil ends up being used) not part of the layer name when you read it back, similar to the to how a . is not part of a classname.

[hober]

@hober can you make any argument here that doesn't rely entirely on theoretical purity? Is there any actual advantage to be had for authors, users, implementors, or anyone else if we separate the sigil from the name?

Coherence with the rest of CSS, in particular ID and class selectors. # and . are not part of the names.

[hober]

I believe we were close to settling on ^, save for the CSSOM part.

As mentioned in the call, the strongness of a layer can be exposed in CSSOM through a new attribute on CSSLayerBlockRule. That way you can have layers with the same name, but a different strongness. This makes the ^ (or whatever sigil ends up being used) not part of the layer name when you read it back, similar to the to how a . is not part of a classname.

That works for me!

[hober]

That way you can have layers with the same name, but a different strongness.

Though this is unfortunate.

[mirisuzanne]

Thanks. Could we:

• Resolve that ^ is syntax, not part of the name
• Resolve that CSSOM should reflect if a given layer is strong or not
• Open a new issue (if needed) to discuss disallowing strong/weak layer name conflicts

?

[Alohci]

That way you can have layers with the same name, but a different strongness.

Though this is unfortunate.

That tells us that strong layer names and weak layer names live in different namespaces. Maybe the CSSLayerBlockRule attribute name should reflect that,

[bramus]

That way you can have layers with the same name, but a different strongness.

Though this is unfortunate.

But that choice is up to authors to make.

Or could also happen by accident: If I author a strong layer overrides and also import a framework that has a similarly named (weak) layer overrides, then that’s that.

[mayank99]

I hate to re-tread older ground, but looking at past discussions, option 3 was never fully rejected. The tradeoffs of options 2 and 3 were discussed, but no resolution.

Option 3 would look something like @layer ^top.overrides, where ^top is a UA-reserved strong layer name, and overrides is an author-defined sub-layer name.

Benefits:

• More explicit, addressing the concerns re: "Any symbol will be less explicit than an explicit description."
• Clear namespace separation, so that @layer overrides does not conflict with @layer ^top.overrides.
• (Theoretical) Provides a convention for adding future UA-reserved layer names, such as ^bottom.

It was said earlier that option 2 and option 3 are the same (which would make this bikeshed), but the namespace separation is an important distinction between 2 and 3 (at least in my mind).

(I'm only mentioning this because it might help with some of the unresolved concerns. Feel free to ignore if it's unhelpful or unviable. I care more about the overall functionality than the specifics.)

[mirisuzanne]

Point two is the most compelling here. That potential namespace collision is the main issue we're left with. (Which seems like a very niche issue to me in practice, since it doesn't come up in the CSS syntax).

As to theoretical future layer features (raised here and on the call):

There are three and only three positions that are fundamental to cascade layers. Two of them already exist. We can have styles not in a layer (unlayered), and styles below those (default layers). There's only one more position available for completeness – above unlayered styles. There is not some arbitrary number of future positions at this level. If we use ^top for the current situation, then we should absolutely never consider ^bottom for anything other than the existing default behavior – which is the clear opposite.

Any theoretical future reserved layer names/features would be dealing with a different level of concern – either contained within those three positions, or extending outside them entirely (as most of the existing proposals have). If we want to leave things as flexible as possible for future developments, I would avoid expanding into a new name syntax for these fundamental positions.

After following that thread, I'm (personally) back where I was, supporting the existing proposal.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order, and agreed to the following:

• RESOLVED: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
• RESOLVED: strength is exposed in CSSOM, details tbd.

The full IRC log of that discussion

miriam: we discussed this at the f2f. we seem to have a solution in the thread. the goal is being able to name layers that are stronger than unlayered styles
miriam: the proposal is to have a character before the name that marks that a layer is stronger rather than weaker than unlayered style
miriam: we suggested the caret, a concern was raised that the character should not be part of the name. this sent us back. in that thread we've agreed on a path forward, if we're ok going with this
miriam: 1. resolving that we're taking on the caret approach at the beginning of the layer name. 2. The caret is syntax rather than a layer name.
miriam: this allows one issue to discuss, whether we allow name conflicts between strong and weak layers of the same name
q+
miriam: sounds OK?
ack TabAtkins
TabAtkins: seems fine. It would have been ok in the name but this is acceptable. for name conflicts, everything gets more complex if we try to prevent conflicts
TabAtkins: it's reasonable if weak/strong names are different in the CSSOM, works similar to important
+1
+1
miriam: seems right
+1 to the proposal, I had someone ask about this feature the other day
rossen: anyone wants to add? challenge?
PROPOSED RESOLUTION: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
bramus: also something about CSSOM?
miriam: we expose strength in CSSOM
names come in "strong" and "weak" versions, in the CSSOM there's a bool that reflects this; in the @layer rule a ^ prefix indicates it's strong
RESOLVED: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
PROPOSED RESOLUTION: strength is exposed in CSSOM, detailxz TBD
rossen: objections?
RESOLVED: strength is exposed in CSSOM, details tbd.
rossen: miriam, you're going to follow up?
miriam: sure