W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2016

Re: [csswg-drafts] [mediaqueries-4] Change when any-* evaluate to 'none'

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Dec 2016 05:28:53 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-265359590-1481088530-sysbot+gh@w3.org>
> i'm using the word "input" as a short way of saying "input 

Sure. I don't care about that difference.

> your extra distinction here of input vs "unidentified devices" seems
 rather orthogonal to my actual points above, no?

I don't think so, because with the way the spec is currently written, 
if something can point it informs the result of `any-pointer`, if 
something can hover, it informs the result of gets `any-hover`, but if
 it cannot, it doesn't matter if it is an input or not. With your 
definition, it does, since an input that cannot hover does inform 
`any-hover` while a thing that isn't an input does not. I'm sure you 
agree that the presence of a rock next to your computer should not 
cause `any-hover` to match `none`, even though a rock is a thing that 
cannot hover. So rocks are out, and that's easy, but I don't think 
there's any definition of "input" that will result in your proposed 
definition working the way you expect.

If you take for example an input to be anything that can either hover 
or point, then a spatnav or sequential-nav device is not an input, 
which I think defeats your use cases, as `any-*` wouldn't pick up game
 pads for instance, and authors would not know to cater to it. If we 
make it to be anything that can activate or focus elements, spatnav 
devices do count, as well as those with caret navigation, and then all
 devices that have a keyboard are in, which means that all desktop and
 laptop computers would match `any-hover: none`. And so would any with
 voice control (would that be all modern phones and all modern desktop
 OSes?). Either way, we end up with `any-hover` matching both `hover` 
and `none` on most devices, making the query effectively useless.

So I don't think we can evaluate your proposal unless we know what 
counts as input. Some definitions are nonsensical (rocks), some make 
the query useless (most devices match most values), and some seem 
completely arbitrary (include game pads but exclude keyboards?) making
 the query unreliable for authors.

Maybe one of the seemingly arbitrary definitions will still be useful.
 But I don't know until you say which one you're using.

Note: this is not the only thing that makes me skeptical of your 
proposal, but until we address it, I think it has too much undefined 
behavior to be effectively evaluated anyway.

GitHub Notification of comment by frivoal
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 7 December 2016 05:28:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:36 UTC