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

Re: [csswg-drafts] [mediaqueries-4] Interaction Media Features make a rigid primary/"rare" distinction

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Tue, 08 Nov 2016 07:17:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-259063677-1478589426-sysbot+gh@w3.org>
Given that it is not possible for a UI to show buttons that are 
simultaneously small and large , at some point there's got to be a 
judgement call as to whether the UI is suited to fine pointing or not.
 It is not possible to have a UI that simultaneously relies on 
hovering and does not use it, so there's got to be a judgement call as
 to whether the UI is suited to a device for which hovering is 
practical or not.

Only using any-* is a cop out: it tells the author: "there's a bunch 
of input devices, some of which might be ignored by the user but you 
can't know which". If authors start to design for the lowest common 
denominator, this will be an incentive for browser vendors to not 
report under any-* some of the less used the devices that users, 
because it dumbs down the UI unnecessarily. At which point `any-*` 
become something like what the `pointer` and `hover` were meant to be,
 and nothing takes the role of the original `any-*`.

When you take the surface studio horizontal in drawing-desk mode, you 
quite possibly have a device which is primarily used both with pen an 
stylus. So maybe it could be described with `coarse` and `fine` 
matching at the same time on `pointer`. But the way I think of it this
 finger+stylus interaction is able to make accurate clicks, thanks to 
the stylus. So when designing a UI for it, you do not need to forgo 
small clicking targets. Just like not every click target is tiny on 
desktop screens, `pointer` responding to `fine` does not mean you have
 to make everything tiny, just that you can when you want to without 
making everything unusable.

Here's the way I think about this:
* If `(pointer:fine)` is true, it is ok to use small click targets. 
Doing so will not inconvenience the user either by asking them to do 
do fine movements with a device unsuited for that, nor by forcing them
 to reach out for some optional peripherals. If it's false, you should
 generally stay away from small click targets. Maybe the user does not
 have an accurate pointing device, maybe they have one, but it's 
somewhere under the sofa's cushions, maybe they have a disability that
 makes fine motion control difficult...
* If `(pointer:coarse) and (any-pointer:fine)` is true, the above 
"should generally stay away from small click targets" is right, as 
accurate clicking will be doable even if it is an inconvenience. But 
if it is false, it is "must stay away from small click targets", as 
the UA is advertising no known way of making accurate clicks.
* Same logic for `(pointer:none)` vs `(pointer:none) and 
(any-pointer)`. `(pointer:none)` tells you to design something that 
works without clicking, and `(any-pointer)` tells you whether that's a
 should or a must.
* Similarly, `(hover:none)` tells you that the user is unlikely to 
discover that things can be hovered and even if they knew, they may 
have a hard time interacting with them. `(any-hover)` tells you 
whether they have a way to bypass that.

So in my mind, it's the `any-*` variants we may be able to do without,
 as they are expressing a nuance over the more generally useful 

The continued disagreement on this topic makes me wonder

1. Does spec do such a poor job of explaining the logic between this 
primary / secondary input mechanism that people tasked with 
implementing it misunderstand what they're meant to do, and instead 
are at risk of implementing something different that's not nearly as 

2. Are the WG or Tab and I oblivious to the fact that the way we want 
these features implemented is not possible, and that what can be 
implemented isn't nearly as useful?

3. Are the WG or Tab and I oblivious to some use cases or some devices
 where the feature as designed falls short of what authors need to do 
a good job?

I am suspecting 1, but you sound like you're on 3. Which is why I 
think that a few concrete examples would help sort things out. If you 
can show a few concrete designs, what you would like to do on 
particular devices, how you'd try to code them up, why it fails to do 
what you'd hope, we should be able to sort out whether it doesn't work
 due to a unclear spec leading to misunderstanding about how 
`pointer`, `hover`, and `any-*` are supposed to work, or because the 
way they're supposed to work does overlook some key situations.

GitHub Notification of comment by frivoal
Please view or discuss this issue at 
using your GitHub account
Received on Tuesday, 8 November 2016 07:17:13 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:05 UTC