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

> This is likely true if you blindly refactor an existing stylesheet to use nesting, or try to simply serve an existing SASS stylesheet. However, this 'all-or-nothing' attitude is not necessary and breaks with pretty much every other CSS feature ever added. I'm not saying this is an absolute deal-breaker, but it's not something we should YOLO and take lightly.

We've done it several times, recently: @layer, @supports, etc. CSS's forward-compatible parsing helps us deal with individual properties upgrading their values over time, and independent at-rules being added to the language, but it fundamentally cannot deal with a new wrapping context. Every single time we add something like this, it means new stylesheets will be *inherently* broken in old browsers.

(Note tho that this has *nothing* to do with the precise syntax we choose. *Any* new syntax for style rules, whether we spell it as a plain rule, as a `@nest`, or something else, means all such rules will be ignored in older browsers, and your stylesheets will be broken. `.foo { color: red; @nest .bar {...} background: blue; }` is also broken in exactly the same way; `@nest .foo { color: red; .bar {...} background: blue; }` is broken *even worse* since the *whole rule* gets discarded. There is *no* reasonable syntax that doesn't significantly break your stylesheet in an older parser.)

Also, if an author *does* want to limit the theoretical damage, they can either (a) put their properties before the nested rules, as the spec recommends, or (b) put a `;` after their rules (the spec doesn't recommend this because it's completely unnecessary if you just put your properties first).

> There are several situations (think small stylesheets in custom elements) where additional nested rules could absolutely be considered progressive enhancement. We are doing a disservice to users if we ignore those use cases.

I do not understand how this could be the case. Can you give an example of a stylesheet where an author might add nested styles that they are okay with not applying? Why would they write such a stylesheet rather than writing them as unnested rules? Assuming they have such a reason, why would they, specifically, write these with the unnested properties *after* the nested rules? (If they put the nested rules after, as the spec recommends and common practice follows, then only the nested rules are dropped; the properties in the top-level rule parse as normal.)

> My point is that this is a factor and a decision the group should carefully consider, not just blow off because one person thinks it's no big deal.

We did consider it, a year ago. The entire WG discussed it, we resolved that Option 1 was fine with its design constraints, then later that we preferred Option 3's even looser syntax, with attendant slightly higher design constraints. Now we have an even better approach that is both more flexible for authors and *less* restrictive on future design. Assuming that our previous resolutions weren't an affirmative vote *for* heavier design restrictions, the previous resolutions hold here; this is a better result that would have satisfied the past WG as well, had we known it was possible at the time.

This WG's work cannot be indefinitely held up by endlessly relitigating existing resolutions without new data. Continuing to imply that this is me, personally, ramming things thru the WG, rather than the entire WG reaching consensus (with a threatened objection) is both incorrect and offensive.

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


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

Received on Thursday, 6 April 2023 00:10:17 UTC