Interaction Media Features and Their Potential (for Incorrect Assumptions)

This article, a significantly expanded update of a 2015 dev.opera piece, clarifies misconceptions surrounding Media Queries Level 4 interaction media features (pointer, hover, any-pointer, any-hover). The original article misinterpreted any-hover: none; this version aligns with the latest working draft, addressing inconsistencies across browser implementations (see current test results and related bug reports).

Media Queries Level 4 aims to adapt website styling and functionality (CSS interactivity or JavaScript behavior via window.matchMedia) based on user input devices. While generally well-supported, implementation variations persist.

Common use cases involve adjusting control sizes based on touchscreen vs. mouse/stylus use, or conditionally enabling hover-based menus:

<code>@media (pointer: fine) {
 /* Mouse or stylus: small controls okay */
}
@media (pointer: coarse) {
 /* Touchscreen: larger touch targets */
}
@media (hover: hover) {
 /* Enable hover menus */
}
@media (hover: none) {
 /* Disable hover menus */
}</code>

Developers often leverage these features for touch detection, typically listening for touch events when pointer: coarse is detected:

if (window.matchMedia && window.matchMedia("(pointer:coarse)").matches) {
 /* Coarse pointer: listen for touch events */
 target.addEventListener("touchstart", ...);
} else {
 /* Otherwise, use mouse/keyboard events */
}

This approach, however, is simplistic and misunderstands the features' purpose.

Primary Input Limitations

pointer and hover only reveal the primary pointer input's characteristics. This may differ from the user's actual primary input, especially with blurred device/input lines. Crucially, these features don't detect keyboard-only users. Therefore, ensure keyboard accessibility regardless of query results.

A phone with a Bluetooth mouse might report pointer: coarse and hover: none, despite the user primarily using the mouse. Conversely, a Surface tablet might primarily use the trackpad (pointer: fine), but the user might prefer the touchscreen.

This problem is addressed by any-pointer and any-hover.

Assessing All Inputs

any-pointer and any-hover reflect the combined capabilities of all pointer inputs. Multiple values can match if inputs have differing characteristics. Current implementations generally behave as follows:

To improve on the original use cases, base decisions on all pointer inputs: "If any input is coarse, enlarge controls," and "Enable hover menus if at least one input supports hover."

<code>@media (any-pointer: coarse) {
 /* At least one coarse pointer: larger controls */
}
@media (any-hover: hover) {
 /* At least one hover-capable input: enable hover menus */
}</code>

any-pointer: none is true only if no pointer inputs exist. any-hover: none is true only if none of the inputs support hover, making it largely redundant.

Combining Queries for Nuance

Combine queries for refined assessments:

<code>@media (pointer: coarse) and (any-pointer: fine) {
 /* Primary input is touchscreen, but a fine input exists. Prioritize touch, but mouse/stylus users can still interact. */
}
@media (pointer: fine) and (any-pointer: coarse) {
 /* Primary input is mouse/stylus, but a touchscreen exists.  Larger controls might be safest. */
}
@media (hover: none) and (any-hover: hover) {
 /* Primary input lacks hover, but another input supports it.  Treat hover as optional. */
}</code>

Browsers dynamically re-evaluate queries in response to environmental changes (e.g., adding a Bluetooth mouse).

Scripting May Be Necessary

Interaction media features don't indicate the currently used input. Tools like What Input? track JavaScript events, but this only provides information after interaction begins, and can be inaccurate due to faked events (assistive technologies, iOS Full Keyboard Support).

Avoiding Broken Experiences

Event-based touch detection (pointer: coarse -> listen for touch events) is flawed. It prevents using non-touchscreen inputs on touch devices and touchscreen inputs on primarily mouse-driven devices. Instead, always listen for mouse/keyboard events, and add touch event listeners only if any-pointer: coarse is true:

/* Always listen to mouse/keyboard events */
target.addEventListener("click", ...);

if (window.matchMedia && window.matchMedia("(any-pointer: coarse)").matches) {
 /* If a coarse pointer exists, also listen for touch events */
 target.addEventListener("touchstart", ...);
}

Alternatively, use pointer events for unified input handling.

Explicit User Choice

Provide a user-selectable mode (touch/mouse) to avoid input detection pitfalls. Use media queries to inform the default setting, and detect touch input to prompt a mode switch.

Responsible Querying

Understand the limitations of interaction media features. Don't assume a single input type, rely solely on pointer and hover, or neglect keyboard accessibility. Instead, prioritize touch-friendliness, offer user choice, and always ensure keyboard accessibility.

The above is the detailed content of Interaction Media Features and Their Potential (for Incorrect Assumptions). For more information, please follow other related articles on the PHP Chinese website!