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

[patrickhlauke]

The section on Interaction Media Features https://drafts.csswg.org/mediaqueries-4/#mf-interaction makes, throughout its description text, a hard distinction between the "primary" input and other input types, even going as far as labelling the others as "rare".

As pointed out previously (e.g. in this article https://dev.opera.com/articles/media-features/ - which needs updating due to the removal of on-demand), fundamentally this hard distinction is becoming much more blurry nowadays.

For instance, on a touch-enabled laptop, or one of those new Surface Studio desktop devices, what is the primary input? I know the idea is that the OS/UA will make that call, but by virtue of even having that distinction in the spec, you're discounting the increasing possibility that devices have multiple equi-potent input modalities. There may well be more than one "primary" input, and labelling anything other than whatever the OS/UA decides is "primary" as being "rare" is an inappropriate qualitative statement in the spec.

At the very least, I would like to see language such as "rare" being amended/removed. Call it "secondary", at a stretch, and possibly include stronger advice that the any-* results should be treated not as some courtesy

some extra conveniences or non essential controls can be offered to users who have additional ways to interact.

because if a user does rely on whatever the OS/UA deems as "rare"/"secondary", then it's not just about being "nice" to the user...if you rely on things like hovering or high pointing precision, you ARE going to stop users from being able to use your site/app if you only concentrate on the "primary".

More fundamentally, I'd actually love to see the concept of "primary" input go away altogether as it's increasingly inappropriate in multi-input environments, but I take it that'd be a step too far?

(for what it's worth, note for instance that in the Pointer Events spec, we don't try to categorise any type of pointer by it being "primary" or not...they're all treated as equally valid/important)

[patrickhlauke]

Happy to make a PR following some discussion here...but wanted to get a feel for this first from the WG

[patrickhlauke]

The potentially radical solution (if we agree that multi-input devices where different input types can be of equal importance) would be to of course drop pointer and hover, and only rely on any-pointer/any-hover queries. A halfway solution perhaps to keep pointer and hover, but to add a very strong warning in the spec pointing out that the concept of "primary" may not be applicable to situations with multiple input devices used concurrently/interchangeably, and to advise authors to just rely on any-* queries...and mark pointer and hover as "at risk".

[frivoal]

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

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

[patrickhlauke]

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

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 cushion?

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

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

just that you can when you want to without making everything unusable.

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

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

• 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 any-pointer?

• 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 file:///D:/github/patrickhlauke/getting-touchy-presentation/index.html#137) 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 information.

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 usable?
• 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.

[patrickhlauke]

And once again, I'll reference the fact that in the Pointer Events spec https://w3c.github.io/pointerevents/ we make no assertion about any kind of input being primary or not.

Additionally, this aspect of multi-input (and ensuring that sites/apps don't make any sort of value judgements about what is primary and what is nice to have) is also something that we're currently working towards enshrining in the upcoming WCAG 2.1. There are already draft Success Criteria in the works to that effect.

[patrickhlauke]

At an absolute minimum - if I simply can't convince the working group that the fundamental idea of a primary vs other stuff input mechanism hierarchy is inappropriate - I would move towards having a strong note in the spec as outlined above

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

and a renaming of "Rare" to read "Secondary" - this term still implies some hierarchical relationship which I don't buy into, but at least it's not a loaded term that contains further value judgements about how often/not often the type of input will be used.

[stucox]

Unfortunately web devs are lazy (I should know, I’m one of them) and will often take the shortest route / first SO answer to achieve what they’re after.

I like @patrickhlauke’s suggestion to make it clear that the definition of “primary” might not always be in the user’s interests, but an effort would have to be made to communicate this across other references: MDN, SO answers, etc.

But I strongly agree that specifying a “primary” input at all is dangerous.

It’s highly likely @media(pointer:coarse) will proliferate as the recommended technique for “detecting a touchscreen”, just like 'touchstart' in window did, as devs will find this works fine for their immediate testing (likely just on a phone and a laptop), and they’ll ship it. People who struggle to use a trackpad/stylus accurately who have bought a laptop with a touchscreen for exactly this reason will be given a fiddly UI and have trouble with it, etc. Nothing about the API implied to the developer that this wouldn’t be fine.

An alternative angle might be replacing “primary” with “current” — and hence encouraging UA implementors to switch based on context rather than device, à la https://github.com/WICG/modality: if the user is currently using the mouse, pointer: fine matches — etc.

Benefits:

• Much less ambiguous than “primary”.
• For devices with a dominant input device, it will usually behave the same as “primary” (e.g. for users who only ever use the touchscreen their phone, pointer: coarse would always match).
• Facilitates more powerful, flexible UIs.
• Easier for end users to test their code, as they won’t have to find devices with the right “primary” configurations.
• More obvious how to combine with any-*: pointer and hover represent dynamic behaviour, while any-* represent (relatively*) static behaviour.

* Relatively, because values matched by an any-* query should ideally change if peripherals are connected/disconnected.

[detlevhfischer]

Patrick said:

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.

There are indeed many cases where the lowest common denominator (large click targets) is not "dumbing down" but an improvement of usability

• allowing the user to interact with any pointer available / connected
• making interaction easier also for the fine pointer user, e.g., when affected by shake (think train journeys and the like)

So the spec should perhaps use language / hints to encourage that and avoid terms like "rare" which implicitly suggest the inclusive approach is just a 'nice to have'.

Having said that, I also see cases where the choice of more inclusive large click targets becomes a problem since there simply may not be enough space to present all elements for an activity in one view. Going for large targets, an interface may need to be broken down into separate views that need to be navigated to - or be subject to a possibly disorienting re-flow of elements that may change both the order and discoverability of sections and interface elements.

In that sense, assuming a primary input mode can work for the user - because the alternative would be much less efficient. I think it is mainly the author's call to weigh the trade-off between going for a design that has click targets for all but by the same token will also become more granular for all, requiring more navigation to different views, and a design that optimises for fine pointer control and disadvantages coarse pointers. The spec should empower authors to supply alternative designs suitable for coarse pointer input, but I guess we have to acknowledge that there are use cases where a coarse pointer simply doesn't work. For these cases, zooming in would be necessary if you insisted on using coarse pointers nevertheless (say, if you insist on retouching a photo with pixel precision using your finger and not a fine pointer, you'd be forced to zoom in a lot).

[stucox]

APIs should avoid implying information to the developer something they don't have. I'm concerned that the nuances around pointer: coarse etc mean it'll frequently be misunderstood (and hence misused).

In our wish to let web devs detect allthethings automatically we forget that these things can be achieved in other ways.

As @detlevhfischer points, out a UI the developer thinks will mostly be used by those capable of fine accuracy can build it as such, yet make it accessible by ensuring it can be zoomed.

Alternatively, a developer could design a touch-friendly UI with a switch to allow the user to opt-in to a mode requiring fine accuracy: e.g. a toolbar which can be switched to show more icons at once (but smaller).

[patrickhlauke]

Filed an initial PR with changes that would at least assuage some of my concerns here #715 - feedback welcome

[frivoal]

I started by answering your points individually, but you have a lot, and I am not sure this will be productive, as we seem to be talking past eachother to some degree, and I am not sure answering the details when we seem to be having a fundamental disagreement is the best way forward.

I will write below the points I have already written answers to below, but I would like to reiterate my earlier request: can you please provide concrete examples of a sets of designs you wish to switch between using [any-]?[pointer|hover], and concrete examples of devices they would be used on, and what you'd like to happen (and why)? The current design is intended to make it easy for an author to do the right thing in the general case, even when running on a device they have not tested on or anticipated, and to expose some additional information for more sophisticated use cases. This does assume that UAs are going to do a decent job a deciding what information to show through the pointer and hover and their any variants, possibly dynamically depending on the device. But it seems to me that with your alternative proposal, the only things authors can conclude is that they have no idea what the user might be comfortable with, and that they should never design anything with fine targets and hover effects. But in that case, you don't need input device MQs at all, so clearly this is not what you're after.

I do not understand how it is useful to the author to have a as the sole information about input capabilities a list of input capabilities that includes those that are known to the UA to be either something that the user doesn't use at all, or something that the user uses occasionally but typically not.

You've already given me plenty of high level answers, and I don't seem to get it. Please try and give me concrete examples. Hopefully I'll process that better.

---

Answer to some of your detailed points below. But again, an answer to the point above would help me much more.

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.

Actually I don't. I think large targets and no hover can often be a better design. But I also think that when a designer has made a large target / no hover design and a small target with hover design, and is trying to pick between the two based on what input is available, then the designer does often have in mind a full UI and simplified one.

Would browsers take a user-hostile move, really?

Of course not (provided they have a choice). This doesn't answer which move is user-hostile.

So in a finger+stylus scenario, you still contend that stylus is then the primary.

Not really: I contend that the primary way the device is intereacted with comprises both a stylus and a finger, and that as such, it is capable of accurate pointing. (I agree that the spec may need to be rephrased to make this interpretation a valid one).

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 cushion?

Well, for a computer that only has a cordless mouse, if you lose your mouse, you're kind of in trouble as well. If you've misplaced the main way you're supposed to use the device, you're up for some pain anyway. Which I see it as a different thing from either of the following:

• You disagree that this device is supposed to be used with a stylus. Maybe tough luck? iPhones don't come with a small-target version of their UI for people who decide to use them differently than what they're designed for. Maybe there's a setting in the UI that lets you switch from finger+stylus to finger-only mode? Maybe the computer is smart enough to notice you never use the stylus (or that it is currently out of battery, or out of range...) and switches mode for you? It seems to me that the spec is trying to give these options to the UA/OS/Device vendor.
• You've misplaced the optional bluetooth mouse for your TV. The TV can support having a mouse, but was not designed to be used with one, so the UI wasn't tweaked for when the mouse was added, and there's nothing to switch it back to now that the mouse is lost.

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?

I am suggesting that it is perfectly reasonable to not check for pointer:fine and to provide large targets always. Just because it would return true if you asked doesn't mean that you have to ask. On the other hand, authors that do want to provide fine targets should indeed check whether that's going to be convenient.

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

I would phrase it differently: hover:hover / pointer:fine do indicate that hovering or accurate pointing are available and easily accessible. They do no indicate preference for or against hovering or accurate pointing.

if (any-hover:none) evaluates to true but (any-hover:hover) also evaluates to true [...]
That's not possible, none is defined to match when other values don't. On the other hand, it seems to me that this example works just fine if (hover:none) evaluates to true but (any-hover:hover) also evaluates to true.

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.

An OS that would insist that the way the user is consistently using the device is not the primary way the user is using the device would be doing it wrong. My take is that yes, the OS+UA (but not the authors of the page) is in a position to judge what is the primary way the user uses the device, by combining knowledge about what the device is, what is connected to it AND how the user generally uses it AND how the user currently uses it.

---

All in all, I agree this is a tricky feature, so I am open to better approaches. And I agree that multi-input makes this tricky. But I would rather avoid answering the query with something that comes close to“The user may be using whatever”, because then authors cannot do anything other than ignore this information.

The any-* are meant to be a generic fallback that isn't particularly smart but is reliably predictable. The pointer and hover queries can only be useful if the OS+UA is generally right about what is the primary way to interact with the device, not in an abstract sense, but in actual practice.