Re: [csswg-drafts] [css-conditional-4] Rename @when to @if (#6684)

While I agree that @Marat-Tanalin's comment was out of line, it really is not helpful to the discussion that every comment that @nex3 leaves here (and previously in the TAG repo) is announced on Twitter via the `@SassCSS` handle, urging people to flock to the discussion or else doom will come to their stylesheets. This is not how discussions work around here, and it's not being a good discussion participant. I have more followers than `@SassCSS`, but I'm not getting them to flock here, despite strongly believing that using `@when` instead of `@if` is pretty _catastrophic_ for CSS (both as an individual decision, and as precedent), because that is not productive. This should be a reasoned debate where the best solution for CSS wins, not a popularity contest. šŸ˜•

> **In short, it would be catastrophic**. The `@if` construct is one of the oldest and most widely-used in Sass, and is particularly indispensable for stylesheet libraries which are extremely widely-used. It's likely that the majority of Sass files uses `@if` either directly or transitively. Changing its syntax would be an order of magnitude more disruptive than any other breaking change we've done, it would take years to fully land, and it would make Sass users _furious_.

Nobody is arguing that `@if` is not widely used in Sass stylesheets. I know it's widely used, in fact, [I've done the research myself](https://almanac.httparchive.org/en/2020/css#sass): `@if` is used on 63% of Sass stylesheets.
However, Iā€™m not sure how big the percentage of websites that use Sass is. When we analyzed websites that included sourcemaps, [out of approximately 5 million webpages, only about 250K included sourcemaps to Sass files](https://docs.google.com/spreadsheets/d/1sMWXWjMujqfAREYxNbG_t1fOJKYCA6ASLwtz4pBQVTw/edit#gid=1725366566). In fact, more than that included sourcemaps to CSS files, hinting at PostCSS or other preprocessors.
In general, no matter how popular a library/framework/tool seems in our industry bubble, out there even the most popular tools are used by a tiny fraction of websites, with few exceptions. E.g. [React is only used in 8% of pages](https://almanac.httparchive.org/en/2021/javascript#libraries-and-frameworks), and from [npm downloads](https://www.npmjs.com/package/react) and the like, we'd think it's used everywhere! Note that React has about double the [npm downloads of Sass](https://www.npmjs.com/package/sass), which would place Sass at about 4% of websites, about the same figure as that hinted by our Almanac analysis. 4% is sizeable, certainly not something we can ignore, but we also shouldn't be introducing major usability flaws in CSS because of it.

> I know this because we've done other, smaller breaking changes to ensure we're compatible with CSS (most recently reserving the `/` character for use as a separator as it is in CSS). Even with years of lead time, automated migration tooling, and easy and intuitive alternatives those changes have led to people flooding our feedback channels with outrage about deprecation messages and broken libraries. Deprecating `@if` would be much much worse than that.

I'll be blunt. The fact that these issues keep coming up should have hinted by now that you folks need to make a shift of direction instead of inventing syntax that looks like plausible CSS, then trying to contort CSS syntax to avoid clashing with yours.

> Workarounds like allowing `@If` are cute, but they don't address the core issue: Sass is a CSS superset, and our core promise to users is that we support all valid CSS as-is. 

This sounds like a philosophical purity argument, which is at the bottom of the [priority of constituencies](https://w3ctag.github.io/design-principles/#priority-of-constituencies).
If following your "core promise" to users is actively making CSS *worse*, maybe it's not sensible to follow that anymore.

That said, I don't think the `@If` workaround is a viable path forward. Many other paths forward have been suggested in this thread (`@-sass-if`, a global switch, etc), but the Sass maintainers do not seem to even be interested in discussing a win-win solution to this.



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


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

Received on Thursday, 17 March 2022 03:02:03 UTC