- 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