- From: Marat Tanalin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 May 2016 22:28:33 +0000
- To: public-css-archive@w3.org
> Yeah, Sass usage does not trump CSS. But there's also no reason to be hostile to the developer community when we can easily avoid such. Replacing the clear straightforward keyword widely used in almost all languages with an invented more-or-less similar one is actually probably not that _easy_. At the same time, SASS (as well as any other preprocessor) could really easily rename its `@if` or just transparently convert something like `@css-if` or `@native-if` to native CSS `@if`. That’s not a CSS problem at all. CSSWG decisions should probably not be based on the goal of avoiding preprocessor conflicts. CSS is a much more fundamental thing that require carefully weighed decisions reasonable and usable in the long term. Preprocessors can be changed at any time, **CSS cannot at all**. > Or are you asking why we don't just extend `@media` to have the full value set that I've defined `@when` to have? This one. > it would be weird; there's nothing media-like about supports queries We already have not quite media-related things like `scripting` in media queries. After all, extending `@media` is (except for placing `@else` as a subrule) what Florian has initially proposed. > It also would make the grammar very complicated. I’m not sure why this: @media ((width >= 400px) and (pointer: fine)) and supports(display: flex) {} would be more complicated than this (at least from author’s [not spec writer’s] perspective): @if media((width >= 400px) and (pointer: fine)) and supports(display: flex) {} -- GitHub Notification of comment by Marat-Tanalin Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/112#issuecomment-221726933 using your GitHub account
Received on Wednesday, 25 May 2016 22:28:35 UTC