[css-mediaqueries-4] any-hover:none is slightly pointless in current implementation?

[patrickhlauke]

Coming in very late on this, but as I'm currently rewriting an old article on the topic of interaction media features...

As currently defined, any-hover:none will only ever evaluate to true when all of the detected pointer inputs are not hover-capable. This makes the query fairly useless in practice. From a developer's point of view, I'd want to know "am I safe to rely on the user being able to hover, or are there any inputs that the user may jump to that don't support this?" - at least I'd want to check this far more often than "is it impossible for the user, using any of the inputs at their disposal, to trigger the hover" (the latter would be accomplished simply by checking any-hover:hover ... if that evaluates to false, I'd know that none of the inputs are hover capable).

Is it far too late in the day now to ask for the behaviour of any-hover:none to be amended? basically, changing this so it can have multiple values evaluating to true...and make this include any-hover:none (so not making that the "union" of all hover capabilities, as is currently the case).

/cc @frivoal

[patrickhlauke]

digging through some old stuff, i see i made a similar case aeons ago #841 - seem to have forgotten about it. the main point though still remains for me: any-hover:none seems very limited in that it only lets you detect that none of the pointers are hover capable. being able to know if at least one pointer isn't hover capable seems to me a much more valuable piece of information - then, as an author, I could decide (very defensively) to avoid any :hover type stuff altogether (as the user may start using that pointer that is non-hover capable). and of course, I can always do the opposite and, with the way any-hover:hover is currently already evaluated, check if at least one is hover-capable and decide that yes, I do want to provide :hover stuff then. I could even take the primary hover:hover into account in this scenario and decide even more strongly to do some hover stuff if the "primary" is hover capable.

@media (hover:hover) {
  /* the primary is hover capable ... depending on how much i trust the user to just stick to mainly the primary input, I can "safely" rely on hover stuff */
}

@media (hover:none) and (any-hover:hover) {
  /* ok, primary input can't hover, but some other input that's there can ... maybe cautiously still use hover? */
}

@media (any-hover:none) {
  /* clear-cut - none of the inputs support hover, so don't bother doing anything hover-related */
}

in the above, what's missing to me would be to be able to determine when the primary has hover capability but at least one other pointer input doesn't. that information is currently not available / queriable at all. this would basically allow me to not rely on that first determination just based on hover:hover (and rewrite the last one as a negative test). as one of the arguments against this was that this breaks the meaning of none ... let's for the sake of argument invent a new value any-hover:mixed or something.

@media (hover:hover) and not(any-hover:mixed) {
  /* the primary is hover capable, and there are no other pointers that don't have hover capability. they can all hover. safe to use hover stuff? */
}

@media (hover:hover) and (any-hover:mixed) {
  /* the primary is hover capable, but there's at least one pointer that isn't. maybe hold back on using hover, as the user might switch to that other pointer and find they can't use/operate my content if it relies on hover */
}

@media (hover:none) and (any-hover:hover) {
  /* ok, primary input can't hover, but some other input that's there can ... maybe cautiously still use hover? */
}

@media not(any-hover:hover) {
  /* clear-cut - none of the inputs support hover, so don't bother doing anything hover-related */
}

[micolous]

I agree with @patrickhlauke's proposal that there should be a simple way to determine if not all pointing devices support hover.

The current spec alludes to this issue (emphasis added):

'any-hover:none' will only evaluate to true if there are no pointing devices, or if all the pointing devices present lack hover capabilities. As such, it should be understood as a query to test if any hover-capable pointing devices are present, rather than whether or not any of the pointing devices is hover-incapable. The latter scenario can currently not be determined using any-hover or any other interaction media feature. Additionally, it does not take into account any non-pointing device inputs, such as d-pads or keyboard-only controls, which by their very nature are also not hover-capable.

The problem is even worse than described here or in the spec: many browsers report a mouse-like "primary" pointing device (hover: hover, pointer: coarse), even when they're being used with a touch screen (several browser bugs are linked from there). There are also devices which defy classification which make "what is primary" more complicated.

The trigger for this is unreliable or incomplete data from the underlying platform about what the "primary" pointing device is, so browsers conflate signals and make incorrect assumptions.

Rather than adding another state to any-hover, I propose a new query, all-hover (maybe for Media Queries Level 5?), with simpler semantics which are hopefully easy for browsers to implement:

• all-hover: none:

  • the user prefers a non-hover interface (eg: for accessibility reasons), or,
  • there are zero pointing devices connected, or,
  • there are one or more pointing devices which:
    • do not support hover (eg: touch screen), or,
    • it is difficult to hover with (which could take into account input-device-specific accessibility needs), or,
    • it cannot be determined whether the device is hover-capable (eg: remote desktop or virtualisation software)

• all-hover: hover:

  • the user has not requested a non-hover interface, and,
  • there is at least one pointing device connected, and,
  • all connected pointing devices definitely support easily hovering

The result of these queries would not be connected to whether a device is in "tablet mode" or has an auto-rotation sensor (as hover and pointer are today).

all-hover: hover would then provide a clear and reliable signal, which could be used defensively with something like:

@media not(all-hover: hover) {
  /* Don't require hover, because the user may not be able to do it, or,
     the browser doesn't support the all-hover query */
}

@media (all-hover: hover) {
  /* The user can definitely use hover, so :hover everything! */
}

My expectation is that many more devices would report all-hover: none than ever reported hover: none. There are a lot of PC-like devices with touch screens, and it should be easy to use them.