W3C home > Mailing lists > Public > www-style@w3.org > April 2015

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 22 Apr 2015 23:00:20 +0200
Cc: Simon Sapin <simon.sapin@exyr.org>, www-style list <www-style@w3.org>
Message-Id: <A4F06C60-FCCC-437F-BFC3-C424951A656A@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
> 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

"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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:53 UTC