Re: [mediaqueries] @media not (unsupported-media-feature) v.s. @media not (unsupported + syntax)

> 
> On 22 Apr 2015, at 21:32, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Apr 22, 2015 at 9:45 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
>> Another option that came up in today’s call is tri-state logic:
>> 
>> Intermediate terms of a media query, in addition to evaluating to either
>> true or false, could evaluate to "maybe" with the following rules:
>> 
>> * <general-enclosed> evaluates to maybe
>> * `not maybe` evaluates to maybe
>> * `maybe and X` evaluates to maybe
>> * `maybe or X` evaluates to X
>> * <media-query> evaluating to maybe is the same as evaluating to false.
>> 
> 
> Your truth table is mostly correct, but I think "maybe AND false"
> should be false.  In particular, we should be implementing the Kleene
> 3-value logic: http://en.wikipedia.org/wiki/Three-valued_logic#Kleene_and_Priest_logics

I am not sure how often you'll run into media queries where the difference between
Simon's table and Kleene's 3-value logic will matter, but sure, Kleene's logic is cleaner.

I particular, it preserves (not( A and B)) == ((not A) or (not B)), which Simon's approach doesn't.

If we're going with 3 way logic though, then it makes sense to use it not only for <general-enclosed>, but also for unknown <mf-name> or <mf-value>.

The problem then is is that going with Kleene's logic break backwards compat, while Simon's logic doesn't. Look at these
examples:

"not ((min-width: 30000px) and (shoes: none))"
"not handheld and foo(bar)"
"not yoyo and (light-level: stroboscope)"

MQ3 behavior: false
Simon: false
Kleene: true

The first two might be ok. They use syntax that wasn't valid at level 3 (not without a media type, general enclosed), so the fact that they evaluate differently is probably fine.

The third one is more problematic. Had we used Kleene's logic in the first place, we would have been better off, but we didn't.


 - Florian

Received on Wednesday, 22 April 2015 21:00:45 UTC