Re: [mediaqueries] Error handling for media-condition

On Wed, 23 Sep 2015 09:36:22 +0200, Florian Rivoal <florian@rivoal.net>  
wrote:

>
>> On 22 Sep 2015, at 21:51, Simon Pieters <simonp@opera.com> wrote:
>>
>> https://drafts.csswg.org/mediaqueries-4/#error-handling seems only  
>> concerned about media queries, not so much media condition. <img sizes>  
>> uses a media condition, not a media query.
>
> This is meant to be covered in the previous section. A large subset of  
> incorrect syntax for media conditions should be caught by the  
> <general-enclosed> part of the grammar.

Right but this still doesn't answer the question about the small subset  
that does *not* match the grammar when a spec uses media condition without  
using a media query.

>
>>  Please state in the spec:
>>
>> * What should happen when a media condition doesn't match the grammar?
>
> If the failure to match the grammar is so bad that it won't even trigger  
> the general-enclosed handling, then you fail to match the syntax for the  
> entire media query (not the entire media query list), and this is  
> handled in the section you linked to.

Again, <img sizes> does not use media query or media query list at all, so  
requirements about media queries do not apply to it. However, the HTML  
spec covers this case for <img sizes> by saying what to do when it fails  
to parse, so this is defined for <img sizes>.

> If you fall into the general enclosed, then the part of   
> https://drafts.csswg.org/mediaqueries-4/#mq-syntax that starts with  
> "Each of the major terms of <media-condition> or  
> <media-condition-without-or> is associated with a boolean result, as  
> follows" should tell you how it is evaluated. This uses three-value  
> logic (true, false and unknown) rather than regular boolean logic (and  
> the note at the end of the section is meant to explain why.

Yes, it is defined what happens when it falls into general-enclosed.

>> * What should happen when a media condition has an unknown <mf-name> or  
>> <mf-value>, or disallowed <mf-value>?
>
> I believe that this is meant to be treated as unknown, like  
> general-enclosed, but I don't think the spec is actually saying this  
> explicitly, or clearly enough. It should.
>
> How about this change
>
>   "When parsing the <media-in-parens> production, the <general-enclosed>  
> branch must only be chosen if the input does not match either of the  
> preceding branches."
>
>   ->
>
> "When parsing the <media-in-parens> production, the <general-enclosed>  
> branch must only be chosen if the input does not match either of the  
> preceding branches, or if the input does match one of the preceding  
> branch but uses <mf-name>s or <mf-value>s not supported by the UA."

It seems confusing to change how the grammar matching works based on what  
is supported by the UA. Isn't it clearer to have separate statements about  
how to evaluate unknown <mf-name> or <mf-value>? Also you didn't cover  
disallowed <mf-value>.

On a related note, is it intentional that a media *query* that with  
unknown/disallowed mf-name/mf-value is replaced with "not all", rather  
than using unknown for the part that is unknown/disallowed? Is this  
supposed to be different for media query vs. media condition?

>> * If the result of a media condition is unknown, should it match or not?
>
> Quoting from the spec:
>
> "<media-condition>
> <media-condition-without-or>
> <media-in-parens>
>   The result is the result of the child term."
>
> and
>
> "If the result of a media query is unknown, it must be treated as false  
> for the purpose of matching."

Again, there is no media query, just a media condition.

> In other words, if the top-leve media condition of a media query is  
> unknown, it is treated as false. If the media conditions is nested into  
> something else, the the unknown value propagates up, and is handled  
> according to the logic described in each of the various things that  
> might contain it (media-not, media-and, media-or).
>
>  - Florian
>
>
>


-- 
Simon Pieters
Opera Software

Received on Wednesday, 23 September 2015 08:52:09 UTC