- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Sat, 26 Mar 2022 02:05:16 +0000
- To: public-css-archive@w3.org
@tabatkins > Given that that's precisely what you would want to do the moment you started using the CSS `@if`, it would be a problem immediately for such a person. In practice, how? Would we not assume that if there were a conflict, Sass would have a version that addressed it before a user could reach for it? i.e. I can't envision a scenario where CSSWG picked `@if`, and Sass would not then address that conflict long before it was implemented in enough browsers that a user would seek to use it within Sass. Again, there's an argument (that I've also made) that `@when` may be the better choice just on semantics alone. I'm just saying I can't actually see the evidence that a native `@if` would cause irreparable harm to Sass users. It just wouldn't. Or if this _were_ true, then CSSWG would have avoided adding CSS functions that already existed in Sass / Less. (`min()` and `max()` existed in both Less and Sass long before they were added to CSS and caused conflicts.) And it would continue to avoid syntax clashes with pre-processors in other specs, which, as I've pointed out, [it isn't!](https://www.w3.org/TR/css-nesting-1/) So, again, I like `@when`. I think it's fine. I just don't get how `@if` is a special snowflake in terms of conflict. It's entirely inconsistent with how CSSWG has made decisions in the past and continues to make them today in other specs. -- GitHub Notification of comment by matthew-dean Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1079564062 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 26 March 2022 02:05:18 UTC