Re: [csswg-drafts] [css-nesting] Problems with indiscriminately wrapping all parent selectors with `:is()` (#9492)

@tabatkins 

> Yes, the `:is()`-like behavior _is_ necessary to avoid inconsistent behavior. `&`, `&.foo`, `& .foo`, and `.foo &` should all be identical wrt specificity (well, the first will have one class less, obvs). We absolutely should not try to do anything to "fix" this in some of the cases but not others.

The way `:is()` flattens specificity is a wart that was necessary because the proper thing to do was way too complicated. `:is()` is necessary for nesting to avoid combinatorial explosion, but I don't see why we should introduce this wart any more than is necessary (and where it is necessary can be statically determined at parse time).

> The pseudo-element restriction is annoying, but there's already an issue tracking that (#7433).

That issue is closed. If we want to have an issue for tracking this, it should not be a closed issue.

> > OK. Hopefully it's not already too late to carry out #8738.
> 
> For it to be "too late" it would require authors to (a) be writing decls after blocks, and (b) be depending on the "shift up" behavior differences (specificity and pseudo-elements). I suspect that's extremely unlikely.

As was discussed in the telcon, authors absolutely *do* write declarations after blocks, though depending on the shifting up behavior is way more rare. FWIW I agree it's not too late to change this.



> Actually, let me make this clearer: I will formally object to treating `& {...}` differently from `& .foo {...}`.

It may help to explain your reasoning rather than just vetoing things. 

FWIW I was seriously considering formally objecting to keeping the shifting up behavior (the closest I ever got to an FO in my 11 years in the WG), but in the end discussion was far more productive and an FO was not necessary. 😊

> Happy to work on the issues via _some other mechanism_ (like Anders says, wrapping them in a different kind of rule instead - let's re-re-revive `@nest`!), but I'm absolutely not ok with having different behavior based on the exact selector used.
> 
> Do we want to repurpose this thread to discussing how to solve the "naked property nesting inherits some of Nesting's weaknesses" issue, or open a fresh issue?

I think it's more important to establish why these weaknesses are necessary in the first place, and explore ways to get rid of them before we decide to add even more syntax to CSS to do similar but slightly different things (which is an antipattern from a UX/DX perspective).


-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9492#issuecomment-1779642233 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 16:27:17 UTC