W3C home > Mailing lists > Public > www-style@w3.org > June 2016

Re: @else in Media Queries

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 13 Jun 2016 11:34:07 -0700
Message-ID: <CAAWBYDACv_h0jszKUEJBYPPU0=SVSqSsWzxeKs8txeiP-Urvjg@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: www-style list <www-style@w3.org>
On Fri, Jun 10, 2016 at 11:34 PM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> On 10/06/2016 22:12, Tab Atkins Jr. wrote:
>>>       - complexifies automated media queries management
>>
>> What is "automated MQ management"?
>
> Given an arbitrary document with arbitrary stylesheets, where should
> I insert a new MQ to see the style rules it contains have visual impact,
> ie. be the ones that win the cascade? Even for handwritten CSS, this
> is an enormous issue.

That's a very difficult general problem, and @else does not make this
any more complicated.  @else is just a *simplification* of the case
where you want two or more mutually exclusive conditional rules.  Any
situation you can get into with @else, you can get into with manual
@media/@supports today, it's just harder to read/write today.

>>>       - can't always express the @else case by a MQ
>>
>> Why is this a con?
>
> Turn a standalone @else in a valid @media.

Just copy the head-rule's condition and wrap it in a NOT.  The
difference in semantics is fairly negligible when you're not
explicitly trying to create two mutually exclusive conditions.

And if, for some reason, it really is important for you to capture the
exact semantics, you can always just use an empty head rule and then
use your @else like normal.  Whatever's easier to read and maintain.

(Sometimes in actual programming languages I leave an empty condition
around, because it's the most expressive way for me to write
something.)

If it does turn out to be necessary, we can add functions for dealing
with unknown values explicitly in the future.

~TJ
Received on Monday, 13 June 2016 18:34:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC