- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jul 2023 22:16:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] [css-nesting] Figure out whether we're fine with "shifting up" bare declarations after rules`.
<details><summary>The full IRC log of that discussion</summary>
<bramus> … in terms of options, we can say that when you are interleaving, you have to make additional ampersand rules to have them maintain their position<br>
<fremy> q+<br>
<bramus> … seems stragithforward but are concerned that we should fix the cascade bc it is confusing<br>
<miriam> q-<br>
<bramus> TabAtkins: main arg for no change is that this behavior is the same as what preprocessors do since they supported it<br>
<bramus> … it has not been a problem for any of them as far as we can tell<br>
<bramus> … for sass we have a maintainer confirming that<br>
<bramus> … so we dont need to worry about it I think<br>
<bramus> … it is not an issue in practice, so we should not come up with complicated solution<br>
<bramus> … MQs and non-style rules have a different behavior when nested than style rules are<br>
<bramus> … style rules put all their props in the style as ??? if it were up front<br>
<myles> q?<br>
<bramus> s/???/<br>
<bramus> … and mqs in similar put all their ?? in nested style rules<br>
<Rossen_> ack TabAtkins<br>
<bramus> … we could run into the issue that knowing when nesting has begun depends on non; it is not ituitive what to define well when we have started nested<br>
<bramus> … a rule that is unknown or mistyped can change that interpretation<br>
<bramus> … in an unpredictable way<br>
<bramus> …. to keep consistent behavior lets avoid that problem entirely, and data from preprocessors has shown it is not a problem<br>
<bramus> fremy: the last argument seems valid<br>
<Rossen_> ack fremy<br>
<bramus> … the examples emilio gave is not about nesting selectors but nesting an at-media rule, which I can do<br>
<bramus> … i feel example is convincing enough<br>
<bramus> … is implementation of sass/less supporting this use case?<br>
<bramus> … if they dont, then we are making things quite ???<br>
<bramus> TabAtkins: yes, i believe they do<br>
<bramus> … throw it into a sass playground and it will output the euiqvalent compliled code with media shifted out<br>
<bramus> … the two decls will be grouped together<br>
<Rossen_> q?<br>
<bramus> s/grouped/combined<br>
<bramus> fremy: in this case I dont feel strongly enough that we should<br>
<bramus> emilio: so fixing interleaved decls inside a grouping rule by wrapping in &-rule is easy<br>
<bramus> … fixing style rules by adding nested style rules is not too hard but … I guess we could fix it<br>
<bramus> … dont feel too strongly either way<br>
<TabAtkins> yup, today emilio's examples compiles to "the div with both properties, followed by the @media holding a div holding the conditional props"<br>
<ntim_> q+<br>
<bramus> Rossen_: so then the proposed resolution is to close no change<br>
<ntim_> q-<br>
<bramus> fremy: did anybody look into ???’s comment?<br>
<bramus> Rossen_: we did,<br>
<myles> q?<br>
<fremy> s/???/Lea Verou/<br>
<bramus> jensimmons: we do not like the proposed resolution. it does not make sense for authors right now. they expect for the later styles to apply<br>
<bramus> … i agree that a non-complicated thing is a goal, bu tshould not be what we have now<br>
<ntim_> +1<br>
<bramus> … sass is a guiding principle, but we should follow how CSS has always worked: source order<br>
<bramus> … ntim has a proposal<br>
<bramus> ntim_: emilio wrote it in the issue : wrapping in &<br>
<miriam> Here's the example in a Sass playground, for reference (sorry it's a long url): https://sass-lang.com/playground/#MTFkaXYlMjAlN0IlMEElMjAlMjBjb2xvciUzQSUyMGdyZWVuJTNCJTBBJTIwJTIwJTQwbWVkaWElMjAod2lkdGglMjAlM0UlMjAwKSUyMCU3QiUwQSUyMCUyMCUyMCUyMGNvbG9yJTNBJTIwcmVkJTNCJTBBJTIwJTIwJTIwJTIwYmFja2dyb3VuZCUzQSUyMHJlZCUzQiUwQSUyMCUyMCU3RCUwQSUyMCUyMGJhY2tncm91bmQlM0ElMjBncmVlbiUzQiUwQSU3RA==<br>
<bramus> astearns: just for my clarification: that solution will allow later rule to override the earlier ones?<br>
<bramus> [multiple]: yes<br>
<bramus> plinss: i presume for wrapping ??? in another declaration block it becomes another rule in the OM?<br>
<bramus> TabAtkins: yes<br>
<bramus> plinss: is the & still required these days?<br>
<bramus> TabAtkins: yes, you need a selector<br>
<bramus> … in terms of raw css syntax parsing, omitting ths eelector will give you a rule with empty prelude and that will fail to parse as valid style rule<br>
<oriol> q+<br>
<bramus> TabAtkins: further issue as explained in thread. anything we do that distinguished behavior on before/after nested rule means we have to define the switch for 'we are past a nested rule'<br>
<emilio> q+<br>
<bramus> … cant be ??? to cause the syntax trigger<br>
<bramus> … we dont need that concept if we dont do this<br>
<bramus> … it will potentially change the cascade<br>
<bramus> emilio: why would you have problem to just use valid nested rule as trigger?<br>
<bramus> TabAtkins: bc a new rule that does not exist in older browser that understands nesting will throw away tgha tnew rule and conclude tha tnesting hasnt started yet<br>
<bramus> emilio: and the declarations will ?? and that seems fine<br>
<bramus> TabAtkins: and the OM changes<br>
<bramus> emilio: ????<br>
<bramus> emilio: like the OM changes, but it also changes when you itnroduce new rules.<br>
<bramus> … you end up with different ??? list<br>
<Rossen_> q?<br>
<bramus> fantasai: if we have style rule with interleaved rules and declarations. lets say 3 decls at top, at-rule, and 2 decl at bottom<br>
<SebastianZ> s/???/length/<br>
<bramus> … old browser will have 5 decls appear in .style of that stylerule<br>
<bramus> … if we wrap it in ??? then in a new browser you would get first 3 decls in ./style. then at-media in .cssRules followed by - followed in it - a new style rule with last 2 decls<br>
<bramus> TabAtkins: not, but that is closely related.<br>
<dbaron> ScribeNick: dbaron<br>
<SebastianZ> s/???/an :is() rule/<br>
<Rossen_> ack oriol<br>
<TabAtkins> specifically, `::before { & {color: red;}}` does *not* apply red to ::before in today's spec<br>
<dbaron> oriol: about wrapping decls in an &: with two elements, the & can't represent 2 elements. If you have a declaration, garbage, and a declaration -- if later a new feature parses the garbage as a nested rule, then the following declaration would be grabbed and not work.<br>
<TabAtkins> and causing implicit wrapping would trigger that problem as well<br>
<matthieudubet> (is oriol mic working ? the sounds seems far away)<br>
<dbaron> oriol: while I agree the current behavior is not great, and would be a good oargument for chosoing option 4, I'm leaning more towards what tab is saying -- keeping current behavior<br>
<emilio> ack emilio<br>
<Rossen_> q?<br>
<matthieudubet> (yes that was better at the end with the new mic)<br>
<dbaron> TabAtkins: I forgot about that -- I agree that kills it harder. You can't nest if your parent rule has pseudo-elements. That's the behavior of :is(). If you tried to do this and parent selector applied styles to pseudo-elements, the implicit wrapping would just drop these declarations on the floor. That's broken at a fundamental model level right now.<br>
<dbaron> plinss: that goes away if we get rid of the :is() behavior, right?<br>
<dbaron> TabAtkins: yes<br>
<ntim_> q+<br>
<dbaron> TabAtkins: my proposed resolution is still to close with no change; I think current spec is right.<br>
<dbaron> TabAtkins: but we should see if objection from Apple is still standing<br>
<Rossen_> ack ntim_<br>
<dbaron> ntim_: I wonderif we can translate to a ? rule without using &, just using the selector text.<br>
<ntim_> div { color: green; } @media (width > 0) { div { color: red; background: red; } } div { background: green }<br>
<dbaron> TabAtkins: no, b/c that's a relative selector<br>
<dbaron> TabAtkins: those nested rules are "div div"; it's still relative to the parent rule<br>
<dbaron> hober: siblings, not nested<br>
<dbaron> myles: there's 3 sibling rules in that example<br>
<dbaron> TabAtkins: that would mean treating nesting as a preprocessor directive that rewrites into a different rule structure<br>
<dbaron> TabAtkins: we haven't been pursuing that approach since very early on in nesting. I'd like to reject trying to rewrite style things. That makes many things more complicated, like for how @media nesting works in rules. But the more we diverge the OM and the model underneath from the syntax authors write, the worse it is.<br>
<dbaron> fantasai: I think I'm not comfortable resolving on no change -- it doesn't sound like we have consensus -- but we don't have a clear counterproposal worked out. I think TabAtkins brought up many useful concerns with emilio's path. We should take some time outside the meeting to review minutes and try to think through the psosibilities. Might be down to these 2, but maybe something else. And see if we can address relevant concerns, or at<br>
<dbaron> ... least have a better understanding of what they are<br>
<dbaron> [mic out of battery]<br>
<jensimmons> +1 to what Elika just said<br>
<dbaron> TabAtkins: If you think it's valuable to more exploration, you're welcome to. I don' t think it's going to work, but you're welcome to.<br>
<dbaron> fantasai: Sounds like there's an aciton item for people with concerns about current proposal to come up with a counter proposal.<br>
<dbaron> Rossen_: No rule that we can't reopen issues.<br>
<dbaron> fantasai: I object to resolving when this many people don't like the direction.<br>
<dbaron> TabAtkins: As long as it's not a drastic change (like turning it into a rewriting rule), unlikely there will be compat concerns if it changes relatively soon, given that this is a rare code pattern. But not indefinitiely, and limitations on how far that reaches.<br>
<dbaron> Rossen_: So let's move on to the next issue. And once Apple or anyone else has a better proposal, bring it back.<br>
<astearns> fwiw I have already seen authoring advice against mixing rules and declarations this way, so if people follow that advice it lessens the compat concerns<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1642833265 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 July 2023 22:16:03 UTC