- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Mar 2022 03:29:18 +0000
- To: public-css-archive@w3.org
Lots to get to, and I'm currently in London for the TAG F2F so hard to keep up with the whole thread this week. However, I wanted to reply to @nex3's comment as she addressed me personally: > ### "You shouldn't have used `@if`" > As @tabatkins points out, this ship sailed in 2008 and we exist in a world where that decision was made. Even saying that, I think a lot of people probably don't remember what the CSS ecosystem was like in 2008. It was unthinkable at the time that one day CSS would want to add its own native `@if` rule—CSS specs evolved at a glacial pace, implementation was even slower, and the only new things that were being added were extremely specific to visual styles or browser detection. Why would it want a procedural-looking conditional? No one in any of the discussions around `@if` or any other Sass feature ever even _raised the possibility_ that it might cause a conflict. It was only in the mid 2010s that CSS started accelerating to the degree that we began thinking seriously about how to avoid conflicts in the future. This is exactly my worry. In 2008 it was unthinkable that CSS would ever add an `@if`, just like now it's unthinkable that CSS might ever want to add a looping construct. When it does, are we going to be bending over backwards again to avoid `@while`, `@each`, and `@for`? There isn't exactly much left. And what about the [inline conditionals](https://github.com/w3c/csswg-drafts/issues/5009) we have been planning to add? Do we need to avoid `if()` there as well? There is a reason Sass syntax clashes with CSS syntax: these **are** the most reasonable syntax choices and Sass simply got there first. These clashes will continue to come up **over and over** until Sass bites the bullet and starts using some kind of namespacing or other extension point to avoid clashing with future CSS syntax, and then they will need to go through the pain of migration **anyway**, so this entire thing will have been lose-lose. This discussion is not only about `@when` vs `@if` but it also sets a dangerous precedent for future decisions. Everyone should keep that in mind when suggesting to just go with `@when` and be done with it because sh*t happens. Though even if it were only about `@when` vs `@if`, I still believe this is a very significant usability cost. Even [in the very CSS WG resolution that added `@when` to the spec, it was minuted as `@if`](https://github.com/w3c/csswg-drafts/issues/112#issuecomment-920196812), because that's what people are familiar with. How many authors will make the same mistake numerous times in their stylesheets? We are entertaining the possibility of introducing syntax that will keep tripping people up over and over, and will make learning harder, to save people from the temporary pain of migration which is a fixed cost, as it only needs doing once (O(N) vs O(1) of frustration cost) and in most cases is a simple find & replace? Not to mention it may need to be done anyway down the line (see above). This does not seem at all like a reasonable cost-benefit analysis in the long run. In fact, given that my background is in usability (and specifically programming language usability), I see this as a *disaster* in the making, and a decision we will come to regret a decade later. > This does suggest one potential compromise: if CSS adjusted the syntax of `<boolean-condition>` to ensure it doesn't and never will conflict with a valid Sass boolean expression (a straw example would be surrounding it with square brackets), we could just suck up the usability pain of issue 1 above and parse both in parallel. My feeling though is that this would be much weirder from the perspective of a CSS user than simply using `@when`. Why is it that in all of these proposed solutions it's CSS that takes the usability hit, while proposed solutions for Sass are met with "but that would reduce the usability of Sass"? > Setting linguistic bikeshedding aside, it seems like the primary practical reason _not_ to use it is familiarity for users of other programming languages, but even that is on shaky ground in my opinion (and I'm doing my best to put on my non-Sass hat for this) because the languages other people are familiar with use `@if` in a procedural way that's not just inaccurate but potentially misleading for CSS. I have responded to this point at length earlier in the thread, since people keep having this idea that `if` is intrinsically imperative. It's not just procedural languages that use if, it's pretty much *every* computer language, not to mention it's closer to natural language usage. Also, it's pretty dismissive to call the concern that "when" is temporal in natural language "linguistic bikeshedding". Let's call it `@broccoli` then if language doesn't matter, shall we? > Again, Lea, I don't understand why you're so set on being combative about this. I’m not being combative, I'm arguing for what I think is best for the Web Platform, just like you are arguing what you think is best for Sass. Not everyone who disagrees with you is being "combative". Btw, I have nothing against Sass, as I said above, I use Sass myself! When Sass switched to not parsing variables used raw in custom property values and required explicit opt in via interpolation, I just went with it, and did it manually, on Sass sheets that were tens of thousands lines long, and that was far more involved than a simple find & replace. It wasn't pleasant, but it was a one-time cost and while painful at the time, I can barely remember it now. If CSS had to adjust the syntax of custom properties instead, that would be a price I'd be paying multiple times every day. No thanks. > I want to emphasize again that Sass has, in every other area that it's ended up conflicting with CSS, quietly ceded the space to CSS's syntax even when that's caused substantial pain to our users. This is actually false. It has been brought up earlier in the thread that CSS had to use square brackets in grid instead of parentheses to avoid clashing with Sass syntax. Which IMO is fine, because square brackets in this case do not significantly degrade usability over parentheses, but it was a concession. > I'm raising a red flag for this issue not out of principle or a misguided sense of territoriality, but because I genuinely believe it will be dramatically worse for Sass users than any previous syntactic conflict. > > If your anger is because I made a tweet, please allow me to apologize. My intent was not to brigade—I specifically only asked for 👍s because I wanted to demonstrate that this was a real issue affecting real users, but I hear you saying that it wasn't helpful and I won't do it again. Could we please keep drama out of this? Nobody is being territorial or angry, we just have different priorities and weightings of costs and benefits. Nobody is questioning whether this is affecting real users. **Both options will affect real users.** The question is how many × how much. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1075877417 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 March 2022 03:29:20 UTC