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

Re: @else in Media Queries

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 9 Jun 2016 13:58:34 -0700
Message-ID: <CAAWBYDCT7AL66O0MxEETSL4D_ABu2uO0rHs-8rQdFAO9o+BV_g@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: W3C www-style mailing list <www-style@w3.org>
On Thu, Jun 9, 2016 at 3:34 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> I'd like to explain a bit more here why I think the proposed @else
> statements for Media Queries are for the time being overkill, despite
> of the good they can provide.
>
> First, it was said yesterday during CSS WG confcall that to find the
> Media Query "applying" to a @else statement, you only need to look at
> the enclosing @media rule. That's false. You need to look at the
> enclosing rule but you also need to look at all the @import ancestors
> and even the stylesheet ancestors because the ownerNode can specify
> a Media Query. Example:
>
>
>   <style media="screen and (max-width: 500px)">
>     @media screen and (min-width: 200px) {
>       p { color: red }
>     }
>   </style>
>
> is, from an editor's or web author's point of view, really a:
>
>   @media screen and (min-width: 200px) and (max-width: 500px) {
>     p { color: red }
>   }
>
> So to find the real media query's context relevant to a given style
> rule, you need to climb up the CSS OM tree up to the html ownerNode and
> do quite a lot of operations (please note MQs are not decomposed by
> the CSS OM that deals only with one string value containing the whole
> MQ; something on Houdini's radar...). And I'm not even mentioning the
> case where the MQ is a group of media, ahem.
> Such an operation is already quite expensive, whether it's done
> automatically or manually. It's error prone, complicated and painful.

I'm not sure what you're trying to say here.  As the spec lays out
clearly in both definition and examples, @else is relative to the
*preceding* conditional rule, not an *enclosing* one.  Any enclosing
conditional is irrelevant here.

> If @else if added, it adds another major layer of complexity:
> we can only negate a whole MQ right now and not a single component
> inside a MQ so expressing the "compound" MQ relevant to an arbitrary
> style rule could be very painful is not impossible. In short it means
> that copy/paste of a given element with its stylistic information
> between two different documents could lead to MQ of that form:
>
>   @media ...a media query... {
>     /* nothing here */
>     @else {
>       p { color: red }
>     )
>   }
>
> Sorry, but that's ugly and that clearly sucks. From a UI perspective,
> wow.

I don't know what you're trying to say here. Can you flesh out the
example with more detail?

> My recommendation for @else is then the following: yes to @else but
> we need to have boolean completion in MQs first, to be able to
> serialize precisely the MQ relevant to a given style rule. That means
> allowing negated single media features, OR operations and grouping
> through parentheses. I'm pretty sure we'll have requests for that (if
> we don't have them yet) anyway.

We already have all of those.

> I did a little survey of all existing wysiwyg editors dealing with MQs,
> whether the pivot format is html or not (i.e. tools exporting to html
> but having their own proprietary format). None of them is able to deal
> with arbitrary Media Queries given their complexity. Adding @else right
> now with only a limited set of boolean operations on MQs will most
> certainly be a huge burden - up to a blocker - on visual editors.

It sounds like @media itself is a blocker on those editors for some
reason.  @else doesn't seem to make the situation any worse.

~TJ
Received on Thursday, 9 June 2016 20:59:22 UTC

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