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

Thanks for this list, Simon!

So we're looking for cases that use a "not" and an "and", with one
clause of the "and" being false sometimes and the other being "maybe"
under our proposed rules.  If we go through the list and eliminate all
the irrelevant cases , we're left with:

@media not screen and (1) {     51
@media not screen and (1){      18
@media not screen and (-webkit-min-device-pixel-ratio: 0) {     1
@media not screen and (min-width: 1290px) and (max-width: 1366px) and
(-o-min-device-pixel-ratio:2/1) { 1

The first two lines, which show up quite a bit (what the hell?) hit
our sweetspot.  Under MQ3 (current impls) they violate the grammar and
thus are always false.  Under MQ4, it's valid, with the "(1)" matching
<general-enclosed> and evaluating to "maybe".  As long as "screen" is
true, that's fine, the whole thing will evaluate out to maybe, and
thus not match.  But when printing, "screen and (1)" will be false, so
"not screen and (1)" will be true.

We could tighten up the grammar for <general-enclosed> to fix these.
For example, maybe split it into two forms - functions that allow
anything as arguments, and parenthesized groups that require at least
one <ident-token> or <general-enclosed> in them.  I doubt we'll
actually ever make "(1)" valid in any meaningful way. ^_^

The third and fourth lines use vendor-prefixed MQs, which invalidate
the whole thing in other browsers.

In particular, the third one appears to be an explicit Browser Test.
It's weird, though.  The RHS is always true in webkit, so it is
essentially a "@media print and (user-agent: webkit) {...}" rule.
(Yes, yes, "not screen" is bigger than "print", but in practice it's
not.)  Our proposed semantics will make it equivalent to "@media print
{...}" instead.

The fourth one is even wider - it'll become true if *any* of the other
conditions are false - if the media is "print", or if the viewport
width is outside the narrow [1290px, 1366px] range.  Simplifying, it's
equivalent to :

@media print and ((width < 1290px) or (width > 1366px) or (resolution
< 2x)) and (user-agent: opera) {...}

under today's semantics; our proposed semantics will make it instead
equivalent to

@media print and ((width < 1290px) or (width > 1366px))

for all non-old-Opera browsers.  I highly suspect this is written
incorrectly in the first place, and the author assumed the "not" was
scoped to the "screen" (which I don't blame them for, it's very
confusing).

So we've got a few choices here:

1. Assume that cases like the last two really are rare in practice
(they only show up once each, in the corpus of nearly 6M pages), and
decide that we're okay with them occasionally giving weird results.
I'd like to examine the pages they show up in to see what they're
really using these for.  (This would remove the ability to use
always-true prefixed MQs as a browser filter, but you can still use
@supports for this, so no big loss.)

2. Switch "maybe" to "bottom", so that OR is the only way to escape
from a "bottom" pit.  DeMorgan's law is lost (in general; it still
applies to expressions that don't contain a "bottom") but shrug.

3. Keep Kleene semantics for "maybe", but specially recognize prefixed
values (ones that start with a single dash) and give them "bottom"
semantics, which can only be escaped by OR.  Custom (double-dash) or
unknown (no dash) MQs continue to be "maybe" with the Kleene
semantics.  This means we have a four-valued logic, technically.

4. Decide that "not screen" is the problem (media types in general are
the problem), and declare that screen == all, or at least that "not
screen" == "not all".  This'll fix the third and fourth lines.

I'd prefer either of the first two, though #3 intrigues me.  I'll have
to think a bit more on how fragile the use of prefixed things might
be.

~TJ

Received on Friday, 24 April 2015 19:13:41 UTC