CSS Media Features and User Preferences

Intermediate

Media features let CSS observe characteristics of the current output environment; user-preference features let CSS respond to choices or accessibility-related settings exposed by the user agent; color-adjustment controls define how author styling interacts with automatic color adaptation. This lesson is the primary owner for those meanings.

The previous Media Queries and Conditional Rules lesson owns the conditional-processing language: how @media is parsed, combined, negated, and evaluated. This lesson does not repeat that syntax. Instead, it answers the next question: what does a particular media feature describe, and what should an author do with that information?

Feature values are observations, not breakpoints

A media feature reports a characteristic such as viewport width, pointer capability, color gamut, dynamic range, or a user preference. The value belongs to the environment being queried; it is not a promise that a particular layout breakpoint is universally correct.

?

Discrete versus range features

Some features have discrete keywords, while others are naturally numeric and can be compared with ranges. Treating every feature as a breakpoint is a mistake: the feature’s value model determines what comparisons make sense.

?

Viewport width is not the same thing as component width

Viewport media features describe the media environment. A component’s own available space is a container-query concern. If a component must adapt when its parent changes size inside a stable viewport, use the Container Queries owner instead of inventing viewport breakpoints.

?

Pointer and hover capabilities

The pointer and hover features describe interaction capabilities rather than the identity of a device. A coarse pointer can represent touch-like interaction, while a fine pointer can support more precise pointing. Hover capability answers whether the primary input mechanism can conveniently hover.

?

Primary versus any pointer capabilities

The primary-pointer features describe the primary pointing mechanism. The any-pointer and any-hover features ask whether any available pointing mechanism has the capability. That distinction matters on hybrid devices where more than one input mechanism can coexist.

?

Reduced motion is a user preference

prefers-reduced-motion exposes whether the user has requested reduced non-essential motion. The query is a signal to adapt motion-heavy presentation; it is not a command to remove functionality or interaction.

?

No-preference is not permission to assume a need for motion

The no-preference state means the user has not requested reduced motion through that feature. It does not establish that animation is desirable, necessary, or accessible in every context.

?

Reduced transparency

prefers-reduced-transparency is a user preference for reducing transparent or translucent visual effects. Authors can provide a more opaque alternative while preserving content and structure.

?

Contrast preference

prefers-contrast reports a user preference for more, less, or no specific contrast preference when the user agent exposes one. It can be used to select a presentation that better fits the requested contrast relationship.

?

Color scheme preference

prefers-color-scheme reports the user agent’s preferred color scheme, commonly light or dark. The feature describes a preference; the CSS color-scheme property separately tells the user agent which schemes the document supports and can affect the rendering of user-agent-provided UI.

?

Forced colors mode

forced-colors indicates that the user agent is applying a forced color palette. In this mode, authors should avoid fighting the user agent’s chosen system colors and should understand which author colors may be adjusted.

?

Color gamut

color-gamut describes the approximate gamut supported by the output device. Values such as srgb, p3, and rec2020 allow authors to conditionally use colors that depend on wider output capabilities.

?

Dynamic range

dynamic-range describes the output device’s dynamic-range capability. It can distinguish standard dynamic range from higher dynamic-range environments when the user agent exposes those values.

?

Resolution and other display characteristics

Media Queries also expose display characteristics such as resolution and aspect ratio. Use them when the actual environment characteristic matters; do not turn every available feature into a breakpoint just because it exists.

?

Print is a media type, not a user preference

The print media type describes a different output medium. Print-specific layout belongs to the media-query and paged-media interaction already covered by the relevant owners; it should not be conflated with user-preference media features.

?

Light-level and inverted-colors: status-sensitive features

Media Queries Level 5 contains additional features whose implementation and authoring status can evolve. Features such as light-level and inverted-colors should be treated as status-sensitive rather than presented as universally reliable foundations.

?

User preference is not a command to redesign semantics

A preference query should normally alter presentation while keeping document meaning and interaction intact. CSS can change color, motion, spacing, decoration, or other presentation without replacing semantic HTML or removing necessary controls.

?

Feature combinations

Different media features can be combined when a real requirement depends on more than one characteristic. Keep each condition understandable: one condition should answer one environmental question, and the combined expression should correspond to an actual design rule.

?

Do not infer device identity

Features describe capabilities and preferences, not product names. A tablet, laptop, phone, or hybrid device can expose overlapping capabilities. Author CSS should respond to the observable characteristic that matters.

?

Interaction with the cascade

A matching media condition does not outrank another declaration by itself. Once the condition admits its nested rules, the ordinary cascade decides among participating declarations. This lesson supplies feature meaning; the Cascade lesson owns conflict resolution.

