[mediaqueries-4] any-hover can't be used to detect mixed hover and non-hover capable pointers

[patrickhlauke]

Relates to https://drafts.csswg.org/mediaqueries-4/#any-input

A more focused successor to #737, only covering any-hover (as I can now rationalise better why any-pointer behaves the way it does, which I tried to more explicitly point out in #842)

any-hover, as currently specified, only evaluates to none when ALL detected pointing mechanisms are non-hover-capable. This currently makes it impossible to query specifically if some, but not all, of the pointing mechanisms is non-hover-capable (or conversely, to test if ALL detected pointing mechanisms are hover-capable)

Assuming two or more pointing devices are present, you can currently only test:

• at least one of the devices is hover-capable - any-hover:hover will evaluate to true (and currently, regardless of whether any of the other pointing devices is non-hover-capable, any-hover:none will be false)
• none of the devices is hover-capable - any-hover:hover will evaluate to false, any-hover:none evaluates to true

Scenarios that can't be tested (as they return the same as the "at least one..." scenario above):

• at least one, but /not/ all, device is non-hover-capable - any-hover:hover will evaluate to true, any-hover:none will evaluate to false
• /all/ devices are hover-capable - any-hover:hover will evaluate to true, any-hover:none will evaluate to false

As the UA should be able to ascertain the total number of pointing devices (since it needs to know this in order to properly evaluate any-pointer, presumably), it should be possible (and not require some special "we need to define what an input is" additional consideration, which was the major argument against #737) to also change when any-hover:none evaluates as follows:

• 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

Going back to the original scenarios, this would then allow to capture all possible states:

• at least one of the devices is hover-capable - any-hover:hover will evaluate to true (as before)
• none of the devices is hover-capable - any-hover:hover will evaluate to false, any-hover:none evaluates to true (as before)
• at least one, but /not/ all, device is non-hover-capable - any-hover:hover will evaluate to true, any-hover:none will also evaluate to true; this is a new capability that couldn't be tested before
• /all/ devices are hover-capable - any-hover:hover will evaluate to true, any-hover:none will evaluate to false; this is also a new capability that couldn't be tested before (with the change to none, this now actually gives you confidence in the any-hover:none to mean "none of the pointing devices is non-hover-capable)

[patrickhlauke]

/cc @tabatkins @frivoal ... any thoughts on this more refocused proposal? the fact that there's a shortcoming (not being able to detect a mixed set of hover/non-hover capable pointers) is now at least mentioned in the spec thanks to #842 but it would be perhaps nice to see if the shortcoming itself could be overcome

[frivoal]

• This goes against the normal meaning of none which is supposed to be true when other values are not. Changing that hurts consistency and understandability, so that's not desirable. An alternative would be better, or you need very strong reasons.

• I am not convinced I understand the use case. Yes, in theory, the more information you have, the better you can make informed decisions. However, if that makes simple cases harder to do correctly (see first point), that's not a good idea. And if we expose more info but still not enough info to make different decisions, we've gained nothing.

I do not understand what use cases would be served by your proposal. Yes, you have strictly more information, but since that's still not an exhaustive list of all the inputs and how they are being used, that's not enough to do fine grained detection of various specific scenarios to which you might want to adapt to.

If you have no idea what the (non-primary) devices are, nor how the user uses them, what can you do differently based on the knowledge that some of them can hover vs all of them can hover?

Thanks to the primary / non primary distinction, you can already know that the normal way of interacting with the device is hover-incapable, but that the user may have additional means of hovering at their disposition. So you know that you should not depend on hovering for essential functions(hover:none), but that if you offer additional conveniences based on hover, the user may take advantage of them (any-hover:hover). What can you do differently with the additional bit of information you're proposing?

[patrickhlauke]

Thanks to the primary / non primary distinction, you can already know that the normal way of interacting with the device is hover-incapable, but that the user may have additional means of hovering at their disposition. So you know that you should not depend on hovering for essential functions(hover:none), but that if you offer additional conveniences based on hover, the user may take advantage of them (any-hover:hover). What can you do differently with the additional bit of information you're proposing?

with the proposed change, you can detect the opposite situation that may lead you to the same decision.

the primary being hover capable (hover:hover), but that other inputs the user may use are not (proposed any-hover:none), which can lead you to the same decision - not to rely completely on hover-based interactions, because the user may well be using/switch to using one of the other pointer-based inputs, so perhaps (even though the primary is hover capable) treat it as a convenience.

[patrickhlauke]

because if you aknowledge that the "offer hover as a convenience" scenario is a valid one, then authors should be able to base that decision both when the primary is not hover capable, or if at least one of the secondary inputs is not hover capable (and with the proposed change they can also differentiate the two of course, based on the value of the primary hover:...). you could argue "but once authors know the primary is/isn't hover capable, that's all they need", but that still gives undue prominence to what the primary pointer does. authors can of course choose to just go mainly by what the primary does, but this allows them some additional granularity in how they base their final decision.

[patrickhlauke]

scenario here would be for instance: laptop with a touchscreen. primary input is the trackpad/mouse (hover:hover). the touchscreen is not hover capable. currently authors cannot detect that beyond the primary input which is hover capable there is also a non-hover capable pointer input (the touchscreen). they can decide "ok, since hover:hover is true, i'm good to rely on hover. which works fine ("for the majority of the time", if we take the primary pointer to be indeed the one used most frequently), but as soon as the user does switch to using the touchscreen, things will not work, forcing the user to revert back to using the trackpad/mouse. [edit: of course, with the prose i added in #842 it's at least mentioned that despite what can currently be detected, there is still a chance that there may be non-hover-capable pointers, or in general non-hover-capable inputs, and authors should still not 100% rely on it, but this cannot be unambiguously detected]

with the proposed change, authors would be able to see that yes, while hover:hover is true, any-hover:none is also true. that then leaves authors the ability to say "ok, even though i could just rely on hover-based stuff for the majority of the time, there may well be cases where the user switches to whatever non-hover-capable pointer input the browser also detected...maybe i should cater for this scenario too". they don't have to, but if they do want to, they can detect this situation too (what they then do is up to them...whether they decide to forego all hover-based stuff on the offchance that the user may switch to the secondary pointer, or whether they load in additional styles/show additional controls/load new scripts to make sure non-hover-capable pointers can also be used...that's up to them)

