[mediaqueries-4] do `hover` and `any-hover` only make sense for *pointer-based* input mechanisms?

[patrickhlauke]

Following the discussions in #737 and taking a step back, I think I may have had a slight shift in perception on how I could reconcile my most fundamental/philosophical issues with what the spec seems to be trying to do...

One of the scenarios that I felt very uncomfortable with for a long time was the fact that keyboard-type inputs aren't sufficiently covered by the spec. My fear in this context is that authors may do something like querying pointer:none, hover:none, any-pointer:none, any-hover:none and if those did not evaluate to true, assume that there was no keyboard (or similar non-pointer, non-hover-capable input).

Now in the case of pointer / any-pointer, I've been able to reconcile this in #842 with the note I added

'any-pointer' is used to query the presence and accuracy of pointing devices. It does not take into account any additional non-pointing device inputs, and can not be used to test for the presence of other input mechanisms, such as d-pads or keyboard-only controls, that don't move an on-screen pointer. 'any-pointer:none' will only evaluate to true if there are no pointing devices at all present.

I'm now wondering if something similar (clarifying text/wording) could also help in the case of hover / any-hover, and this would depend on the following: does the concept of "hovering" only really make sense in the context of pointer-based inputs? Inputs that have an on-screen or physical pointer/cursor?

I can't think of a situation where an input would or could be hover-capable if it didn't have the concept of a pointer (and this also seems to be reflected in the table for https://drafts.csswg.org/mediaqueries-4/#mf-interaction). Is the very idea of hovering perhaps intrinsically tied to having a "pointer", and therefore not applicable at all in the context of non-pointer-based inputs?

And if we can agree on that, perhaps the cleanest way to address my concern about keyboard/keyboard-like input mechanisms not being covered would be to, instead of talking about "input mechanisms" in the spec (which is quite a broad, generic term, which would cover keyboards), the spec text should quite explicitly talk about something like "pointer-based input mechanisms". By using this more specific language, it would be immediately clear that these media features are not even meant to help authors detect if there are other input mechanisms, like keyboards, present. pointer-accuracy and hover-capability would only apply to any pointer-based inputs, and authors would still need to use their judgement to know that there may be other non-pointer-based input mechanisms present (and this could be reinforced in a note).

Thoughts?

If the above makes sense, I'm happy to file a PR that will try to refocus the wording and add a note, as described.

(note that this does not invalidate #841 which is still pertinent even when we focus purely on pointer-based input mechanisms)

[frivoal]

the spec text should quite explicitly talk about something like "pointer-based input mechanisms". By using this more specific language, it would be immediately clear that these media features are not even meant to help authors detect if there are other input mechanisms, like keyboards, present. pointer-accuracy and hover-capability would only apply to any pointer-based inputs, and authors would still need to use their judgement to know that there may be other non-pointer-based input mechanisms present (and this could be reinforced in a note).

I think this is a good idea. I was indeed only meant to cover pointer based input mechanism, and the keyboard related questions were left out for a future (set of) MQ(s) to be drafted when we have a better grasp of the use cases and the right level of granularity.

So making it clear seems fine to me.