[mediaqueries-4] Change when any-* evaluate to 'none'

[patrickhlauke]

Currently, any-pointer: none and any-hover: none only evaluate to true when they apply to ALL pointers/input mechanisms. There are situations, however, where it would be useful if these evaluated to true if ANY pointers/input mechanisms had those characteristics. Filing a speculative PR together with this issue - see the examples I propose there for use cases. [edit: see examples/use cases from the PR ]

This would clearly be a substantive change to the spec, but one that I feel would open up some more granular possibilities for authors.

(this issue is a continuation of #715 which in turn came out of this isse #690)

[tabatkins]

There are definitely some interesting use-cases to address that aren't fully addressed by (pointer) and (any-pointer) (and hover/any-hover) right now, but I don't think that generalizing (any-pointer) to allow it to match anything is the right approach. The PR as written just removes any instructions on what values to should match.

If we can come up with good criteria for determining what any-pointer/any-hover should match (more elaborate than just "the union of capabilities", as currently defined), then there might be something here. Otherwise, we might be looking at a different solution altogether - for example, maybe it's useful to explicitly call out the capabilities of the secondary input devices (so (secondary-pointer) would be just like (any-pointer), but excluding the primary devices). Or maybe we want a JS enumeration of the input devices with some annotations of their capabilities, so apps that really care can be smart about it.

Regardless, I think the PR as written won't work.

[patrickhlauke]

The PR as written just removes any instructions on what values to should match.

• if ANY inputs are present that are non-hover capable, any-hover: none should evaluate to true
• if ANY inputs are present that are hover capable, any-hover: hover should evaluate to true
• if ALL inputs that are present are non-hover capable, any-hover: none should be true and any-hover: hover should be false
• if ALL inputs that are present are hover capable, any-hover: none should be false and any-hover: hover should be true
• if a mix of hover-capable and non-hover capable inputs is present, both any-hover: none and any-hover: hover should evaluate to true

(same for any-pointer, saving myself from writing out the combinations here)

Of course, an author would need to know exactly what they're asking for, and why, in order to make sensible use of this.

[patrickhlauke]

In essence, this change makes the feature query for any-* more along the lines of (to write it out in plain english): "(any-hover: hover) - are there any inputs that are hover capable? (any-hover: none) - are there any inputs that are not hover capable?" etc

[patrickhlauke]

In combination with the regular pointer and hover features, an author can then make more accurate judgements about when to do what. for instance "(hover: none) true and (any-hover: hover) true - the primary input isn't hover capable, but at least one other secondary input is hover capable; (hover: hover) true and (any-hover: none) true - the primary input is hover capable, but at least one of the secondary inputs isn't." what they then decide to do in those situations is, of course, up to the authors (as per the proposed additional examples)

[frivoal]

if ANY inputs are present that are non-hover capable, any-hover: none should evaluate to true

Wouldn't that always be true? On desktops/laptops, the keyboard fits that bill. On mobile, the virtual keyboard or voice control...

In an (js-based?) enumeration of input devices, saying that a particular one doesn't have the ability to hover seems reasonable. But on a single query that answers about the combination of all input devices, that seems ineffective.

In a reductio ad absurdum kind of way, specifying thingsthis way sorts of implies that connecting an input device which is not capable of anything at all should change the result of the media query. I don't think that makes much sense.

[patrickhlauke]

True, keyboard on desktop would be the fly in the ointment (unless UAs were using some heuristics - similar to what Firefox does with regards to ::moz-focusring where it only considers keyboard if the user interacted with the page at least once using, say, TAB/SHIFT+TAB). Incidentally, authors should already be considering the desktop/keyboard use case anyway for accessibility reasons today...

Related musing: perhaps the features should be more tightly limited/defined to only apply to "pointer inputs" per se - similar to what happens with Pointer Events (I originally argued, but then conceded, that keyboard should also be a pointerType back before PE Level 1 went to TR).

As for the reductio ad absurdum case, it doesn't seem too absurd to me - if the user does add an input that doesn't hover and doesn't have a traditional pointer, then yes I would expect the query (if it were modified as per this PR) to then return true for (any-pointer: none) and (any-hover: none), as that would be the truthful answer to the question "are there any inputs now present which don't have a pointer and aren't hover capable?"

[frivoal]

perhaps the features should be more tightly limited/defined to only apply to "pointer inputs" per se
I think that with the current way none is defined, the spec does not need to distinguish:

• If there are no other input device at all, the presence of an input that cannot hover is treated the same as the absence of any input device, and both hover and any-hover match none.
• if there are other input devices, the addition of a device that cannot hover has no impact on the result of the hover / any-hover MQs.

In both cases, excluding from consideration the device that cannot hover on the basis that it is not a pointing device would have no impact on the MQ.

This distinction would be come meaningful if we were to follow to start allowing none and hover to match at the same time.

If I'm understanding you write, what you're after is the ability to distinguish between the absence of a pointing device, and the presence of a pointing device that cannot hover. In the case of the primary one, we can already do so: (pointer) and (hover: none) vs (pointer: none). We can also distinguish using any-* between the complete absence of any pointing device at all, and the presence of one or more pointing devices, none of which is able to hover: (any-pointer) and (any-hover: none) vs (any-pointer: none).

What we cannot tell apart is when there is one or more pointing devices some of which can hover, and one or more pointing devices, all of which can hover. I have a bit of a hard time imagining what a web page would do with that information. I can sort of imagine wanting more fine grained information, and iterating in javascript through an exhaustive list of input devices, each with detailed information, but as long as you're querying about the combined capabilities of all input devices, I don’t quite see it.

Would you be so kind as to give me an example of how one would use that?

[patrickhlauke]

Would you be so kind as to give me an example of how one would use that?

see use cases here 08eaa28

This, in essence, boils down to authors having the ability to base their decision on whether or not to offer certain styles/functionalities reliant on pointer or hover based on knowledge of ALL available inputs. authors may decide that the fact that an input is present (even if it's not primary) that lacks that particular feature is enough for them to decide not to rely on hover stuff, or to add non-pointer stuff, for instance. It's not to say they must, but it gives them the option to.

[patrickhlauke]

thinking about this further in the last few days - just to help myself work through this:

1. the way any-pointer and any-hover are currently specced with regards to none value, they can be used to answer the questions "are all inputs of a type that lacks a pointer" / "are all inputs incapable of hover"

2. with the proposed change here, any-pointer and any-hover would help answer the questions "is there any input of a type that lacks a pointer" / "is any input incapable of hover"

in the current model, there is no way to find out an answer to the questions in 2). which is confusing because the any- part implies (at least to me, purely from the name) that it would be able to answer "is any..." type questions.

if the model for 2) was adopted, and the developer did want to find the answer to the questions as posed in 1), they could still do it with something like (using not, and for the pointer case or and parentheses) @media not ((any-pointer: coarse) or (any-pointer: fine)) / @media not (any-hover: hover)

