W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2017

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

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 May 2017 08:14:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-299802178-1494231274-sysbot+gh@w3.org>
@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.



-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/841#issuecomment-299802178 using your GitHub account
Received on Monday, 8 May 2017 08:14:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:12:53 UTC