- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 9 Jun 2016 13:58:34 -0700
- 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