- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Mar 2023 22:27:36 +0000
- To: public-css-archive@w3.org
> That the adoption/usage of &div will only be determined by looking at a use counter in Chrome, ignoring that PostCSS and others exist. And ignoring the reality that people will continue to transpile their nested source to non-nested CSS for years to come. Yes, we *intentionally* do not pay attention to preprocessors that attempt to lead the spec before browser support is solidified, *because* "ships in a major browser and sees measurable use" is the point at which we consider a feature stable. Going ahead of browsers means you're working with Explicitly Unstable And Possibly Bad Ideas. I'm being very firm here for a reason - it's *incredibly* hostile to all other parties to attempt to unilaterally thrust an early, unstable version of our work into "frozen in practice" stability. The browsers all have explicit steps in their launch processes for seeking and ensuring consensus and stability, and advance without those guarantees very carefully and deliberately. PostCSS and related tools do not meet that bar. It is also the case that, as a general rule, such tools do not impose nearly the "frozen in practice" weight that a browser does. They generate valid old-style code, which will continue to work as intended regardless of how we change the feature the preprocessor is implementing. The tool itself will continue to *accept* CSS written for it, regardless of how we change the spec, so long as authors don't update the version. The *only* issue arises when authors are updating their tool version but not maintaining their code; *then* their sites will break. But that's the case for *every* tool they use, for any purpose whatsoever. A syntax change is a major-version bump in semver; you must be ready to fix breakage if you accept the bump. ---------- Separate from the above, as Natalie said, if we make this change and PostCSS/etc follow, then the `&div` syntax will just become invalid in them. This means those tools *can* offer migration tools: auto fixup, warnings, source rewriting, etc. This is not the case for Sass/etc here - if we leave the spec as-is, then it *conflicts* with valid Sass/etc code that has specific, unreproducable-in-CSS behavior. And we know that it's pretty *common* behavior in Sass/etc. Luckily it's not the end of the world for these tools - `div&` *is* legal to write today in CSS (so long as it's not at the start of the selector, but that restriction'll drop), so they *could* just continue to say that `&div` has its current meaning in those tools (concatenation) while `div&` means the same as CSS. This would be a behavior divergence from CSS, but as Natalie noted, it's a pretty rare situation in practice anyway. But, since the only reason for relaxing the "type selectors must go in front" restriction was to deal with the parsing restrictions that earlier versions of Nesting imposed, and those restrictions no longer apply, *and* reverting to the old type-selector behavior would avoid a behavior difference with a decade-old Sass syntax that we're intentionally invading the syntax space of, it'll be nice to make the change if we can. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8662#issuecomment-1492678780 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 March 2023 22:27:38 UTC