Re: [mediaqueries] Error handling for media-condition

> On 23 Sep 2015, at 17:52, Simon Pieters <simonp@opera.com> wrote:
> 
> 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.

Which specs do that? As far MQ4 is concerned, media-conditions are an internal construct used to explain the grammar of media queries. Error handling is defined if you take the whole package. If you don't, I'd argue that the onus of defining how things work falls on to the spec referring to the individual parts.

Then again, given that media features are a legacy thing that didn't work all that well, maybe we should facilitate reuse of media conditions. Should we also introduce the media-condition-list, like a media-query-list but without media-types, with a note saying that new specs without a legacy content dependency on media-types should use these rather than media-query and media-query-list?

>>> 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>.

For for HTML we're covered. Any other spec using it?

>> 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>.

I'm ok with a separate statement if that would make things clearer. As for disallowed <mf-values>, I'd argue it should be false, but I could be convinced it should be unknown. Either way this is a break from MQ level 3, which treats it as a syntax error invalidating the whole media query, but we already decided to move away from that with the introduction of general enclosed and 3-valued logic.

Proposal:

  "<media-feature>
The result is the result of evaluating the specified media feature. If a syntactically valid <media-feature> uses <mf-name>s or <mf-values> unknown to the User Agent, the result is unknown. If the mv-value is not allowed for the specific media feature, then the result is false."


> 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?

I think that's a leftover from before the 3 valued logic was introduced, and that we should remove this in favor of the proposal above.

>>> * 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.

I had missed your point earlier, but I get it now. I still think specs that uses concepts from media queries other than the top level concepts for which error handling is fully define will still needed to handle things on their own, but we can probably make things a bit easier for media conditions, since it is a reasonable bit to reuse:

"If the result of a media query is unknown, it must be treated as false for the purpose of matching."

->

"When the result needs to be evaluated in a context where only the boolean values true and false are allowed (such as using the result of a media query for the purpose of matching), then unknown must be treated as false."

Would this help?

 - Florian

Received on Wednesday, 23 September 2015 09:41:54 UTC