W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2016

Re: [csswg-drafts] [mediaqueries][css-conditional] else

From: Marat Tanalin via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 May 2016 22:28:33 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-221726933-1464215313-sysbot+gh@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 
using your GitHub account
Received on Wednesday, 25 May 2016 22:28:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:40:58 UTC