- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Oct 2023 17:04:31 +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`, and agreed to the following:
* `RESOLVED: We will address ths issue, and fix nesting to allow for bare declarations after nested rules without moving them above.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> lea: Right now, if we have bare declarations after a nested rule, current behavior is that they're shifted up to be before the nested rule<br>
<fantasai> ... which means nested rule can override them<br>
<fantasai> ... [gives example in the issue]<br>
<astearns> q?<br>
<fantasai> ... This behavior violates source order when specificity is the same, and is against author expectations<br>
<lea> https://github.com/w3c/csswg-drafts/issues/8738<br>
<fantasai> ... WebKit ran a poll showing that<br>
<fantasai> ... I ran two polls, here's link to both of them<br>
<fantasai> ... Almost 80% of authors were expecting the different behavior<br>
<fantasai> ... and those who didn't seemed to have a broken mental model around specificity<br>
<fantasai> ... things like "@supports increases specificity"<br>
<chris> that seems surprising, it breaks document order. I bet people spend time debugging this<br>
<fantasai> ... That's quite dangerous, not just that this feature has a weird behavior, but it encourages a broken mental model of how CSS works<br>
<fantasai> ... specificity is already confusing as it is, we don't need to add to that<br>
<fantasai> lea: in terms of changing behavior, not really much reason<br>
<fantasai> ... in the thread it's "this is how preprocessors work"<br>
<fantasai> lea: in the TAG we have a principle against this<br>
<fantasai> lea: other option is compatible with existing tools<br>
<fantasai> lea: we suggest that ppl go with the usability benefit<br>
<fantasai> lea: 10 years down the line, how preprocessors of today work will not matter<br>
<fantasai> lea: There was also point that maybe slightly easier to implement current way<br>
<jensimmons> q+<br>
<oriol> q+<br>
<emilio> q+<br>
<fantasai> lea: but doesn't seem that there is serious implementation complexity problem with changing to match source order<br>
<fantasai> lea: Also, jensimmons ran several more polls, which validated the same point that authors find the behavior confusing<br>
<astearns> ack jensimmons<br>
<fantasai> jensimmons: I feel pretty strongly that we should change the behavior so that it matches what people expect from CSS cascade, that later thing overrides earlier thing when specificity is tied<br>
<fantasai> jensimmons: People will not remember what SASS did 20 years from now<br>
<astearns> ack oriol<br>
<fantasai> oriol: I think Lea posted the wrong link to the poll above...<br>
<miriam> q+<br>
<fantasai> oriol: I agree that we should not prioritize aligning with preprocessors, since preprocessors can always change by releasing a new version<br>
<fantasai> oriol: authors can adopt when they want<br>
<lea> comment with polls: https://github.com/w3c/csswg-drafts/issues/8738#issuecomment-1746990112<br>
<fantasai> oriol: but this wasn't the main reason<br>
<fantasai> oriol: The question is how do you handle this?<br>
<fantasai> oriol: One was that we would just ignore declarations after nested rules<br>
<lea> q?<br>
<fantasai> oriol: but that seems problematic if they add garbage, and could cause declarations to stop working, so concerned about future-compat<br>
<fantasai> oriol: Wrapping in & doesn't work with pseudo-elements<br>
<fantasai> oriol: so I don't think this is straightforward<br>
<fantasai> oriol: While I agree that this is pretty bad and very confusing, and I would have objected to current syntax of nesting if I had realized this<br>
<fantasai> oriol: I think alternatives seem worse<br>
<fantasai> oriol: I don't see a clear proposal addressing all the concerns<br>
<fantasai> oriol: I think the current state is the lesser of the evils<br>
<lea> q+<br>
<chris> unclear why current state is "worse"<br>
<fantasai> astearns: I don't believe we're talking about discarding things after nested rules, only talking about how to keep them in and do the source order correctly<br>
<fantasai> astearns: whether wrapping in an & is the way forward, would need to work through the issues with pseudos etc.<br>
<astearns> ack emilio<br>
<fantasai> astearns: Let's go back to the queue<br>
<fantasai> emilio: I also brought another concern which may or may not be an issue<br>
<fantasai> emilio: this also assumes we go with wrapping-in-&, which seemed like most straightforward solution<br>
<fantasai> emilio: Wrapping stuff in extra rules can have surprising consequences perf-wise<br>
<fantasai> emilio: you triple the amount of selectors that element has to match<br>
<fantasai> emilio: I agree with Oriol that given the & stuff doesn't work with pseudo-elements, we either need to figure out how to fix that<br>
<fantasai> emilio: but current behavior is better than having some declarations work and others not<br>
<fantasai> emilio: we want to make sure all the declarations work<br>
<fantasai> emilio: but then the nested at-rule would also not work?<br>
<fantasai> emilio: so maybe pseudo-elements issue isn't such a great argument, since the at-rule inside would also be broken<br>
<fantasai> astearns: not sure I follow<br>
<fantasai> emilio: You have sth::before { declarations; @rule {... }; more-declarations; }<br>
<fantasai> emilio: The issue is that more-declarations gets shifted up above @rule<br>
<fantasai> emilio: but wrapping in & doesn't work, because :is() doesn't work with pseudo-elements<br>
<fantasai> emilio: but actually you have this same problem with the at-rule<br>
<fantasai> emilio: if you put bare declarations in the @rule, they also get magically wrapped i n&<br>
<fantasai> emilio: so maybe wrapping in & isn't so terrible<br>
<fantasai> emilio: it's weird if ones before work and ones after don't<br>
<fantasai> emilio: but the @rule declarations would also be broken<br>
<astearns> ack miriam<br>
<fantasai> miriam: Not a lot to add, except to say that I agree it's confusing<br>
<fantasai> miriam: I don't know why SASS did it in the first place<br>
<fantasai> miriam: Authors develop convention of putting declarations first<br>
<emilio> q<br>
<fantasai> miriam: but that's not great<br>
<emilio> q+<br>
<fantasai> miriam: we're going to have similar problems with mix-ins in the future<br>
<astearns> ack lea<br>
<fantasai> miriam: be nice to not have a totally different solution<br>
<fantasai> lea: Are we sure it would be a problem with pseudo-elements?<br>
<fantasai> lea: there's no reason to use :is() for a single &<br>
<fantasai> lea: You should just get same selector as parent. If you write something where that substitution isn't fine then you have a problem<br>
<fantasai> lea: [missed]<br>
<fantasai> lea: would enable media queries inside pseudo-elements, which seems important to allow<br>
<astearns> ack emilio<br>
<fantasai> emilio: Using :is() is kinda necessary in the sense that it allows you to avoid expansion, which prevents combnatorial explosion<br>
<astearns> q+<br>
<fantasai> emilio: but maybe special-casing the single & is OK?<br>
<fantasai> emilio: but I suggest we first fix this, at least the bare at-rule issue and then<br>
<lea> s/[missed]/If we don't already do that then we should, even aside from this issue/<br>
<fantasai> emilio: figure out if we need to do this<br>
<fantasai> emilio: It is observable due to specificity, right? This would get the combined specificity of all the items in the selector list<br>
<fantasai> emilio: if you have #foo, bar { .. } then things inside at-rule would be different specificity<br>
<fantasai> emilio: it would be weird to diverge<br>
<fantasai> emilio: it would be weird to make & work differently than in any other position<br>
<fantasai> ntim: :is() will take the higheste specificity<br>
<lea> what emilio is saying is that .foo, #bar { & { color: green } } rn has different specificity than .foo, #bar { color: green } because it's rewritten as :is(.foo, #bar) { color: green }<br>
<fantasai> emilio: which is why it's different. & will get the ID's specificity, even though that matches .foo rather than #bar<br>
<lea> q?<br>
<fantasai> emilio: assuming of course only one of the selectors matches<br>
<fantasai> astearns: One of the arguments against making this change is that people use SASS conventions and nobody puts declarations after nesting anyway<br>
<fantasai> astearns: anecdotally, when I went to search, the 2nd CSS file I looked at had bare declarations after nesting rule for SASS<br>
<fantasai> astearns: probably an accident, but don't think you can say it's not done<br>
<astearns> ack fantasai<br>
<astearns> ack astearns<br>
<emilio> fantasai: couple things emilio brought up and I think are insightful. First is that this is a current problem for @media in pseudo-elements<br>
<lea> +1 to fantasai<br>
<emilio> ... so we need to make it work with nested at rules<br>
<emilio> ... second is that it's weird that that flattening of specificity is very weird and unexpected<br>
<jensimmons> q+<br>
<emilio> ... so I think we should address both of these issues<br>
<emilio> ... but the fact that pseudo-elements are already a concern it means we need to address it<br>
<emilio> ... but it shouldn't block us from solving the cascade<br>
<emilio> ... proposal is that we agree that we're going to fix this<br>
<emilio> ... and try to figure out a right way to fix it<br>
<emilio> ... we could just make that & matches pseudos or something<br>
<emilio> ... or we could come up with another symbol that matches pseudo-elements<br>
<emilio> q+<br>
<astearns> ack jensimmons<br>
<fantasai> jensimmons: Adding to astearns, idea that people will organize their code properly, might have worked out a decade ago when sites were new and got overhauled every few years, and only a few developers<br>
<fantasai> jensimmons: but now teams are much more massive, and code lasts much longer, 5-10 years<br>
<fantasai> jensimmons: and people are scared to reorder styles, touching cascade could break things on other pages<br>
<fantasai> jensimmons: they just jam things in, and might not understand that they're adding things before or after<br>
<astearns> ack emilio<br>
<fantasai> jensimmons: so industry has changed enough that I don't think relying on good CSS organization is workable<br>
<fantasai> emilio: I agree with fantasai that we should bring up those issues and find a coherent way of fixing it<br>
<bradk> +1 to @jensimmons<br>
<lea> q?<br>
<fantasai> emilio: the most striaghtforward solution would be to make & expand to the selector list when it's alone<br>
<lea> q+<br>
<fantasai> emilio: it would solve all the relevant issues here: would make pseudos work, would make @media inside stuff work, and it would make declarations wrapped in & work<br>
<chris> also +1 to @jensimmons this makes css fragile and unmaintainable<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<fantasai> emilio: it feels a bit inconsistent, but I think it's the only reasonable solution<br>
<astearns> ack lea<br>
<fantasai> lea: Agree with emilio. even if we decide this isn't the best solution, can invent a better one<br>
<fantasai> lea: but saying that & alone should invoke the selector directly is a good optimization regardles<br>
<fantasai> lea: no reason to have :is() there<br>
<fantasai> lea: good change, solves a bunch of issues, and gives us time to solve the problems down the line<br>
<argyle> i thought :is() only wrapped & when it was a selector list, but that changed somewhere along the line<br>
<jensimmons> +1<br>
<fantasai> lea: and means implementations can update, and that avoids web compat lockdown of waiting<br>
<lea> argyle:<br>
<fantasai> astearns:OK. Let's first resolve that we want to fix this issue, that we want the cascade to use source order<br>
<fantasai> astearns: I haven't heard any arguments against this change, just details<br>
<bradk> +1<br>
<fantasai> RESOLVED: We will address ths issue, and fix nesting to allow for bare declarations after nested rules without moving them above.<br>
<fantasai> astearns: unclear if there's one or two extra issues, can a volunteer untangle?<br>
<fantasai> fantasai: The two issues are, pseudo-elements aren't handled properly by & because it wraps in :is(); and specificity is badly handled because & is wrapped in :is()<br>
<fantasai> lea: should discuss together as one issue<br>
<fantasai> astearns: OK, we're out of time, let's restart this conversation next week<br>
<astearns> s/let's restart this conversation next week//<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-1768977689 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 October 2023 17:04:34 UTC