- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Oct 2023 17:02:25 +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> TabAtkins: we got a resolution last week?<br>
<bramus> lea: yeah, to solve the issue<br>
<bramus> … not sure if this issue should be on the agenda, prolly the new one 9492<br>
<bramus> Rossen_: Is that one ready? dont see agenda+<br>
<bramus> … we can discuss sth else<br>
<bramus> lea: orig issue was on the agenda because impls are shipping<br>
<bramus> … changes should be sooner than later in that case<br>
<bramus> … TabAtkins made point that authors dont hit it frequently<br>
<bramus> … so maybe we have more time?<br>
<bramus> … changing shipped behavior tends to be difficult though<br>
<bramus> … the longer we wait, the more work to change it later<br>
<bramus> TabAtkins: at the end of the OG issue, interaction with future planned things like mixins does mean we prolly dont want to shift<br>
<bramus> … I do agree this is worth fixing and should be fine to fix relatively quickly for reasons lea explained<br>
<bramus> … we should figure out secondary issue but happy to stick with last weeks resolution that they get wrapped instead of lifted<br>
<bramus> Rossen_: remaining Q then is if we discuss the new issue now or not?<br>
<bramus> lea: the discussion died down after a few days and TabAtkins said he would reject … would be nice to start discussing<br>
<lea> q?<br>
<lea> q+<br>
<oriol> +1 to Tab<br>
<bramus> TabAtkins: I explained why immediately in preceding comment. we cant treat selectors in ?? fashion based on how they were referefenced in nested selector. inconsistent and confusing.<br>
<Rossen_> ack lea<br>
<bramus> lea: the way the :is() flattens specificity (largest one) was most reasonable one but it is a wart. the less we expose authors to it, the better<br>
<TabAtkins> `.foo, #bar { & .baz {...} .baz & {...} }` <-- these two nested rules absolutely need to have the same specificity<br>
<TabAtkins> And `.foo, #bar { & {...}}` should have the same specificity as the above, minus one class.<br>
<bramus> … i dont think there are any use cases that actually require flattending spcfcty<br>
<bramus> … the less authors hit that, the better<br>
<oriol> q+<br>
<bramus> … similar to generating a math expression: not including () when you dont need to<br>
<bramus> TabAtkins: yes, but the wart exists<br>
<fantasai> But `.foo, #bar { & { ... } }` should have the same specificity as `.foo, #bar { ... }` is the argument<br>
<Rossen_> ack fantasai<br>
<bramus> fantasai: I agree we should solve soon. the way specificity works with is(), definitely not expected behavior.<br>
<bramus> … nesting should not cause selectors to get flattened<br>
<bramus> … if you have a class and an id, they mathc based on what they match<br>
<bramus> … as soon was you start nesting they get flattened … definitley not expected<br>
<TabAtkins> (And note that it's absolutely too expensive to not flatten *in general*, this was well-established in previous Nesting discussion. It makes matching exponential-time.)<br>
<bramus> … & foo and foo & should have same specficity<br>
<lea> Indeed, even beyond shifting, the fact that `.foo, #foo { h1 { color: red } }` flattens specificity is *incredibly* confusing (and wouldn't be solved by not using `:is()` when not necessary)<br>
<bramus> … .foo.bar and .foo, .bar ???<br>
<fantasai> .foo, #bar { color: blue; @media print { background: yellow; } }<br>
<lea> e.g. it's common to do things like `button, .button { &:hover { } }`, now `button:hover` has the same specificity as `.button:hover`!<br>
<lea> q?<br>
<bramus> fantasai: these decls should have same specificity when the match, but they dont right now<br>
<bramus> oriol: I agree with tab. idea of treating lone & vs when used in bigger selector seems incosistent and confusing<br>
<lea> q+<br>
<bramus> … i am confused. the main probl is with pseudo-els which cant be matched by &, but discussion seems to be shifting to specificity<br>
<TabAtkins> I had a proposal for just `@nest { ...props here }` that is semantically identical to `& {...}` but doesn't impose the restrictions.<br>
<bramus> … i dont really see the flattening as a blocking thing<br>
<bramus> … maybe i am missing something<br>
<bramus> … seems necessary in complex cases of nesting<br>
<bramus> … if you need to check all possible combinatorial expansion to know the specificity, then it seems problematic<br>
<bramus> … main problem was with psuedo-els though. could be possible to have & also match pseudo-els<br>
<bramus> …which would fix this<br>
<Rossen_> ack lea<br>
<bramus> lea: I wrote an example ajust above, wher authors can trigger this<br>
<bramus> … button and .button<br>
<bramus> … headings and classes of headings<br>
<bramus> … common to style element names with class names<br>
<TabAtkins> (I would also be fine with defining `&` can match pseudos, fwiw. That wouldn't solve the specificity flattening, tho, so I lean more towards a solution that does more, and leave `&` consistent with `:is()`.)<br>
<TabAtkins> q+<br>
<bramus> … right now with the button example, the button:hover would hav especificiy of .button:hover<br>
<bramus> … @nest would only solve the issue with internal rewriting<br>
<bramus> … even proposed solution with ??? that would also not fix the issue<br>
<bramus> … i disagree with myself from last week<br>
<bramus> … we should solve root cause<br>
<bramus> … one idea: we introduced :is() to avoid combo explosion.<br>
<emilio> q+<br>
<bramus> … what if instead of wrapping with :is() we do some smarter rewriting that retains specificiyt<br>
<Rossen_> ack TabAtkins<br>
<bramus> TabAtkins: unforutnately the specifiity issue is not fixable<br>
<lea> q?<br>
<lea> qq+ to reply to TabAtkins<br>
<bramus> … it depends on the length of th eseleector list and number of levels<br>
<bramus> … but, i think we can solve being able to put naked props<br>
<bramus> … after rules or inside @media et al<br>
<bramus> … that should be solved<br>
<bramus> … its not great today<br>
<bramus> … even more wrapping will make it worse<br>
<bramus> … ?? is too expensive in general case<br>
<bramus> … flattening specificity also<br>
<bramus> … even if authors often produce the same specifity the wont always<br>
<bramus> … so the general is still as expensive<br>
<Rossen_> ack lea<br>
<Zakim> lea, you wanted to react to TabAtkins to reply to TabAtkins<br>
<bramus> lea: i was proposing to drop is()<br>
<bramus> … what if we do some smarter rewriting, to retain specificity?<br>
<bramus> … it would be very productive to have an eexample of combinatorial explosion<br>
<bramus> TabAtkins: nothing is forcing authors<br>
<bramus> … example is make a selector list of n selectors and nest it a few times<br>
<bradk> Just a thought, but maybe flattening ‘button, .button’ into the same specificity as .button isn’t necessarily a bad thing.<br>
<bramus> … problem becomes exponential to resolve inner property<br>
<Rossen_> ack emilio<br>
<bramus> emilio: another potential solution would be to make is specificity dynamic, but we resolved against that in the past<br>
<bramus> … you would still need to match all selectors<br>
<bramus> … seems very non-triviail … like make the parent selector behave as dynamic specificity<br>
<lea> it does introduce a new dependency for calculating specificity, where it depends on the element matched<br>
<TabAtkins> `a, .a, #a { a, .a, #a { a, .a, #a { ...}}}` <- already 3^3 possible specificies<br>
<bramus> … i seem to recall webkit implemented ?? but that also has a lot of problems<br>
<emilio> s/??/:matches()/<br>
<bramus> Rossen_: good discussion, and we are at time<br>
<bramus> … lets end here and continue discussion in the issue<br>
<bramus> … feel free to bring back next week when enough progress<br>
<bramus> … enjoy the rest of your week<br>
<bramus> topic-end<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-1779696636 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 October 2023 17:02:27 UTC