- From: Paceaux via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Jul 2024 03:43:23 +0000
- To: public-css-archive@w3.org
@mirisuzanne Thank you again for clarifying. I really appreciate you using the term, "chained `is()` metaphor," because that really helps solidify how one should understand what is happening. I would strongly encourage the specifications to use this terminology to help CSS users understand the mechanics. > As far as I can tell, only the & should ever be treated 'like' :is(<parent-selector>). There is never any need to think of the nested selector as though it is wrapped The reason I made the conclusion, "oh, the parent should also be wrapped in `:is()` is because one of the examples suggests this: ```css /* multiple selectors in the list are all relative to the parent */ .foo, .bar { color: blue; + .baz, &.qux { color: red; } } /* equivalent to .foo, .bar { color: blue; } :is(.foo, .bar) + .baz, :is(.foo, .bar).qux { color: red; } */ ``` I'll weed out the parts that aren't related, and it looks like this: ```css .foo, .bar { + .baz { color: red; } } /* equivalent to :is(.foo, .bar) + .baz { color: red; } */ ``` [I ran some tests on specificity](https://codepen.io/paceaux/pen/MWMWzYL), and it appears that any time the parent selectors are a list, they get wrapped in `:is()`. Chrome's dev tools reports specificity and I experimented with my final ruleset and looked at the specificity. ```css .oof { + .baz { /*specificity 0,2,0*/ color: orange } } .oof, div.oof { + .baz { /* specificity 0,2,1 */ color: orange; } } ``` Is it more accurate to say, "the `&` should be thought of as similar to :is(<parent>), and any instance where the parent is a list should also be thought of as `:is(<parent>,<parent>`? _If_ that's the case, do you think it might be easier to simplify that "metaphor" as, "in cases of nesting, always think of the nested parent as wrapped in `:is()`. Your explanations have been great and I've found them very insightful; I really appreciate you correcting my assertions. Do you think that Section 3.2's examples could be rewritten and organized so as to only make one clear assertion at a time? The examples written in the spec are very long and often make several assertions in a single example. Complex (using `&` or not with multiple lines) come first, and simple examples (not using `&`, only being type selectors) are in the middle, while examples for nesting at-rules are at the end. [Sass' own documentation for nesting](https://sass-lang.com/documentation/style-rules/) does a great job of providing increasingly-complex examples. Do you think the CSS spec could possibly consider even using Sass' exact examples? I know that the goal here is to not conflate or confuse CSS Nesting or Sass Nesting because the mechanisms are different. But given that Sass got there first (¿probably?), leaning on how Sass has documented behaviors like `&` with first simple examples, and then gradually increasing complexity, could help folks more clearly understand the differences. I'd love to see section 3.2 arranged so that the first examples had nothing to do with `&` at all, then went to lists in the parent, lists in the child, and then the special behavior of & all alone, then &&, and then the output preceding and following selectors. That would make it so much easier to track when `:is()` is relevant and when expectations should change. -- GitHub Notification of comment by paceaux Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10523#issuecomment-2216369676 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 July 2024 03:43:24 UTC