[patrickhlauke]

@frivoal ... did the above make sense to clarify my particular desire/use case?

wondering, if there is definitely no chance to change the way any-hover:none is evaluated, if there's any mileage in defining an additional value such as any-hover:mixed, any-hover:partial or similar to signal "some of the pointer devices support hover, others don't". authors could then still combine this with an explicit query of hover:hover / hover:none to determine if in this scenario at least the primary is hover-capable, and then make their decisions as they see fit (e.g. they can then still say "oh well, i don't care about non-primary pointers anyway"), but at least it gives some way for a defensive author to detect this case (and potentially think "although the primary IS hover capable, this query tells me that there's at least one more pointer input device which isn't...so i'll play it safe and provide non-hover alternatives" or "i'll avoid using hover-based functionality/styles altogether", whatever they want to do)

[frivoal]

@patrickhlauke

In the case of a touch-pad+touch-screen laptop, the touch pad is never very far away, so if some aspects of the UI are only conveniently used with the pad, I do not think users are greatly inconvenienced by being required to use it.

Note that I think that making any essential part of the UI depending on hovering is generally a bad idea, as it is not very discoverable, not very friendly to users with limited skills or ability to use the pointing device, and gets in the way of keyboard users. So I believe that authors should always be very careful before adding anything that needs hover to work, as opposed to taking advantage of hover when it happens without relying on it. The argument is similar for accurate pointing.

However, once an author has taken the decision to build some part of the UI in a way that needs hovering, the presence of a touch screen in addition to the touchpad or mouse is unlikely to affect that decision much, anymore than the presence of a tab key.

