mdn / mdn/browser-compat-data

css.at-rules.media.hover, css.at-rules.media.pointer - Inaccurate results on Android, ChromeOS, Safari on iOS, Windows

Open
#24,451 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

browser:multiple data:css
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:

MDN:

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.