- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Thu, 24 Mar 2022 22:07:17 +0000
- To: public-css-archive@w3.org
@synecdokey It's a fair point. I suppose there's a fair amount of assumption that the keywords would need to co-exist, and that there's inherent conflict. But... there actually wouldn't be in practice. 🤔 Because both usages would not happen immediately for the same stylesheet author. It could be like: 1. Sass renames `@if` to `@when` (or something else) 2. You run the migration tool and upgrade Sass. 3. Now you can use native `@if` 4. If you don't want to use native `@if`, you stay on an older Sass version. Basically, it _wouldn't_ break builds. Existing files w/ existing Sass dependencies would continue to compile just fine. It's just when a Sass user wanted to use a native `@if` that they would need to make upgrade choices, which could be automated. Basically, it doesn't break live code, because there's not an external compiler you don't control, and it doesn't break builds, because languages / existing files are inherently tied to a fixed compiler version. It's more like a "future compatibility question". So I wonder if people have been thinking about this in the wrong way. If browsers added `@if` today, it wouldn't cause anyone's Sass code to break anywhere. It's just you would need a solution when you wanted to _output_ `@if` I'm just spitballing, I'm not sure it's the best choice, but just to point out that choosing `@if` wouldn't actually break anything for any users. -- GitHub Notification of comment by matthew-dean Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6684#issuecomment-1078428931 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 24 March 2022 22:07:18 UTC