Re: [css3-mediaqueries] handling of unknown media types

On Tue, 10 Jun 2008 15:02:08 +0200, Stewart Brodie  
<stewart.brodie@antplc.com> wrote:
> "Anne van Kesteren" <annevk@opera.com> wrote:
>> David Baron has suggested he prefers a different type of error handling
>> for unknown media types. E.g., that 'not foo' evaluates to true and
>> instead of being ignored. This would avoid having to hardcode a specific
>> set of known media types. E.g., if 'not projection' was to evaluate to
>> true as well in user agents not supporting projection. (This would also  
>> be
>
>> more in line with existing implementations of Opera and WebKit.)
>
> It does seem more logical to me to have "not" always invert the result of
> the evaluation.  That way you can write if-then-else style media queries  
> in stylesheets:
>
> @media foo and (bar) and (baz) { }
> @media not foo and (bar) and (baz) { }
>
> and know that exactly one of the two will match.

Actually, unrecognized media features would still be a parse error and  
make the media query be ignored (though not the whole media query list).


> However, I'm not too bothered - my implementation can handle it easily
> either way, as queries are always evaluated ignoring the 'not' and then  
> the result of the query evaluation (yes, no, invalid) is mapped to a  
> final
> "yes/no" answer taking into account any not.

Ok.


>> If we do this I think it would be the first time an unrecognized IDENT
>> ends up in the CSSOM. I'm not really convinced that's a good idea, but I
>> don't feel strongly about it.
>
> It's not even just IDENT tokens: the "3d-glasses" example in the MQ spec  
> is a DIMENSION - so I have a hack that reserialises DIMENSION tokens  
> when I'm looking for a media type in the parser.

Good point. David Baron didn't mention how he'd handle syntactically  
incorrect types. (So far this didn't really matter as syntactically  
incorrect and unrecognized was pretty much the same.)


> What is the current status of the CSSOM specification - is the 30 Dec  
> 2007 editor's draft still the latest version?  Currently, I'm using that  
> draft as guidance to how to expose the media query information through  
> DOM, as that's the most complete part of the document and it seems  
> sensible to me and
> doesn't conflict with DOM L2 Style.

That's the latest version, yes. I haven't found time to work on it.


> I would like it very much if "example" serialised to "not all", along  
> with all other invalid queries - it would make my job an awful lot  
> easier and
> make the code safer.

David Baron's proposal is to treat "example" as "example" as I understand  
things.


> Currently, if I don't recognise a media type, currently I do actually  
> store it as a string, so that I can regenerate it for  
> MediaList.mediaText (DOM L2 and CSSOM).  The MQ spec says things like  
> (examples in section 3): 'When all media queries in a media query list  
> are ignored, it is the same as if "not all" was specified.'   Is it  
> talking about evaluation of the MQ only, or the serialisation too?

Just the evaluation. MQ doesn't define serialization of media queries.


> Should "example" be serialised as "example" or "not
> all"?

"example" per the proposal from David Baron. (Per the current draft it  
would have ended up being ignored and if it was the only one that was  
specified it would be serialized to "not all" most likely, to be defined  
by the CSSOM.)


> Should an invalid feature cause the whole media query to be
> discarded and replaced by "not all" for serialisation purposes?

It should just cause the media query to be ignored. So

   (foo), all

would end up as

   all

If it was just

   (foo)

it should probably be serialized to "not all" but defining te  
serialization is outside the scope of MQ at this point.


> Laying down the serialisation rules would also make it a lot easier to  
> write testcases, too.

I've written a series of testcases against the current draft (not  
including the proposal from David Baron) without the need for that:

   http://tc.labs.opera.com/mediaqueries/parsing/

I agree it would be good if these were detailed as well in due course  
though.


>> Unless more people are opposed I'll try to make this change before the
>> telcon tomorrow so we can move forward with this specification again.
>
> I don't mind which way it is, as long as a decision is made and stuck to  
> :)

Yeah :/


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 10 June 2008 13:16:19 UTC