@else in Media Queries

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.

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.

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.

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.

</Daniel>

Received on Thursday, 9 June 2016 10:34:39 UTC