Re: [csswg-drafts] [css-nesting-1] & representing parent elements vs parent selector (#8310)

> Usability takes precedence over compatibility with tools, and I'm concerned that the combinatorial explosion will make nesting unusable except in trivial tiny cases.

Given that Sass has been shipping with this exact behavior for years, and they pay a *larger* cost than browsers would (Sass has to ship the expanded results over the wire, rather than just representing it in memory), I don't believe this fear is warranted. (It does make the need for a minimum/maximum spec more relevant, as in #2881.)

> Top-level selector lists are split and not handled as a single selector. This has e.g. the implication that wrapping a selector list inside :is() in order to have forgiving parsing will change the meaning in nesting

This is true. But note that "just wrap it in `:is()` is already noted to not *just* be a forgiving no-op; note its effects in `:has()`. Increasing the places where this is true isn't great, I agree.

> What about nesting .c& inside .a .b, the spec allows it, seems invalid in SASS, would it produce .c.a .b with this proposal? Regardless, .c& looks like a compound selector but it can't be freely reordered.

Sass's particular parsing/emitting rules disallow `.c&` as invalid; you have to write it as `&.c`. That's not a requirement for us, tho; I imagine Sass's limitation is related to their support for token concatenation.

So no, `.a .b { .c& {...}}` would still effectively produce `.a .b.c {...}`. The rule is "the compound selector with the & is merged with the final compound selector of the parent; compounds preceding the & are placed entirely before the parent selector, while compounds following the & are placed entirely after".

> The current spec is more natural to CSS. May it be confusing to the people who are used to a tool with a different behavior? Sure, but of course they are biased.

Right, that's the question - is the expectation formed by Sass authors the *natural* expectation, such that we can expect fresh CSS authors to do the same, and be surprised when they write HTML that violates that expectation but still matches? (Like markup options 1 and 3 in my original post.) I think that it's a somewhat reasonable expectation.

And again, since it's quite easy to regain the current spec's behavior (by using `:is(&)`) if we make this change, but impossible to gain the Sass-ish behavior if we retain the current spec, I think the threshold for reasonableness is lower than it would be if we were deciding entirely on one vs the other.

> For example, div { [title=&] {} } would also be valid.

This definitely would not be. The `&` is still, itself, a `<simple-selector>` for grammar purposes.

> In Sass it is also perfectly fine to use pseudo elements in the parent :

Yes, this would make pseudo-elements in the parent usable again.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1383215582 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 15 January 2023 18:10:01 UTC