On the other hand, on a laptop where the touch screen can be detached from the keyboard+touchpad part and used as a tablet, then the UA would be expected to change the pointer and hover media features to reflect only the touch screen when detached. In this scenario, the inconvenience that would be caused to the user by presenting a hover-only UI would be much greater, and is covered by the current design of the feature.

In my opinion, when it comes to this (or to pointing accuracy), the best practice is for authors to think along these lines:

Case 1:

• Can I rely on hovering / pointing / accurate pointing?
• Probably not, it makes things worse for lots of people
• But I really want to, it simplifies things quite a bit in this particular case, and the alternative is much worse
• Ok then, does the primary input let people do that conveniently?
  • Yes => Ok, but don't go overboard
  • No => don't rely on it then

Case2:

• Can I use hovering / pointing / accurate pointing to trigger non essential niceties?
• Does it have any negative side effect (visual clutter, increased difficut)?
  • No => do it, regardless of device capabilities. If it doesn't trigger, no big deal
  • Yes, but the trade-off is worth it => Does the user have any device they could actually trigger this with?
    • No => Don't do it then
    • Yes => OK, but don't go overboard.

Neither of these require the ability to detect the situation where the primary device and some (but not all) of the non-primary ones can hovering / point / point accurately. If we could provide this information at no cost to anyone, this would still be worth doing. But in this case, I think that it does have a cost: depending on how we design it would either:

• make this media feature unusable in a boolean context, if values are hover and no-hover, neither of which is falsy
• inconsistent with how other media features work in a boolean context, if none and hover can be true at the same time
• be misleading if none or no-hover do not trigger when some of the input devices are neither capable of hovering nor pointing (e.g: a keyboard), as the reasoning you proposed for touchscreen+mouse applies equally well to keyboard+mouse
• make the feature hard to define if none or no-hover do trigger when some of the input devices are neither capable of hovering nor pointing, as we now need to worry about whether a thing that can neither point nor hover is an input device or not, to know whether it should influence that query

Based on that, I'd rather keep the feature as it is. However, I do recognize that this is subjective ones, and that reasonable people can see disagree.

Unless I have convinced you (in which case you can close the issue), this probably needs a CSSWG discussion and decision.

Marking as "Agenda+" to schedule this for a teleconference.

[patrickhlauke]

However, I do recognize that this is subjective ones, and that reasonable people can see disagree.

Glad to know I'm reasonable :)

In seriousness, I agree that what you outline in terms of how an author should treat hover is reasonable. Plus, with the additional text I added in #715 which strongly suggests that authors should still not rely on hover to take account of any other non-hover-capable inputs and the note I added in https://github.com/w3c/csswg-drafts/pull/842/files#diff-86306790afb9d5330bbdda192a7b99f6R1783 we've probably got at least a warning to authors of potential gaps in what they can detect, which would hopefully temper their enthusiasm when any-hover:hover evaluates to true.

Nonetheless, I'd be interested in what others in the CSSWG think (to either changing when any-hover:none evaluates or the potential for a third partial/mixed value.

[tantek]

@patrickhlauke can you add https://drafts.csswg.org/mediaqueries-4/#any-input to the initial issue description at the top? Much thanks. (p.s. I tend to agree with your line of reasoning here and am trying to understand it better)

[css-meeting-bot]

The CSS Working Group just discussed any-hover can't be used to detect mixed hover and non-hover capable pointers, and agreed to the following resolutions:

• RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/841 no change.
• RESOLVED: Pushing scripting MQ values to L5
• RESOLVED: new WD of MQ4
• RESOLVED: mark the various hover and pointer things as at-risk

The full IRC log of that discussion