[frivoal]

This would require us to define what is an input, while the current definition does not need that.

If there is a thing that can hover, we're good, without having to wonder about whether that thing is an input. If there is nothing that can hover, we're also good.

With your definition, we'd need to start classifying things as being an input or not. If a thing cannot point and cannot hover, is it an still input (e.g. the enter key, a spat-nav only gamepad, voice control, volume buttons, /dev/null…)?

I am sure we could come up with a number of definitions. But as I don't see in what case it would be useful to distinguishing between the absence of devices with a certain feature and the presence of unidentified devices lacking that feature, I don't see on what basis to judge whether we picked the best definition.

[patrickhlauke]

sorry @frivoal but you seem to be strangely splitting hairs here...i'm using the word "input" as a short way of saying "input mechanism", which is exactly what the current spec already talks about

The pointer and hover features relate to the characteristics of the “primary” input mechanism, while any-pointer and any-hover can be used to query the properties of all potentially available input mechanisms.

your extra distinction here of input vs "unidentified devices" seems rather orthogonal to my actual points above, no?

[patrickhlauke]

i've provided use cases 08eaa28, rationale, and in answer to @tabatkins also clarified how UAs should decide when the proposed modified media features would return true or false #737 (comment) ... could we focus the discussion back to those? where are the gaps here (one already identified was keyboard always being present and always fudging potential results on desktop, but I'd argue that's by design in my proposal rather than a problem, as indeed a desktop/laptop user could well decide at any point to use a keyboard)

[frivoal]

i'm using the word "input" as a short way of saying "input mechanism",

Sure. I don't care about that difference.

your extra distinction here of input vs "unidentified devices" seems rather orthogonal to my actual points above, no?

I don't think so, because with the way the spec is currently written, if something can point it informs the result of any-pointer, if something can hover, it informs the result of gets any-hover, but if it cannot, it doesn't matter if it is an input or not. With your definition, it does, since an input that cannot hover does inform any-hover while a thing that isn't an input does not. I'm sure you agree that the presence of a rock next to your computer should not cause any-hover to match none, even though a rock is a thing that cannot hover. So rocks are out, and that's easy, but I don't think there's any definition of "input" that will result in your proposed definition working the way you expect.

If you take for example an input to be anything that can either hover or point, then a spatnav or sequential-nav device is not an input, which I think defeats your use cases, as any-* wouldn't pick up game pads for instance, and authors would not know to cater to it. If we make it to be anything that can activate or focus elements, spatnav devices do count, as well as those with caret navigation, and then all devices that have a keyboard are in, which means that all desktop and laptop computers would match any-hover: none. And so would any with voice control (would that be all modern phones and all modern desktop OSes?). Either way, we end up with any-hover matching both hover and none on most devices, making the query effectively useless.

So I don't think we can evaluate your proposal unless we know what counts as input. Some definitions are nonsensical (rocks), some make the query useless (most devices match most values), and some seem completely arbitrary (include game pads but exclude keyboards?) making the query unreliable for authors.

Maybe one of the seemingly arbitrary definitions will still be useful. But I don't know until you say which one you're using.

---

Note: this is not the only thing that makes me skeptical of your proposal, but until we address it, I think it has too much undefined behavior to be effectively evaluated anyway.

[patrickhlauke]

Serious question: do user agents not know what an "input"/"input method" is (either from some built-in capabilities or from the OS)?

[edit: to expand, sure the UA doesn't know about the non-hovering "rock" next to it on the desk, but I'm fairly sure the OS at least has an overview of any standard HCI-type input mechanisms that are plugged in/paired/active, and of those the UA probably(?) knows which ones it needs to react to / can cause an activation / etc?]

[patrickhlauke]

revisiting this once more, i think part of the discussion about keyboard is actually a red herring, since pointer/hover/any-pointer/any-hover in their definition do seem to refer specifically to pointing mechanisms. keyboards and keyboard-like interfaces (d-pads, spatnav, etc) by that definition aren't covered at all by these.

so, with this reevaluation, i can see how any-pointer would logically be none only if none of the pointing devices had any precision, i.e. only if no pointing devices were present.

however, in the case of any-hover, the one scenario (if we only take pointing mechanisms into account, not generic input mechanisms) that still can't be properly detected today would be: two pointing mechanisms (say a touchscreen and a mouse), one of which is hover capable (mouse), one of which isn't (touch). currently, any-hover:none would return false, even though there is a pointing mechanism without hover. does this narrowing of the scope change the discussion here? presumably, the UA should already be "aware" of all the pointing mechanisms (so no, it doesn't need to know about the "rock" next to your computer, but it does know about the touchscreen and the mouse, since it needs to already know about those to correctly evaluate the pointer/any-pointer), so it should be straightforward to then also change the way it evaluates any-hover to not just be the union, but to consider all individual hover capabilities of the pointers it presumably knows about already?

[patrickhlauke]

Tackling at least the clarification of what currently happens (and the shortcoming of what currently can't be detected) in #840

[patrickhlauke]

Closing this in favor of a more focused successor that only deals with any-hover #842