- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 16:58:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order`.
<details><summary>The full IRC log of that discussion</summary>
<ntim> miriam: We've discussed this before, authors have been asking for ways to explicit place their styles cascade layer order<br>
<ntim> Miriam: The other way to think about that, is that people want to have layers above their unlayered styles<br>
<ntim> miriam: after different proposals, we sorted them into 3 categories<br>
<miriam> https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-2207341923<br>
<ntim> miriam: one was an explicit name for unlayered styles<br>
<ntim> miriam: one was an explicit naming convention for putting your styles above unlayered styles<br>
<ntim> miriam: starting with a bang, up or down<br>
<ntim> miriam: the third was some explicitly prenamed layer that uses a special layer<br>
<ntim> miriam: we rejected the first option<br>
<ntim> miriam: in the discussion, we realized that options 2 & 3 are the same but with different names<br>
<bramus> q+<br>
<ntim> miriam: what the issue thread came to was option 2<br>
<emilio> q+<br>
<ntim> miriam: the proposal was that layers can start with a hash, and they would go above<br>
<ntim> miriam: hash because they don't work like importance<br>
<TabAtkins> +1<br>
<hober> q+<br>
<ntim> miriam: spelling can be discussed further if needed<br>
<ntim> miriam: but the gist is that layers can be named differently and they would go above<br>
<astearns> ack bramus<br>
<oriol> q+<br>
<kbabbitt> q+<br>
<ntim> 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.<br>
<ntim> bramus: the argument for hash is that it's an ID, but layers already have a name<br>
<astearns> ack emilio<br>
<ntim> emilio: this looks reasonable, but I wonder, what is the order of these layers relative to each other?<br>
<astearns> ack hober<br>
<ntim> emilio: seems fine, i don't care too much about syntax<br>
<ntim> hober: I like solving the use case, I have 2 issues with syntax<br>
<ntim> hober: the first is that the hash seems particularly, hash is linked to fragments<br>
<ntim> hober: more broadly, I like naming conventions for author, but I don't like naming conventions that the platform imposes<br>
<fantasai> +1<br>
<ntim> hober: I'd rather have syntax that doesn't intrude into names<br>
<astearns> ack oriol<br>
<ntim> 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<br>
<ntim> oriol: would that just be for named layers? would it be possible to have an unnamed layers over named ones?<br>
<ntim> miriam: this hasn't been discussed<br>
<astearns> ack kbabbitt<br>
<kbabbitt> ^<br>
<ntim> kbabbitt: I support the proposal, I would prefer not using hash, fantasai proposed a slash<br>
<ntim> miriam: the slash proposal is quite different, and it gets complicated, and it would be simpler if it stayed in the name<br>
<ntim> fantasai: not sure I understood that, it would work the same as !<br>
<ntim> fantasai: you could declare I have 2 layers that go above, 2 layers that go below, pretty easily with slash<br>
<bramus> q+<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to suggest https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-971910037<br>
<ntim> fantasai: and if you want to do only 1, you can just prefix with the slash<br>
<kbabbitt> s/^/I'll also suggest ^ as an alternative to #/<br>
<astearns> ack bramus<br>
<fantasai> @layer / bar { stuff }<br>
<ntim> fantasai: thinking about it as a syntax, rather than as an attachment to the name, would give more flexibility<br>
<ntim> 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 !<br>
<bramus> q+<br>
<fantasai> s/syntax/separate syntax/<br>
<astearns> q+<br>
<kbabbitt> between # and ! I would prefer !<br>
<ntim> bramus: when referring to nested layers, you can use the . notation, with the slash, I don't see how that would work<br>
<astearns> ack bramus<br>
<astearns> ack astearns<br>
<ntim> bramus: whereas with the # / !, it would work, bc it sticks with name<br>
<ntim> astearns: in my quick reading of the slash proposal, I was confused<br>
<astearns> I was assuming lists would look like `above / unlayered / below`<br>
<ntim> fantasai: this is what I had in mind<br>
<ntim> fantasai: actually it's the other way round<br>
<astearns> so it’s `below / unlayered / above`<br>
<astearns> `name/` `/name`<br>
<ntim> astearns: if we used slash, or any other char, do we have different behavior if it comes before or after?<br>
<ntim> miriam: I think with fantasai's proposal you'd get a bit of that<br>
<astearns> q?<br>
<ntim> astearns: with fantasai's proposal, we're always building a list<br>
<ntim> miriam: in the issue, i thought we had consensus, we can take it back to the issue?<br>
<bramus> q+<br>
<astearns> q+<br>
<ntim> miriam: I tend to agree with bramus, that we lose a lot of flexibility around syntax, for the reasons stated previously<br>
<ntim> fantasai: why can't you do this with slash?<br>
<miriam> @layer #name { … } vs @layer / name { … }<br>
<ntim> fantasai: I might not be understanding this well, but would exclamation at the start/end be the same thing?<br>
<astearns> ack bramus<br>
<fantasai> this: https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-2433062569<br>
<ntim> bramus: !important exists, it works in weird ways, it's considered a design mistake, but it's there so maybe we should embrace it<br>
<kizu> q+<br>
<fantasai> but I might have misunderstood it<br>
<ntim> 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<br>
<ntim> 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<br>
<astearns> ack astearns<br>
<ntim> miriam: we shouldn't confuse that for users, because they work very differently<br>
<ntim> 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<br>
<ntim> dbaron: and a word you can search for<br>
<astearns> ack kizu<br>
<ntim> kizu: one thing I want to mention, we can probably resolve on choosing option 2 about adding _something_ to the name<br>
<bramus> +1<br>
<miriam> I'd be happy with the caret<br>
<astearns> 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/<br>
<bramus> Not blocking on caret<br>
<ntim> kizu: I would prefer the current symbol, to avoid overloading symbols<br>
<fantasai> s/current/caret/<br>
<ntim> kizu: ! often denotes negation in other languages too, in addition to the current meaning in CSS<br>
<bramus> As long as it’s not the #, I’m fine :)<br>
<hober> q+<br>
<ntim> astearns: ^ might be something to start with<br>
<astearns> ack hober<br>
<lea> Q+<br>
<ntim> fantasai: caret also points up<br>
<ntim> hober: caret as syntax vs caret as name?<br>
<ntim> hober: in the CSSOM, I don't want the caret in the name if I ask for the name<br>
<lea> Q?<br>
<ntim> miriam: i'm ok with that, but adding a space might make it complicated for nested<br>
<ntim> TabAtkins: we need the caret to distinguish right?<br>
<ntim> hober: how about a function syntax?<br>
<bramus> qq+<br>
<TabAtkins> `@layer foo, ^foo;`is valid<br>
<TabAtkins> need to be able to tell them apart<br>
<fantasai> ok, can we not have separate namespaces?<br>
<ntim> 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<br>
<fantasai> I think that's not a good idea<br>
<ntim> hober: maybe that would be good because it would encourage explicit names<br>
<ntim> TabAtkins: but then you can't declare<br>
<ntim> miriam: it's very common to declare<br>
<astearns> ack bramus<br>
<Zakim> bramus, you wanted to react to hober<br>
<ntim> 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<br>
<bramus> An attribute on CSSLayerBlockRule<br>
<astearns> @layer foo(strong)<br>
<TabAtkins> 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.<br>
<astearns> ack lea<br>
<ntim> 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?<br>
<ntim> lea: if we follow this pattern, are we going to explode syntax?<br>
<ntim> lea: I'd prefer an explicit named description<br>
<dbaron> +1 (weakly, at least) to keywords or functions rather than symbols<br>
<ntim> miriam: I don't think it's true that there's a lot of possible expansions, including for shadow DOM<br>
<ntim> miriam: shadow DOM cascading happens before layer cascading<br>
<ntim> miriam: we likely need something completely new<br>
<ntim> miriam: layers as a feature exists in the cascade after shadow contents in teh cascade<br>
<ntim> miriam: there is no way for stuff internal to layering that would impact something external to layering (like shadow DOM)<br>
<ntim> lea: this is about what other ways of ordering we may want to define? not about a specific proposal<br>
<ntim> miriam: I don't think there's any other ones internal to layering<br>
<ntim> fantasai: I'm basically agreeing with miriam that this idea of concept of above/below always existed, just without a syntax<br>
<ntim> fantasai: it's a feature much more fundamental, so I think it's ok if the syntax very baked<br>
<TabAtkins> you do that by just not using a layer<br>
<ntim> lea: is there any point at defining a layer at the same level?<br>
<ntim> 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<br>
<ntim> miriam: we have done this many times, and keep rehashing the same discussions<br>
<bramus> +1<br>
<kizu> +1<br>
<ntim> miriam: when we do reach consensus on the issue, we have new people coming up with the same discussions<br>
<ntim> TabAtkins: we need to resolve on something.<br>
<ntim> hober: a resolution would probably fail right now<br>
<ntim> astearns: the only thing that we might be able to resolve on is the caret<br>
<ntim> TabAtkins: is everyone ok with the exact proposal from miriam?<br>
<ntim> hober: idk<br>
<TabAtkins> save with ^ isntead of #<br>
<ntim> astearns: use a single character in front of the name was the proposal<br>
<ntim> hober: the question about whether the symbol is part of the name is very relevant<br>
<ntim> hober: it's the contentious part of this<br>
<ntim> miriam: is this only for CSSOM?<br>
<ntim> hober: it's more general<br>
<ntim> miriam: it would be attached to the name, like the dot is for nested layer<br>
<bramus> 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<br>
<ntim> miriam: so you couldn't have a strong/weak version with foo<br>
<ntim> 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<br>
<ntim> miriam: this would be a new rule<br>
<ntim> emilio: conflicting names with conflicting strongness, what happens there?<br>
<ntim> hober: I could live with overriding<br>
<ntim> miriam: neither of the options are desirable, why are we doing this?<br>
<ntim> hober: we shouldn't mess with semantics of author defined names<br>
<ntim> hober: double dash was a hack<br>
<ntim> miriam: what do we gain from this ?<br>
<bramus> `CSSLayerBlockRule.attributeThatIndicatesIfItsStrongOrNot = true | false`<br>
<ntim> astearns: I would like the CSSOM discussion to be separate from this issue<br>
<ntim> hober:This is about semantics more fundamentally, not just CSSOM<br>
<ntim> astearns: we are done with this discussion<br>
<bramus> :(<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6323#issuecomment-2627810047 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 16:58:10 UTC