- From: Daniel Upstone via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Jan 2023 19:01:38 +0000
- To: public-css-archive@w3.org
> You are missing an important detail: Changing it will most likely make sure it isn't rolled out at all. Not delay it; stop it. It's unlikely we'll want to implement something that blows up into exponential memory use so easily and without warning, and if nothing else is acceptable to web developers, seemingly the only solution is to do nothing. Not missing it, I'm just not convinced the implementation is such a hurdle that it won't eventually be overcome under the weight of developer needs, so I don't think it's a valid argument for the simpler option to be locked in and rolled out. If implementation stops, but one day starts again, is that not a delay? (I have no doubt it is a difficult challenge that requires lots of rethinking, and potentially large architectural changes that are simply not workable for implementers currently.) > I don't think the current spec is inconsistent with `:has()` if that's what you mean. No, I was just comparing this situation as a developer desire for a feature that was long thought too expensive to implement, but a way to achieve it was eventually found. > Most nested selectors have & at the beginning, so they are not affected by this. That's fair for the most part, but I wouldn't like to see future emerging patterns and features hindered by that metric. > The natural thing is that .a + & selects some element preceded by .a. I guess that SASS has another behavior because back then :is() didn't exist and being a preprocessor it couldn't do better. Where does this interpretation of "natural" reading come from? Is there something already in CSS I'm missing that would suggest `&` should be the selected element, and not the selector? I know the latter is heavily influenced by preprocessor experience, but also feels natural for what most want nesting for (sugar for reducing multiple selectors). Functional pseudo-classes and `:scope` are the exceptions to the usual reading of a selector, so it seems odd to me there would be an assumption that nesting is also an exception without it being explicitly shown which type of expception using one of those. It would seem the current behaviour is a big foot gun, requiring a large list of "gotchas" in learning resources (especially with the selectors being forgiving unlike most of CSS). > Leaving it as a preprocessors only feature might be better for authors? Avoiding quoting your entire comment, I'm not against this, but it has lots of short and long term issues that you touched upon. If this spec is to go ahead as it is, it serves a mostly different purpose to what preprocessors are doing (which I understand was the original intent, but this was certainly co-opted for its similarity to preprocessor nesting as a desirable feature), which means the syntax needs to clearly differentiate itself from preprocessor nesting, so that they can easily coexist and not cause confusion (which many clearly didn't know would need to be the outcome when feeding back on syntax). I imagine that means either picking one of the less favourable syntax options, or preprocessors changing their syntax moving forward, but I still think someday we will end up in a situation where both exist in CSS itself, so may as well plan carefully for that. To avoid going too off topic here, see my proposed solution in https://github.com/w3c/csswg-drafts/issues/8329. -- GitHub Notification of comment by zealvurte Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8310#issuecomment-1387605819 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 January 2023 19:01:40 UTC