?

Interaction with animations and transitions

Motion preferences can conditionally change CSS animation and transition behavior, but the animation and transition owners explain the underlying interpolation and timing models. This lesson owns why a preference condition is used, not the animation algorithm.

?

Interaction with color

The Color lesson owns color values, spaces, interpolation, and gamut mapping. This lesson owns when a color choice should respond to a preference or output capability. The two concerns interact but should not be merged.

?

Interaction with Color Adjustment

CSS Color Adjustment defines how the user agent can adapt colors and how authors can declare supported schemes or opt into or out of specific automatic adjustments. This is different from merely choosing colors inside a media query.

?

Authoring strategy: query the smallest useful fact

Start with the presentation requirement, then identify the smallest media feature that describes it. “I need more space” may be width. “I need to avoid motion” is a preference. “I need a wider gamut color” is an output capability. Avoid encoding a device taxonomy when a direct feature exists.

?

Testing preference-aware CSS

Test the state you are targeting, not only the default state. A reduced-motion rule should be inspected with reduced motion enabled; forced-colors behavior should be inspected in forced-colors mode; dark-mode rules should be checked under both supported schemes.

?

A feature is not a guarantee of exact hardware behavior

Media-query features are defined abstractions exposed by the user agent. They are useful because authors can reason about capabilities without knowing the hardware implementation, but the abstraction should not be stretched into promises it does not make.

?

Stable core versus developing surface

For this curriculum, the stable core includes established media-feature categories and user-preference features with defined semantics. Developing Level 5 additions and newer preference proposals are marked as developing and are not treated as universal compatibility guarantees.

Current Media Queries Level 5 surface: teach it with status labels

The current Media Queries Level 5 Working Draft adds several media features beyond the established core. They belong to this lesson because they are still media features, but they must be taught as developing specification material rather than as universally settled CSS. The current draft marks `update` as at-risk and includes features such as `overflow-block`, `overflow-inline`, `horizontal-viewport-segments`, `vertical-viewport-segments`, `environment-blending`, `nav-controls`, `scripting`, and `prefers-reduced-data`.

Reduced-data is a preference query

`prefers-reduced-data: reduce` lets authors adapt resource-heavy or data-heavy presentation to a user preference. It is a media feature, not a command to remove meaningful content or accessibility information.

?

Output update rate is different from animation timing

`update` describes whether the output can update after rendering and, when it can, whether updates are slow or fast enough for ordinary dynamic presentation. The current Level 5 draft marks `update` at-risk, so treat it as developing material.

?

Foldable and segmented viewports

`horizontal-viewport-segments` and `vertical-viewport-segments` report the logical number of viewport segments created by a hardware divider such as a fold or hinge. These features are specialized and developing; do not infer a device model from them.

?

The same current draft also defines `overflow-block`, `overflow-inline`, `environment-blending`, `nav-controls`, and `scripting`. These are specialized media features and should be used only when the author's design genuinely depends on the capability they report. Keep their developing-spec status visible in production guidance.

Ownership decision tree

If the condition describes the output environment, start here. If it describes a component’s query container, use Container Queries. If the question is how the condition syntax is combined, use Media Queries / Conditional Rules. If the question is how the color value itself is represented, use Color. If the question is general containment, use Containment.

?

<p class="?ice">The message remains available without animation.</p>

.status { color: CanvasText; background: Canvas; }
.status { ?: auto; }

Practical authoring rules

1. Query capabilities and preferences, not device names. 2. Preserve semantics and required interaction when adapting presentation. 3. Keep preference adaptations targeted. 4. Treat forced colors as a user-agent mode, not merely another theme. 5. Test both sides of preference conditions. 6. Label developing features honestly. 7. Keep container-local conditions in the Container Queries owner.

What this lesson deliberately does not own

It does not own media-query grammar, boolean parsing, or conditional-rule mechanics; those belong to Media Queries / Conditional Rules. It does not own container evaluation; that belongs to Container Queries. It does not own color-space mathematics; that belongs to Color. It does not own automatic color-adaptation controls; those belong to Color Adjustment. It does not own animation algorithms, scroll behavior, or layout algorithms. It also does not turn accessibility guidance into a CSS specification: it teaches the CSS mechanisms that expose preferences and adaptation modes.

Quick self-audit

Before shipping preference-aware CSS, ask: What exact feature am I querying? What presentation requirement does it satisfy? What remains usable if the condition changes? Have I tested the alternate state? Am I fighting a user-agent adjustment mode? Am I duplicating a container query or general color/layout rule that belongs elsewhere?

?