Re: [csswg-drafts] [css-nesting] Problem with mixing properties and selectors (#8249)

> The problem is that the current proposal does not match the "common usage of nesting across more than a decade of preprocessors". It already diverges by requiring prefixes in a significant percentage of the cases.

And doesn't require prefixes in the majority of cases.

>  The stylesheets is these projects have all sorts of repetition and would benefit greatly from nesting. Over 90% of those style rules would require prefixing in the current proposal.

So the current proposal would save you some typing in 10% of the cases versus prefixing all the time, and for most people would save them a lot more.

> To this date I have never seen a public-facing description of the nesting syntax that accurately describes what an ident is.

This is because the full, accurate description of what an ident is *isn't relevant to the discussion*. Nobody, and I mean **nobody**, writes a selector like `\64 iv.foo`, so the fact that it's an ident (despite looking like it "starts with a symbol") doesn't matter. The ambiguous case in question is someone writing a property name (always ASCII letters, or a dash or underscore) vs a tagname selector (always starting with an ASCII letter, and usually composed of *only* ASCII letters).

> I've heard too many times to count, and even from Google implementers, that it's easier to simply prefix every nested rule.

And we've also heard at least as many times (more times, if going by poll results) that people prefer *not* prefixing every single rule. The popular sentiment seems to be clearly tilted (slightly, but significantly) towards not prefixing everything.

> And here's the elephant in the room. There is a middle ground that satisfies my objection and actually does allow the common usage of nesting. We relax the lookahead requirement. This gets rid of all required prefixes and doesn't impose any restrictions on the evolution of CSS, in fact it opens up more avenues.

The current spec is compatible with relaxing the lookahead requirement in the future. All it will do is make some currently-invalid CSS become valid; everything that's already valid under the current spec will remain so. The only thing that'll be encouraged to change is that selectors that would have started with an ident (and thus have to be spelled differently today) can be rewritten to be simpler, but every other selector remains exactly the same. And if those selectors aren't rewritten, well, they're still being spelled with existing valid CSS, not a legacy syntax that existed solely to fix Nesting parsing.

For *every other option*, relaxing the lookahead requirement in the future will mean there are now multiple ways to express *any* nested styles, and the previously-valid way (which presumably would remain valid) would become a legacy option that nobody uses, since it's longer. It doesn't seem great to leave behind an "oh yeah, you can put an `@` before your selector in nested rules, it doesn't do anything but it's valid for some reason" legacy! (Or worse, "oh yeah, you can put an @nest in front of your parent rule, but then you have to wrap its properties in a nested rule" or "oh yeah, you can put your nested rules *after* the parent rule, in another {}-block, if you want", etc.)

> The problem is that Google's position here so far has been "non-starter, we're not even going to consider this", with no data or explanation why. Even though other implementers have said it seems doable and are willing to experiment. I don't believe Google's position here is an example of engaging in the standards process constructively.

Steiner, personally, isn't interested in doing the perf explorations to figure out if infinite lookahead is viable. Other people are, both inside and outside of Google, and I feel confident that we'll get those explorations and see what the results are. If it turns out the way we all want, great, the current spec has the shortest path to accommodating that change, with the least amount of legacy cruft left by the wayside. If not, the current spec is the closest we can get to that syntax, and that has value to authors (as proven by their repeated votes and comments).

> If there were hard data showing why adding lookahead can't be done, then we'd be in a position where we have to compromise on something else, but there isn't, and we don't.

Absent any newer experimentation, what we *do* have is the statements from several years ago when Nesting was first broached, where impls were pretty sure the perf hit to parsing would be too much. These positions can absolutely change over time, but we can't *assume* they will. I'm not willing to stake the spec's survival on something that, at last check, was a multi-implementation non-starter.

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


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

Received on Friday, 13 January 2023 18:01:06 UTC