<dael> Topic: any-hover can't be used to detect mixed hover and non-hover capable pointers
<dael> Github topic: https://github.com//issues/841
<dael> Florian: We have two pairs of media features. hover/any-hover and pointer/any-pointer
<dael> Florian: hover and pointed desc the primary way for interaction.
<dael> Florian: the any variant are for additional peripherals.
<dael> Florian: pointer can tell if things point accurately, hover is can it hover. Generally you should design without relying on hover or accurate point, but if you can detect that its' supported feel free to take advantage. Any is for if you have a bit more granularity.
<tantek> e.g. laptop with touch screen
<dael> Florian: Issue being raised is there are scenarios this can't detect. Example, primary is a mouse but a non-primary can't hover and you can't detect that.
<dael> Florian: I agree that there are non-detectable cases. I disagree it's useful. If you know there is a thing that cannot hover, what do you style differently?
<dael> Florian: The other argument to not do this is to do this we either make hover:none and hover media feature be able to exist at the same time.
<tantek> q?
<dael> Florian: I think there's down sides to make it work and I still can't see how you would use it. But the person who raised it feels it's useful
<tantek> yeah I tend to agree with the problem the issue is documenting
<dael> fantasai: For hover/no hover proposal....
<Rossen_> come down from the mountain Elika! :)
<dael> fantasai: I was thinking if you had hover, no haver, and none...if the things that would possibly have hover if all are no-hover then you have none.
<dael> Florian: So if you jsut query hover media feature it's supposed to be true. If one of the values other then none are true...you're saying no hover is true only if there's a no hover thing in addition to hover thing and if there's never a hover thing you query through none?
<dael> fantasai: Through hover we only query primary, right?
<dael> Florian: Yes. Q is on any-hover.
<dael> Florian: When you have a set where some can hover you want to detect that some can and some can't.
<dael> fantasai: Then anyhover would be true. any hover no hover would be true.
<Florian> https://drafts.csswg.org/mediaqueries-4/#any-input
<dael> fantasai: But hover hover is false therefore hover:none is true.
<dael> Florian: If we only do it the way it currently works we don't have to worry about if something is an input. If it can hover it clearly is one and if it can't it doesn't matter. If we do this we need to classify things that can hover and are a media device vs aren't a media device. We have to classify all sorts of fuzzy things.
<dael> Florian: If we exclude keyboards it's kind of bad. If we include them the MQ qill almost always return that you have a thing that can't hover.
<tantek> the keyboard/voice examples don't make sense
<dael> Florian: Overall I think we can tweak to try and expose, but any way is complicated and I don't see how the author would use this.
<tantek> because they never hover
<tantek> this should only be about pointing device inputs
<dael> fremy: I think I agree with you. I think we can fix it I don't see a strong use case and I would be fine resolving we don't need to fix.
<dael> tantek: It's pointless to talk about devices that can never hover as causing exceptions. I would assume author is thinking about can the pointing device support hovering. I don't think if authors are considering this also has a keyboard.
<dael> Florian: IN general, yes. Quoted use case was if you know among the ways a user can interact there is one that cannot hover you shouldn't make any part of UI to hover.
<gregwhitworth> nm, tantek is covering my question
<dael> tantek: That's impractical. Every device with hover has a keyboard since hover was created. I disagree with that statements. Authors have known for a long time there's an input modality that doesn't support hover.
<liam> [+1 to Tantek here]
<dael> tantek: Existance of some other input modality should not impact authoring decisions about using hover.
<dael> Florian: I think I agree. Where I'm disagreeing with commentor is if we were to take presense of thigns that can't hover, not taking keyboard owuld be weird.
<dael> tantek: The presense of pointing things, not the presense of things.
<tantek> "presence of things that can't hover" is not useful
<fantasai> A pointing device is one that can spit out x y coords. Keyboards can't do that in general (unless you've made them control the cursor somehow)
<dael> Florian: How is the presense of things that can point and not hover more useful? THat's the point I don't get.
<dael> tantek: This has nothing to do with things that can never hover. THis is pointing inputs that can't or can't hover.
<dael> astearns: One of the confusion points is in the comment Patrick talks about input devices, but clarifies that he's only talking about pointing devices.
<dael> tantek: That's mu understanding.
<tantek> s/mu/my
<dael> fremy: What can you do differently as an author if you know there's a device that cannot hover.
<dael> fremy: Every windows laptop has a touch screen. WHat would you do differently?
<dael> Florian: Maybe you may want to do something special for touch screen + touch pad, but the MQ wouldn't tell you that. IT would jsut say there's something that cannot hover. You don't know what it is, just just know it can't hover and it's not the main thing the user uses.
<dael> liam: If you know the user has something that doesn't hover you can't rely on every press havning hover pre-light.
<dael> Florian: It's not primary way. WE'd have an answer on the main way the user interacts.
<dael> liam: Sure, but doesn't matter if it's primary. The user could use it. IT's saying something useful
<MaRakow> +1 to feature not seeming useful
<dael> astearns: Even though the main device is hover capable, the presense of other non-hover modality makes it a better idea not to rely. Patrick points out he's happy with it saying try not to use hover with examples wehre there could be problems.
<tantek> has anyone prototyped any of these?
<dael> astearns: Sounds to me like using hover affordances is usually a bad idea. PAtrick is okay with the amount of warnings. I'm not hearing a huge push to add additional capability for these worse scenarios beyond what we have. Is that accurate?
<dael> tantek: I'd agree.
<dael> Florian: I'm trying to find that section. He's happy with that in addition to what he suggests.
<tantek> IMO this is a good example of a feature that really ought to be incubated (prototyped) before we seriously consider it
<dael> astearns: [reads last comment]
<tantek> I really don't want to see browsers waste time implementing a feature that just makes things worse / more confusing for authors / users
<tantek> hmm MQ4 is a WD almost a year old
<dael> astearns: Given we don't have enthusiasm for desgining a new way of detecting less hover capable devices, I'd be happy to close as-is and leaving open that we might design something in the future that has the additional case, but it should be prototyped. There should be an idea of the use caes and showing why it will be useful.
<dael> tantek: Does tha tmean leave the feature in?
<dael> Florian: any-hover is in the draft and it can take hover or none. You can detect if nothing is hovercapable, but you can't detect a mix. We're leaving that as-is
<fantasai> Sounds good to me. We can extend in the direction I outlined later, too, if we want. :)
<dael> astearns: And I understand the draft does have warnings that even if the MQ says something is hover capable you may not want to use hover affordances.
<dael> tantek: Has anyone impl?
<dael> Florian: I think pointer and hover are in Chrome. Maybe jsut pointer.
<dael> TabAtkins: I think we do both, but not 100% certain.
<dael> Florian: can i use says both on Chrome, edge & safari
<dael> astearns: Proposal is leave in draft and close no change. Obj?
<dael> RESOLVED: Close https://github.com//issues/841 no change.
<tantek> well if we has so many impls, seems like we should be able to try it out with examples?
<tantek> yes I'd like to see a new WD published please
<dael> Florian: I jsut noticed there's one issue on MQ DoC. Other then that we should do a new draft.
<dael> Florian: ASk issue is fantasai saying scripting-enabled should be called something else.
<Florian> https://drafts.csswg.org/mediaqueries-4/issues-wd-2016-01-26.html#issue-4
<tantek> we can do a new WD without completing DoC AFAIK
<dael> s/ASk/Last
<dael> Florian: fantasai do you remember what you wanted this to be called?
<dael> Florian: We discussed, but never concluded. Are you happy with scripting: enabled | none?
<tantek> oh interesting, this is missing a big use-case, headless script execution
<dael> fantasai: I think that's fine.
<dael> tantek: I think you're missing a massive use case, headless script execution.
<dael> Florian: That level of granularity was pushed to another level.
<dael> tantek: Yeah, okay.
<dael> astearns: Sounds like there's agreement.
<dael> Florian: Can we resolved current naming is okay?
<tantek> where is the proposed conclusion?
<dael> fantasai: Enabled means if there's any scripting at all it's true, even if only runs first 10ms?
<dael> Florian: Yes. There is sripting support. No fine grained knowledge of what.
<dael> fantasai: Is that clear in description?
<Florian> https://drafts.csswg.org/mediaqueries-4/#scripting
<tantek> lol none of the emails nor the DoC linked to the spec portion
<dael> Florian: [reads]
<dael> fantasai: That's not sufficiently clear
<dael> astearns: [reads more]
<dael> fantasai: That's a different question. This is going to flip on for things that run until onload event.
<dael> fantasai: An author won't think about those things. If they trigger enabled that needs to be super clear. This script may or may not run, this may only run for first few ms. It needs to be clearly spec what triggers it for both impl and developers. THat enabled doesn't mean you have event support.
<tantek> "enabled" does seem to imply too strong a level that we are committing to in this version
<tantek> "scripting: maybe" :P
<dael> Florian: Just because we marked it as at-risk and removed something doesn't mean what we left behind makes sense.
<tantek> q?
<fantasai> scripting: sort-of
<fantasai> scripting: some
<dael> ACTION Florian clarify the scripting section as per fantasai description in minutes.
<trackbot> Created ACTION-851 - Clarify the scripting section as per fantasai description in minutes. [on Florian Rivoal - due 2017-05-24].
<dael> Florian: Did we resolve name is fine?
<fantasai> scripting: somewhat
<dael> tantek: I'm curious if having this feature is worth it in level.
<dael> Florian: You'd like to push to sort out varients together?
<dael> tantek: That's what I'm hearing from the convo that it may be needed.
<dael> Florian: I think it's a good idea. Enabled value needs to mean a different thing depending on if loading should exist.
<dael> astearns: Is there a value in none even though non-none doesn't work as expected?
<dael> fantasai: Depends on what you're doing. If you're depending on event support you want to get none. But if you're depending on if this script will run then it's not important.
<dael> fantasai: I agree with tantek that it's good to have this together in a level
<dael> tantek: What people imple today in none in the static loaded website. I don't think we need another mech for only none.
<dael> Florian: I'm happy to push it all to L5.
<dael> Florian: Espeically since that's the last issue on L4 and we can do a last WD
<dael> astearns: Objections to pushing scripting to next L of MQ
<tantek> btw on previous issue, have we marked any-pointer any-hover at-risk?
<dael> RESOLVED: Pushing scripting MQ values to L5
<tantek> or are we not doing so because of impls?
<fantasai> go for it
<dael> astearns: Obj to new WD of MQ4?
<tantek> +1 new WD MQ4
<dael> RESOLVED: new WD of MQ4
<tantek> \o/
<dael> astearns: That will go for wide review.
<dael> Florian: tantek I don't think we need at risk b/c they're impl
<dael> tantek: Are they impl the way we want them to be? We don't want to codify something that would create bad authoring or confusion.
<dael> Florian: Agree. It's the part of the spec I'm least convinced we did right. If you want to at risk it now that's fine.
<dael> tantek: And that communicates to Patrick we hear your concerna nd we're making as at risk to keep looking at it.
<dael> Florian: Fair.
<dael> Florian: Do you want any-* as at risk or also pointer and hover.
<dael> tantek: I don't know how to seperate.
<dael> Florian: I'm okay with that.
<dael> tantek: And I think that would support more input from Patrick.
<dael> astearns: Do we need a resolution or is that editorial?
<dael> astearns: Obj to marking the various hover and pointer things as at-risk?
<dael> RESOLVED: mark the various hover and pointer things as at-risk

[frivoal]

@patrickhlauke in the log above, pushing the scripting MQs to L5 is not related to this issue.

Other than that, the WG felt that the use cases for being able to detect mixed hover and non-hover capable pointers were not compelling enough to justify the complexity needed to make that work, and decided to close this issue as no change.

However, recognizing that the whole set of pointer/any-pointer/hover/any-hover was not the part of the spec we're most confident it, and that it is possible that as implementations come in contact with reality or as we learn more about use cases, we may still need to adjust, we marked them at risk. That way, if need be, we can pull them to level 5 to tweak them some more without slowing down the rest of the spec.

Since this is a rejection of this issue you raised, I realize this is not the conclusion you were hoping for, but is this a conclusion you are willing to live with?

[patrickhlauke]

@tantek done

@frivoal at least the current shortcoming of any-hover is documented in the spec, so i'd say for now i can live with it. closing...