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: Patrick H. Lauke via GitHub <sysbot+gh@w3.org>
Date: Tue, 08 Nov 2016 10:26:10 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-259100457-1478600767-sysbot+gh@w3.org>
> 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. 

You talk of lowest common denominator and "dumbing down", so clearly 
you have a value judgement here that having large targets and no hover
 is intrinsically a bad thing. The main tension I see is this: 
assuming I as a user have both a fine/hover-capable input and a 
coarse/non-hover-capable input at my disposal, and I am able to switch
 equally between them

- a UI that relies on larger targets and foregoes hover-specific 
functionality will work for all my input modalities
- a UI that relies on small targets and is based on hover-specific 
functionality will *only* work if I explicitly only use the 
fine/hover-capable input

So, given multiple input types, designing for the lowest common 
denominator isn't "dumbing down"...it's adapting the interface to 
ensure that all available inputs can be used. This is a user-friendly 
move, a positive. It feels like your (perhaps not you personally, but 
the working group's?) own value judgement of "non-hover/coarse 
interfaces are dumbed down" influence the spec.

The "this will be an incentive for browsers..." part seems rather a 
conjecture on your part. Would browsers take a user-hostile move, 
really? Would browsers willfully hobble their functionality because 
they share the belief that "if there's both a mouse and a touchscreen,
 surely the user will be happy if we just pretend there's just a 
mouse"? I'd like to hear statements from browser vendors to that 

> 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 because the spec currently forces the idea of a single *primary* 
input, this wouldn't work, would it?

> 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.

So in a finger+stylus scenario, you still contend that stylus is then 
the *primary*. But take your own example later on of the accurate 
pointing device under the sofa cushions...what if yes, I have 
finger+stylus, but my stylus is currently under that same sofa 

> Just like not every click target is tiny on desktop screens, pointer
 responding to fine does not mean you have to make everything tiny,

But by its very definition that's what you're saying though. Are you 
suggesting that authors would check for `pointer:fine` but then ignore
 it? What's the point of that, then? And if so, the spec needs a clear
 note in the `pointer`/`hover` section which is essentially says the 
same thing as the note you have in the `any-*` part. So if you have

Designing a page that relies on hovering or accurate pointing only 
because `any-hover` or `any-pointer` indicate that an input mechanism 
with these capabilities is available, is likely to result in a poor 

you also need the same to be said for `pointer`/`hover`

Designing a page that relies on hovering or accurate pointing only 
because `hover` or `pointer` indicate that (whatever the OS/UA decided
 is) the primary input mechanism has these capabilities, is likely to 
result in a poor experience (as it ignores the fact that secondary 
input mechanisms may be available that lack these specific 

> just that you can when you want to without making everything 

But you are making it unusable if the user is using that input you/the
 OS/the UA deemed "rare". You're saying "hey, it's not unusable...just
 stop using the input you're using just now, because we know best, so 
you should switch from that input to what we decided is the primary 
one". Again, a user-unfriendly (bordering perhaps on patronising) 

> 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  
fine movements with a device unsuited for that, nor by forcing them to
 reach out for some optional peripherals.

It will inconvenience the user if they're currently not using what is 
deemed as the one true primary input mechanism. You're forcing them to
 stop using whatever "optional"/secondary input mechanism they're 
currently using for whatever reason (maybe because they dropped their 
stylus behind the proverbial sofa? or because their RSI kicked in and 
instead of using their mouse they're using their laptop's touchscreen,
 or ... any other scenarios that you/the OS/the UA has no way of 

> - 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.

True, but this is based on the intrinsic value judgement of this 
mythical *primary* input. The more robust and user-friendly 
rationale/conclusion in my mind would be: "If `(any-pointer:coarse)` 
and `(any-pointer:fine)` are true, the user has at their disposal both
 coarse and fine pointers. I have no way of knowing which one they're 
using just now, which one they may switch to, which one they prefer, 
which one is actually more convenient for them in their current 
situation (sofa/RSI/etc), so the safest option is to make sure my 
interface works for all possible input types the user has currently at
 their disposal".

> - 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.

This is a strong outlier, which depends on what you envisage happening
 when `(pointer:none)`. Are you expecting authors to, when that 
evaluates to true, remove any form of "clickability" (and instead do 
something like just listening to `keydown`/`keyup`/`keypress`)? And 
can this not be also addressed by simply doing checks for just 

- if `(any-pointer:none)` evaluates to true and both 
`(any-pointer:fine)` and `(any-pointer:coarse)` evaluate to false, 
there's no need for "clickable" things
- if `(any-pointer:none)` evaluates to true and `(any-pointer)` also 
evaluates to true, make sure your interface works both for pointers 
and for non-pointers

No need for a value judgement of "but what is the *primary*?". You're 
ensuring that if the user does have a non-pointer input at their 
disposal, an author can query for that and make a judgement on whether
 or not they want to also include non-pointer input functionality 
(such as listening explicitly to `keydown`/`keyup`/`keypress`).

> 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.

Assuming I'm on a device which does have both a hover-capable mouse 
and a non-hover capable touchscreen, and I land on your site/app while
 I'm using the touchscreen. My mouse is by my side, but I am currently
 purely interacting with my touchscreen because...well, because I want
 to. How am I now more "likely to discover that things can be 
hovered"? Unless I actively switch back from my touchscreen to my 
mouse (and mutter something under my breath about "[expletive] 
designer making assumptions that mouse is my primary input..."), I may
 never actually "discover" that there's hover-specific functionality. 
I may in fact find that the site/app simply isn't working properly for
 me, and leave. And again, this is due to the intrinsic value 
judgement of *primary* input and that my using the touchscreen is 
somehow a rare quirk.

Instead, just as with the above reframing of `(any-pointer)`, as an 
author I can make a judgement myself:

- if `(any-hover:none)` evaluates to true but `(any-hover:hover)` also
 evaluates to true, I know that the user has at least one means of 
invoking hover. Now I as an author can make a choice...do I take this 
information and decide that my site/app should forego any hover 
interface (which will still work just fine for mouse etc users, so 
covers all input modalities)? Or do I politely put a notice up on my 
page saying "This functionality requires you to pick up your 
hover-capable device, sorry about that"? Or do I offer the user an 
explicit switching mechanism, the same exact way that for instance 
Microsoft Office does when on a touch-enabled laptop? (see 
 The decision making is still with me, the author, but I can make the 
exact same value judgement myself, and not rely on the OS/UA to 
somehow magically work out that one of the inputs is *primary* and 
therefore *better*/*more likely to be used*.

- if `(any-hover:none)` evaluates to false, great...I can rely on 
hover-based functionality to my heart's content (until a user attaches
 a secondary input, e.g. using a KVM switch to flip over to their 
touchscreen monitor, at which point a good site/app would detect this 
change and offer a dialog a la "it seems you've added a non-hover 
capable input..." and then follow any of the approaches outlined in 
the previous bullet point)

> 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 

Again, "nuance"/"generally useful" is an value statement that, in my 
mind, is simply not there anymore in a multi-input world. You're still
 trying to boil all possible inputs at a user's disposal down to "well
 there's the *primary*, and then lots of other stuff which is possibly
 nice to consider but maybe not, and even if we ignore it it's fine 
users are likely to just use *primary* anyway".

> The continued disagreement on this topic makes me wonder
> - 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 
> - 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?
> - 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?

In short, my disagreement is quite fundamentally with the fact that 
the spec makes a hard distinction between *primary* and "rare" input 
mechanisms. As increasingly we're seeing multi-input devices, this 
hard distinction is becoming hazy. This results in ever-increasing 
need for somehow rationalizing things back down to a single input as 
being primary (see for instance how you had to somehow interpret the 
"finger+stylus" scenario in order to arrive to your personal 
conclusion that "stylus" is this really the primary).

Beyond that, there's language such as "rare" which is rather loaded 
terminology. You're making a judgement here in the spec which you (nor
 the OS or UA) is in any position to make. This is further compounded 
by your apparent value judgement (for instance your "dumbing down" 
comment) in explaining why the spec steadfastly insists that one input
 *must* be the *primary*. And then there's the assumption that because
 one input is *primary*, it will never be inconvenient to require the 
user to use that, regardless of which input mechanism they're 
currently using. Again, the spec, the OS, the UA, and the 
author/developer are in no position to make that particular 
assessment, and it is user-hostile to assume that it's ok to ignore 
the input mechanism the user might be currently using because it's not
 the "right" (primary) one.

> 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.

I believe the spec is perfectly clear in expressing your intended 
approach, and I simply disagree with the underlying principle of your 
approach. My scenarios are, as mentioned throughout, the situations 
where a user has multiple inputs at their disposal, that they choose 
for whatever reason to use a particular input, and that because it's 
not what the OS/UA deems to be *primary* it's ok to ignore them. 
Couple this with the fact that I don't believe that if an interface is
 adapted to `pointer:coarse` and `hover:none`, it's "dumbed down". It 
works just fine even if a user has another input with is 
fine/hover-capable. Whereas the opposite is not true.

GitHub Notification of comment by patrickhlauke
Please view or discuss this issue at 
using your GitHub account
Received on Tuesday, 8 November 2016 10:26:16 UTC

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