- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Oct 2024 17:04:56 +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`, and agreed to the following:
* `RESOLVED: Reject option 1`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> miriam: since we introduced layers, we intentionally made them weaker than unlayered styles<br>
<TabAtkins> miriam: this is useful for importing third-party code, if they use layers you should be able to determine if they override you or not<br>
<TabAtkins> miriam: but authors would like a way to be more explicit, there are some cases where it woudl be helpful to import unlayered and override them<br>
<TabAtkins> miriam: there are cases where you're getting styles from a third party that you can't layer<br>
<TabAtkins> miriam: difficult to solve. three approaches that have come up in various forms<br>
<TabAtkins> miriam: if we could at least narrow on the appraoch we could bikeshed the syntax<br>
<emilio> q+<br>
<TabAtkins> miriam: 1) somehow say in your layer ordering, give a special name to the unlayered styles and let you put it in yourself<br>
<TabAtkins> miriam: conceptually simplest, but now different stylesheets can disagree about position. once you set it once, later things can't move it around. so styles can't palce themselves in relation.<br>
<TabAtkins> miriam: think we shoudl take it off the table<br>
<TabAtkins> miriam: other two are variants<br>
<TabAtkins> miriam: 2) with each layer, say whether it's above or below the unlayered styles<br>
<TabAtkins> miriam: ideally make that clear in the layer name itself<br>
<TabAtkins> miriam: maybe a !<br>
<TabAtkins> miriam: downside is now we're trakcing two layer lists separately, a little complicated mentally<br>
<TabAtkins> miriam: mayb ealso impl complicated, unsure<br>
<bramus> I like to call these “strong layers”<br>
<TabAtkins> miriam: 3) simplification of that, one named layer that's above and you can add sublayers to that<br>
<bramus> q+<br>
<TabAtkins> miriam: call it !top or something, you can write `@layer !top { @layer my-foo {...}}`<br>
<TabAtkins> miriam: that seems in some ways a good balance of the tradeoffs<br>
<astearns> ack emilio<br>
<TabAtkins> emilio: i agree we don't want #1<br>
<emilio> https://github.com/w3c/csswg-drafts/issues/6466<br>
<TabAtkins> emilio: this also interacts with this issue (above)<br>
<TabAtkins> emilio: where one potential option was letting unlayered styles compete by specificity across scopes<br>
<TabAtkins> emilio: i dont' think this has been discussed yet, but it's similar-ish<br>
<astearns> ack bramus<br>
<TabAtkins> (I don't think this touches directly on the slotted stuff, even if we end up having to define a similar solution)<br>
<TabAtkins> bramus: big +1 on solving this, authors are struggling with it<br>
<kizu> q+<br>
<TabAtkins> bramus: i lean towards option 2, has some identifier added to the layer name indicating it's a "strong" layer<br>
<TabAtkins> bramus: ! is fine, whatever<br>
<TabAtkins> qq<br>
<TabAtkins> q+<br>
<TabAtkins> bramus: with the ! you can add a strong layer into a non-strong layer<br>
<TabAtkins> astearns: do we allow ! in layer names right now?<br>
<fantasai> +1 to bramus<br>
<keithamus> q+<br>
<TabAtkins> TabAtkins: no, they're idents<br>
<astearns> ack kizu<br>
<TabAtkins> kizu: big +1<br>
<TabAtkins> kizu: i'm for third option<br>
<TabAtkins> kizu: second can be a bit confusing, because ordering layers is odd if you mix layers with ! and without<br>
<TabAtkins> kizu: I think just giving each layer a !top layer is simplest to implement and understand<br>
<TabAtkins> kizu: use-cases for this probably isn't that many, so only having one !top per layer is fine imo<br>
<TabAtkins> kizu: and each layer has its own seaprate !top<br>
<fantasai> scribe+<br>
<astearns> ack TabAtkins<br>
<fantasai> TabAtkins: I also now think #3 is best, because ordering problem where the "below" styles and the "above" styles are tracked in the same layer declaration and multiple declarations stack<br>
<fantasai> TabAtkins: that induces a misordering, where you have regular, !strong, regular, !strong -- look like they're in a single list but interwoven<br>
<bramus> q+<br>
<fantasai> TabAtkins: having an explicit layer avoids this issue, nothing gets reordered in an implicit way<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<astearns> ack keithamus<br>
<TabAtkins> keithamus: at github we just shipped layers, we ran into this issue so big +1<br>
<romain> q+<br>
<TabAtkins> keithamus: i think option 3 works, option 2 is a little onfusing, option 1 sin't great<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: making sure i udnerstand<br>
<TabAtkins> fantasai: option 2 is the name, depending on ! or not, grows the layer order away from teh unlayered<br>
<TabAtkins> miriam: no they both get strong<br>
<TabAtkins> fantasai: okay so two lists<br>
<TabAtkins> fantasai: and #3 is the same but the top list has a name<br>
<astearns> ack bramus<br>
<TabAtkins> Note my example: `@layers foo bar !baz qux;`<br>
<TabAtkins> bramus: replying to Tab about mixing layers<br>
<TabAtkins> bramus: could say that when defining, can't intermix<br>
<fantasai> fantasai: Ok, in that case I would prefer #2. Prefer that to having a magic name.<br>
<TabAtkins> bramus: so only `@layers foo bar; @layers !baz !qux;`<br>
<TabAtkins> miriam: can we reject option 1 at least?<br>
<TabAtkins> astearns: objections?<br>
<romain> +1<br>
<TabAtkins> RESOLVED: Reject option 1<br>
<TabAtkins> Note that "just don't allow mixing in the same statement" is more complicated than it looks.<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-2432886056 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 October 2024 17:04:57 UTC