- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Mon, 26 Apr 2010 14:08:24 +0000
- To: Anne van Kesteren <annevk@opera.com>, www-style list <www-style@w3.org>
- CC: "Sharon Newman (COHEN)" <sharco@microsoft.com>, Daniel Libby <dlibby@microsoft.com>
> From: Anne van Kesteren [mailto:annevk@opera.com] > Right. I'm saying that a CSS3 draft for @media could change it. Is there one ? Are we planning on one ? In the meantime, we agree that @media {} is invalid, yes ? > If you have suggestions for how to clarify it that would help. To me > it's > perfectly clear. :) I'm glad it's clear to you because existing implementations - 3 of them - are not exactly helpful on this specific aspect. So either they're all sloppy or this may not be as clear as it seems. I'd be happy to suggest changes once I understand what it's supposed to, especially on the OM front. > I would like to get full interoperability here, but I think that would > require moving the MediaList API in the Media Queries specification and > make it into one model. Or alternatively provide more hooks or > something > in the Media Query specification for the API, but I believe neither is > really desired by the WG as we want to move Media Queries forward. Which spec the answer goes to is an orthogonal issue to what the interop runtime behavior is intended to be. I'm really asking about the latter. This being said, if this is spread across two documents at different stages then this means that there will be 2+ set of testcases for MQ and we will not know whether two browsers interop without running them both (or all three of them if one includes HTML5's media attribute). That's unfortunate. I want MQ to move forward too, but if that means punting on OM interop issues then it's worth asking if that's the proper trade-off. More recent modules - Transitions, Transforms and Animations - include the relevant OM bits. MediaList seems to be a stand-alone interface so it could fit within this pattern as well. > >> (unless a referencing specification says something different, e.g. > >> <style media=""> is the same as <style media="all"> per HTML5). > > > > So: > > 1. @media {} is invalid > > 2. If none of the specified queries match then that is equivalent to > > 'not all' > > 3. media="" is equivalent to media="all" > > > > I think web authors definitely expect #2. But #1 may surprise them in > > light of #3. > > #3 is also invalid, but needs to be done this way for backwards > compatibility. OK, my bad. So media="" is invalid but the absence of the media attribute means media="all". That one makes sense and seems consistent with no @media implying @media all {...} and @media {...} being invalid. > I suppose. I'm open to suggestions and some help in getting it changed > in all implementations. Given the correction above, I don't think it's too bad. Setting media="" results in an invalid query so the content of the style element no longer applies. Removing the media attribute is equivalent to setting it to "all". There is no real equivalent in CSSOM i.e. something that removes an @media {...} but I think that's OK.
Received on Monday, 26 April 2010 14:09:02 UTC