css.at-rules.media.hover, css.at-rules.media.pointer - Inaccurate results on Android, ChromeOS, Safari on iOS, Windows
Nobody has claimed this yet.
- Dominant language
- JSON
- Stars
- 5.8k
- Forks
- 2.6k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 186
Description
What type of issue is this?
Browser bug (a bug with a feature that may impact site compatibility)
What information was incorrect, unhelpful, or incomplete?
The Media Queries Level 4 specification defines several behaviours for primary pointing devices, which affect the hover and pointer media queries.
The primary pointing device is defined as:
While this specification does not define how user agents should decide what the “primary” pointing device is, the expectation is that user agents should make this determination by combining knowledge about the device/environment they are running on, the number and type of pointing devices available, and a notion of which of these is generally and/or currently being used. In situations where the primary input mechanism for a device is not a pointing device, but there is a secondary – and less frequently used – input that is a pointing devices, the user agent may decide to treat the non-pointing device as the primary (resulting in 'pointer: none'). user agents may also decide to dynamically change what type of pointing device is deemed to be primary, in response to changes in the user environment or in the way the user is interacting with the UA.
There are gaps in the way this works on multiple platforms, as they do not seem to change based on how the user is interacting with the browser, and use limited information about hardware being used:
-
Android: Some devices (eg: OnePlus, Samsung) report a virtual mouse device which Chromium and Firefox treat like an actual mouse – and the primary pointing device.
My understanding is that this is a bug in certain OEM's Android builds, and it is difficult to filter this out on an application level. OnePlus has fixed it, Samsung has not.
-
Chrome on ChromeOS: If a mouse is connected to a touch-only (or convertible) device, it is always treated as the primary pointing device, even if the touchscreen is used. It seems to be connected to ChromeOS tablet mode.
-
Safari on iOS: always reports the primary pointing device is the touchscreen (
pointer: coarse, hover: none), even when using hover-capable peripherals (Apple Pencil, Magic Keyboard, mouse), or using an external display in "extended" mode (Stage Manager).Also, the Apple Pencil (stylus) is hover-capable, but never triggers
any-hover: hover. -
Windows: All Windows desktop browsers only ever treat touch devices with an auto-rotation sensor and supporting "tablet mode" as being touch-first devices (eg: Microsoft Surface Pro).
PCs without an auto-rotation sensor (such as a desktop PC with a HDMI touchscreen monitor) are never considered as having the touch screen as the primary pointing device, even if it is the only pointing or keyboard device attached, and there are no virtual devices attached.
As a result, a web developer cannot rely on pointer or hover media queries correctly indicating a user's preference or device attributes.
What browsers does this problem apply to, if applicable?
Chromium (Chrome, Edge 79+, Opera, Samsung Internet), Firefox
What did you expect to see?
Many browsers should be listed as partially supporting pointer and hover, with caveats:
-
Desktop Windows: Chromium and Firefox based browsers should caveat they report an ordinary mouse (with
pointer: fine, hover: hover) as the primary input device on a touch device which lacks an auto-rotation sensor (eg: desktop PC with touchscreen monitor). -
Desktop ChromeOS: touch/tablet devices treat the mouse as a primary pointing device if one is connected, even if the user is still using the touchscreen.
-
Android: Chromium and Firefox based browsers should caveat that some Android devices have a virtual mouse device which the browser treats as the primary pointing device, even when it only has a touchscreen and no pen input (eg: mobile phone).
-
Safari on iOS: should caveat that the touchscreen is always treated as the primary pointing device, and that the hover-capable Apple Pencil does not report as supporting hover.
One could use any-pointer: coarse as a rough approximation for "is touch supported on this device", but it would mix in with Wiimote-style inputs (which can hover), as there is no signal like any-hover: at least one pointing can't hover.
Did you test this? If so, how?
Not my page, but illustrates the media query results for pointer, hover, any-pointer and any-hover: https://mustaqahmed.github.io/web/mq-test.html
A touchscreen device being used with its touchscreen should report:
- pointer: coarse
- hover: none
Instead, it reports like a mouse device:
- pointer: fine
- hover: hover
If there is only a touchscreen attached, it should also report:
- any-pointer: coarse
- any-hover: none
This works correctly on iOS, though iOS always treats the touchscreen as primary.
Can you link to any release notes, bugs, pull requests, or MDN pages related to this?
Bugs:
- Chromium Windows bug: https://issues.chromium.org/issues/366055333
- Chromium Android bug: https://issues.chromium.org/issues/41445959
- Chromium ChromeOS bug: https://issues.chromium.org/issues/366056633
- Firefox bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1735765 https://bugzilla.mozilla.org/show_bug.cgi?id=1918292
MDN:
hovermedia query: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hoverpointermedia query: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer
Do you have anything more you want to share?
No response
MDN URL
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover
MDN metadata
MDN page report details
- Query:
css.at-rules.media.hover - Report started: 2024-09-17T02:56:11.759Z
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin with the MDN hover and pointer pages and the linked Chromium and Firefox bugs to verify the platform-specific behavior described. Locate the corresponding compatibility data entries for both media queries, then record the supported caveats for Android, ChromeOS, iOS, and Windows and confirm both queries are covered consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- documentation, web-dev
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100