- From: micolous via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2024 06:34:19 +0000
- To: public-css-archive@w3.org
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](https://www.w3.org/TR/mediaqueries-4/#any-input) (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](https://www.w3.org/TR/mediaqueries-4/#descdef-media-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](https://github.com/mdn/browser-compat-data/issues/24451) (several browser bugs are linked from there). There are also [devices which defy classification](https://firefox-source-docs.mozilla.org/widget/windows/windows-pointing-device/index.html#selection-of-the-primary-pointing-device) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1735765). Rather than adding another state to `any-hover`, I propose a new query, `all-hover`, 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1918292)). `all-hover: hover` would then provide a clear and reliable signal which could be used defensively with something like: ```css @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! */ } ``` -- GitHub Notification of comment by micolous Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5462#issuecomment-2354650820 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 17 September 2024 06:34:20 UTC