Re: [mediaqueries] Error handling for media-condition

On Wed, 23 Sep 2015 11:41:23 +0200, Florian Rivoal <florian@rivoal.net>  
wrote:

>> 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 as I know, only HTML <img sizes>. The reason it uses media  
condition is basically because Tab Atkins wanted it to. Otherwise it would  
have used a media query. :-)

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

I seems like a good idea to facilitate use of media condition without  
media query. But for <img sizes> it would not be helped by a  
media-condition-list since it has a custom list.

https://html.spec.whatwg.org/multipage/embedded-content.html#valid-source-size-list
https://html.spec.whatwg.org/multipage/embedded-content.html#parse-a-sizes-attribute


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

Not AFAIK.


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

I agree it should be false.

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

LGTM.


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

OK.

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

That sets things up for different handling in different places, which  
seems bad. I'm OK with handling the case where the grammar is not matched,  
but interpreting the semantics I think should be handled by the MQ spec so  
it gets "right", and more to the point, defined at all.

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

Yes, but it's a bit fluffy. I think I would be happier if the spec had  
three clearly supported entry points for other specs:

* media query list
* media query
* media condition

If some spec in the future also wants a media condition list, we can  
consider that when we get there.

cheers
-- 
Simon Pieters
Opera Software

Received on Wednesday, 23 September 2015 10:27:17 UTC