-
Notifications
You must be signed in to change notification settings - Fork 659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mediaqueries-4] any-hover can't be used to detect mixed hover and non-hover capable pointers #841
Comments
/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 |
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( |
with the proposed change, you can detect the opposite situation that may lead you to the same decision. the primary being hover capable ( |
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 |
scenario here would be for instance: laptop with a touchscreen. primary input is the trackpad/mouse ( with the proposed change, authors would be able to see that yes, while |
@frivoal ... did the above make sense to clarify my particular desire/use case? wondering, if there is definitely no chance to change the way |
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:
Case2:
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:
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. |
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 Nonetheless, I'd be interested in what others in the CSSWG think (to either changing when |
@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) |
The CSS Working Group just discussed
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 |
@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? |
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 whyany-pointer
behaves the way it does, which I tried to more explicitly point out in #842)any-hover
, as currently specified, only evaluates tonone
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:
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)any-hover:hover
will evaluate to false,any-hover:none
evaluates to trueScenarios that can't be tested (as they return the same as the "at least one..." scenario above):
any-hover:hover
will evaluate to true,any-hover:none
will evaluate to falseany-hover:hover
will evaluate to true,any-hover:none
will evaluate to falseAs 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 whenany-hover:none
evaluates as follows:any-hover: none
should evaluate to trueany-hover: hover
should evaluate to trueany-hover: none
should be true andany-hover: hover
should be falseany-hover: none
should be false andany-hover: hover
should be trueany-hover: none
andany-hover: hover
should evaluate to trueGoing back to the original scenarios, this would then allow to capture all possible states:
any-hover:hover
will evaluate to true (as before)any-hover:hover
will evaluate to false,any-hover:none
evaluates to true (as before)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 beforeany-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 tonone
, this now actually gives you confidence in theany-hover:none
to mean "none of the pointing devices is non-hover-capable)The text was updated successfully, but these errors were encountered: