Abstract

Media Queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and Javascript.

Media Queries Level 4 describes the mechanism and syntax of media queries, media types, and media features. It extends and supersedes the features defined in Media Queries Level 3.

CSS is a language for describing the rendering of structured documents
(such as HTML and XML)
on screen, on paper, in speech, etc.

Status of this document

This section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports
index at http://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.

GitHub Issues are preferred for discussion of this specification.
When filing an issue, please put the text “mediaqueries” in the title,
preferably like this:
“[mediaqueries] …summary of comment…”.
All issues and comments are archived,
and there is also a historical archive.

1. Introduction

This section is not normative.

HTML4 [HTML401] defined a mechanism to support media-dependent style sheets,
tailored for different media types.
For example, a document may use different style sheets for screen and for print.
In HTML, this can be written as:

1.2. Values

1.3. Units

The units used in media queries are the same as in other parts of CSS, as
defined in [CSS3VAL]. For example, the pixel unit represents CSS pixels and
not physical pixels.

Relative length units in media queries are based on the initial value, which means
that units are never based on results of declarations. For example, in HTML,
the em unit is relative to the initial value of font-size,
defined by the user agent or the user’s preferences,
not any styling on the page.

2. Media Queries

A media query is a method of testing certain aspects of the user agent
or device that the document is being displayed in. Media queries are (almost) always independent of the contents of the document,
its styling,
or any other internal aspect;
they’re only dependent on “external” information
unless another feature explicitly specifies that it affects the resolution of Media Queries,
such as the @viewport rule.

Statements regarding media queries in this section assume the syntax section is followed.
Media queries that do not conform to the syntax are discussed in §3.2 Error Handling.
I.e. the syntax takes precedence over requirements in this section.

This example expresses that a certain style sheet
(example.css) applies to devices of a certain media type
(screen) with certain feature (it must be a color screen).

Here is the same media query written in an @import-rule in CSS:

@import url(example.css) screen and (color);

User agents must re-evaluate media queries in response to changes in the user environment that they’re aware of,
for example if the device is tiled from landscape to portrait orientation,
and change the behavior of any constructs dependent on those media queries accordingly.

Unless another feature explicitly specifies that it affects the resolution of Media Queries, it is never necessary to apply a style sheet in order to evaluate expressions.

An individual media query can have its result negated
by prefixing it with the keyword not.
If the media query would normally evaluate to true,
prefixing it with not makes it evaluate to false,
and vice versa.

For example, the following will apply to everything except color-capable screens.
Note that the entire media query is negated,
not just the media type.

The concept of media queries originates from HTML4 [HTML401].
That specification only defined media types,
but had a forward-compatible syntax that accommodated the addition of future concepts like media features:
it would consume the characters of a media query up to the first non-alphanumeric character,
and interpret that as a media type,
ignoring the rest.
For example, the media queryscreen and (color) would be truncated to just screen.

Unfortunately, this means that legacy user agents using this error-handling behavior
will ignore any media features in a media query,
even if they’re far more important than the media type in the query.
This can result in styles accidentally being applied in inappropriate situations.

Note: At the time of publishing this specification,
such legacy user agents are extremely rare,
and so using the only modifier is rarely, if ever, necessary.

2.3. Media Types

A media type is a broad category of user-agent devices
on which a document may be displayed.
The original set of media types were defined in HTML4,
for the media attribute on <link> elements.

Unfortunately, media types have proven insufficient as a way of discriminating between devices with different styling needs.
Some categories which were originally quite distinct,
such as screen and handheld,
have blended significantly in the years since their invention.
Others, such as tty or tv,
expose useful differences from the norm of a full-featured computer monitor,
and so are potentially useful to target with different styling,
but the definition of media types as mutually exclusive
makes it difficult to use them in a reasonable manner;
instead, their exclusive aspects are better expressed as media features such as grid or scan.

In addition, the following deprecatedmedia types are defined.
Authors must not use these media types;
instead, it is recommended that they select appropriate media features that better represent the aspect of the device that they are attempting to style against.

User agents must recognize the following media types as valid,
but must make them match nothing.

tty

tv

projection

handheld

braille

embossed

aural

Note: It is expected that all of the media types will also be deprecated in time,
as appropriate media features are defined which capture their important differences.

2.4. Media Features

A media feature is a more fine-grained test than media types,
testing a single, specific feature of the user agent or display device.

Syntactically, media features resemble CSS properties:
they consist of a feature name, a colon, and a value to test for.
They may also be written in boolean form as just a feature name,
or in range form with a comparison operator.

( feature name : feature value feature name range form (see below) )

There are, however, several important differences between properties and media features:

Properties are used to give information about how to present a document.
Media features are used to describe requirements of the output device.

Media features are always wrapped in parentheses
and combined with the and keyword,
like (color) and (min-width: 600px),
rather than being separated with semicolons.

A media feature may be given with only its name
(omitting the colon and value)
to evaluate the feature in a boolean context.
This is a convenient shorthand for features that have a reasonable value representing 0 or “none”.
For example, (color) is true is the colormedia feature is non-zero.

Properties sometimes accept complex values,
e.g., calculations that involve several other values. Media features only accept single values: one keyword, one number, etc.

If a media feature references a concept which does not exist on the device where the UA is running
(for example, speech UAs do not have a concept of “width”),
the media feature must always evaluate to false.

The media feature device-aspect-ratio only applies to
visual devices. On an speech device, expressions involving device-aspect-ratio will therefore always be false:

2.4.1. Media Feature Types: “range” and “discrete”

Every media feature defines its “type” as either “range” or “discrete” in its definition table.

“Discrete” media features,
like pointer or scripting,
take their values from a set.
The values may be keywords
or boolean numbers (0 and 1),
but the common factor is that there’s no intrinsic “order” to them—none of the values are “less than” or “greater than” each other.

“Range” media features like width, on the other hand,
take their values from a range.
Any two values can be compared to see which is lesser and which is greater.

The only significant difference between the two types is that “range” media features can be evaluated in a range context and accept “min-” and “max-” prefixes on their name.
Doing either of these changes the meaning of the feature—rather than the media feature being true when the feature exactly matches the given value,
it matches when the feature is greater than/less than/equal to the given value.

A ''(width >= 600px)'' media feature is true
when the viewport’s width is 600pxor more.

On the other hand, (width: 600px) by itself is only true
when the viewport’s width is exactly600px.
If it’s less or greater than 600px, it’ll be false.

2.4.2. Evaluating Media Features in a Boolean Context

While media features normally have a syntax similar to CSS properties,
they can also be written more simply as just the feature name,
like (color).

When written like this, the media feature is evaluated in a boolean context.
If the feature would be true for any value other than the number 0,
a <dimension> with the value 0,
or the keyword none,
the media feature evaluates to true.
Otherwise, it evaluates to false.

For example, scripting is typically written as (scripting) to test if scripting is enabled,
or not (scripting) to see if it’s disabled.

It can still be given an explicit value as well,
with (scripting: enabled) equal to (scripting),
and (scripting: none) equal to not (scripting).

Some numeric media features, like width,
are rarely if ever useful to evaluate in a boolean context,
as their values are almost always greater than zero.
Others, like color, have meaningful zero values: (color) is identical to (color > 0),
indicating that the device is capable of displaying color at all.

For example, (pointer) is useful,
as pointer has a none value to indicate there’s no pointing device at all on the device.
On the other hand, (scan) is just always true or always false
(depending on whether it applies at all to the device),
as there’s no value that means “false”.

2.4.3. Evaluating Media Features in a Range Context

Media features with a “range” type can be alternately written in a range context that takes advantage of the fact that their values are ordered,
using ordinary mathematical comparison operators:

The remaining forms,
with the feature name nested between two value comparisons,
returns true if both comparisons are true.

For example, (400px < width < 1000px) returns true if the viewport width is between 400px and 1000px (but not equal to either).

2.4.4. Using “min-” and “max-” Prefixes On Range Features

Rather than evaluating a “range” type media feature in a range context,
as described above,
the feature may be written as a normal media feature,
but with a “min-” or “max-” prefix on the feature name.

This is equivalent to evaluating the feature in a range context,
as follows:

Using a “min-” prefix on a feature name is equivalent to using the “>=” operator.
For example, (min-height: 600px) is equivalent to ''(height >= 600px)''.

Using a “max-” prefix on a feature name is equivalent to using the “<=” operator.
For example, (max-width: 40em) is equivalent to ''(width <= 40em)''.

“Discrete” type properties do not accept “min-” or “max-” prefixes.
Adding such a prefix to a “discrete” type media feature simply results in an unknown feature name.

For example, (min-grid: 1) is invalid,
because grid is a “discrete” media feature,
and so doesn’t accept the prefixes.
(Even though the gridmedia feature appears to be numeric,
as it accepts the values 0 and 1.)

2.5. Combining Media Features

Multiple media features can be combined together into a media condition using full boolean algebra
(not, and, or).

Any media feature can be negated by placing not before it.
For example, not (color) inverts the meaning of (color)—since (color) matches a device with any kind of color display, not (color) matches a device without any kind of color display.

Two or more media features can be chained together,
such that the query is only true if all of the media features are true,
by placing and between them.
For example, (width < 600px) and (height < 600px) only matches devices whose screens are smaller than 600px wide in both dimensions.

Alternately, two or more media features can be chained together,
such that the query is true if any of the media features are true,
by plaing or between them.
For example, (update: slow) or (hover: none) matches if the device is slow to update the screen (such as an e-reader) or the device has no hover capability,
perhaps indicating that one should use a layout that displays more information
rather than compactly hiding it until the user hovers.

Media conditions can be grouped by wrapping them in parentheses () which can then be nested within a condition the same as a single media query.
For example, (not (color)) or (hover) is true on devices that are monochrome
and/or that have hover capabilities.
If one instead wanted to query for a device that was monochrome and didn’t have hover capabilities,
it must instead be written as not ((color) or (hover)) (or, equivalently, as (not (color)) and (not (hover))).

It is invalid to mix and and or and not at the same “level” of a media query.
For example, (color) and (pointer) or (hover) is illegal,
as it’s unclear what was meant.
Instead, parentheses can be used to group things using a particular joining keyword,
yielding either (color) and ((pointer) or (hover)) or ((color) and (pointer)) or (hover).
These two have very different meanings:
if only (hover) is true,
the first one evaluates to false
but the second evaluates to true.

3. Syntax

Informal descriptions of the media query syntax appear in the prose and railroad diagrams in previous sections.
The formal media query syntax is described in this section,
with the rule/property grammar syntax defined in [CSS3SYN] and [CSS3VAL].

Note: Whitespace is required between a not, and, or or keyword
and the following ( character,
because without it that would instead parse as a <function-token>.
This is not made explicitly invalid because it’s already covered by the above grammar.
It’s fine to have whitespace between a ) and a following keyword,
however.

Authors must not use <general-enclosed> in their stylesheets. It exists only for future-compatibility,
so that new syntax additions do not invalidate too much of a <media-condition> in older user agents.

If the result of any of the above productions
is used in any context that expects a two-valued boolean,
“unknown” must be converted to “false”.

Note: This means that,
for example,
when a media query is used in a @media rule,
if it resolves to “unknown” it’s treated as “false”
and fails to match.

Media Queries use a three-value logic where terms can be “true”, “false”, or “unknown”.
Specifically, it uses the Kleene 3-valued logic.
In this logic, “unknown” means “either true or false, but we’re not sure which yet”.

In general, an unknown value showing up in a formula will cause the formula to be unknown as well,
as substituting “true” for the unknown will give the formula a different result than substituting “false”.
The only way to eliminate an unknown value is to use it in a formula that will give the same result
whether the unknown is replaced with a true or false value.
This occurs when you have “false AND unknown” (evaluates to false regardless)
and “true OR unknown” (evaluates to true regardless).

This logic was adopted because <general-enclosed> needs to be assigned a truth value.
In standard boolean logic, the only reasonable value is “false”,
but this means that not unknown(function) is true,
which can be confusing and unwanted.
Kleen’s 3-valued logic ensures that unknown things will prevent a media query from matching,
unless their value is irrelevant to the final result.

3.2. Error Handling

A media query that does not match the grammar in the previous section must be replaced by not all during parsing.

Note: Note that a grammar mismatch does not wipe out an entire media query list,
just the problematic media query.
The parsing behavior defined above automatically recovers at the next top-level comma.

Both of the above media query lists are turned into not all, speech during parsing,
which has the same truth value as just speech.

Note that error-recovery only happens at the top-level of a media query;
anything inside of an invalid parenthesized block
will just get turned into not all as a group.
For example:

@media (example, speech { /* rules for speech devices */ }

Because the parenthesized block is unclosed,
it will contain the entire rest of the stylesheet from that point
(unless it happens to encounter an unmatched “)” character somewhere in the stylesheet),
and turn the entire thing into a not allmedia query.

Remember that some keywords aren’t allowed as <media-type>s
and cause parsing to fail entirely:
the media query or and (color) is turned into not all during parsing,
rather than just treating the or as an unknown media type.

The orientation feature does not accept prefixes,
so this is considered an unknown media feature,
and turned into not all.

The media query (color:20example) specifies an unknown value for the color media feature
and is therefore turned into not all.

This media query is turned into not all because negative lengths are not allowed for the width media feature:

@media (min-width: -100px) { … }

Note that media queries are also subject to the parsing rules of the host language.
For example, take the following CSS snippet:

@media test;,all { body { background:lime } }

The media query test;,all is, parsed by itself,
equivalent to not all, all, which is always true.
However, CSS’s parsing rules cause the @media rule,
and thus the media query,
to end at the semicolon.
The remainder of the text is treated as a style rule
with an invalid selector and contents.

4. Viewport/Page Dimensions Media Features

The width media feature describes the width of the targeted display area of the output device.
For continuous media, this is the width of the viewport
(as described by CSS2, section 9.1.1 [CSS21])
including the size of a rendered scroll bar (if any).
For paged media, this is the width of the page box
(as described by CSS2, section 13.2 [CSS21]).

The height media feature describes the height of the targeted display area of the output device.
For continuous media, this is the height of the viewport including the size of a rendered scroll bar (if any).
For paged media, this is the height of the page box.

The aspect-ratio media feature is defined as the ratio of the value of the width media feature
to the value of the height media feature.

The <ratio> value type is a positive (not zero or negative) <integer> followed by optional whitespace, followed by a solidus ('/'),
followed by optional whitespace, followed by a positive <integer>. <ratio>s can be ordered or compared by transforming them into the number
obtained by dividing their first <integer> by their second <integer>.

5. Display Quality Media Features

The resolution media feature describes the resolution of the output
device, i.e. the density of the pixels, taking into account the page zoom but assuming a pinch zoom of 1.0.

When querying media with non-square pixels, resolution queries the density in the vertical dimension.

For printers, this corresponds to the screening resolution
(the resolution for printing dots of arbitrary color).
Printers might have a different resolution for grayscale printing.

For output mediums that have no physical constraints on resolution
(such as outputting to vector graphics),
this feature must match the infinite value.
For the purpose of evaluating this media feature in the range context, infinite must be treated as larger than any possible <resolution>.
(That is, a query like (resolution > 1000dpi) will be true for an infinite media.)

This media query simply detects “high-resolution” screens
(those with a hardware pixel to CSS px ratio of at least 2):

@media (resolution >= 2dppx)

For example, this media query expresses that a style sheet is used on devices with resolution greater than 300 dots per CSS in:

<resolution> does not refer to the number of device pixels per physical length unit,
but the number of device pixels per css unit.
This mapping is done by the user agent,
so it is always known to the user agent.

If the user agent either has no knowledge of the geometry of physical pixels,
or knows about the geometry physical pixels and they are (close enough to)
square, it would not map a different number of device pixels per css pixels
along each axis, and the would therefore be no difference between the vertical
and horizontal resolution.

Otherwise, if the UA choses to map a different number along each axis,
this would be to respond to physical pixels not being square either. How
the UA comes to this knowledge is out of scope, but having enough information
to take this decision, it can invert the mapping should the device be rotated 90 degrees.

The scan media feature describes the scanning process of some output devices.

interlace

CRT and some types of plasma TV screens used “interlaced” rendering,
where video frames alternated between specifying only the “even” lines on the screen
and only the “odd” lines,
exploiting various automatic mental image-correction abilities to produce smooth motion.
This allowed them to simulate a higher FPS broadcast at half the bandwidth cost.

When displaying on interlaced screens,
authors should avoid very fast movement across the screen to avoid “combing”,
and should ensure that details on the screen are wider than 1px to avoid “twitter”.

progressive

A screen using “progressive” rendering displays each screen fully,
and needs no special treatment.

Most modern screens, and all computer screens, use progressive rendering.

For example, the “feet” of letters in serif fonts are very small features that can provoke “twitter” on interlaced devices.
The scan media feature can be used to detect this,
and use an alternative font with less chance of “twitter”:

The grid media feature is used to query whether the output device is grid or bitmap.
If the output device is grid-based
(e.g., a “tty” terminal, or a phone display with only one fixed font),
the value will be 1.
Otherwise, the value will be 0.

The <mq-boolean> value type is an <integer> with the value 0 or 1.
Any other integer value is invalid. Note that -0 is always equivalent to 0 in CSS,
and so is also accepted as a valid <mq-boolean> value.

Note: The <mq-boolean> type exists only for legacy purposes.
If this feature were being designed today,
it would instead use proper named keywords for its values.

The update media feature is used to query the ability of the output device
to modify the apearance of content once it has been rendered.
It accepts the following values:

none

Once it has been rendered, the layout can no longer be updated.
Example: documents printed on paper.

slow

The layout may change dynamically according to the usual rules of CSS,
but the output device is not able to render or display changes quickly enough
for them to be percieved as a smooth animation.
Example: E-ink screens or severely under-powered devices.

fast

The layout may change dynamically according to the usual rules of CSS,
and the output device is not unusually constrained in speed,
so regularly-updating things like CSS Animations can be used.
Example: computer screens.

For example, if a page styles its links to only add underlines on hover,
it may want to always display underlines when printed:

The overflow-block media feature describes the behavior of the device
when content overflows the initial containing block in the block axis.

none

There is no affordance for overflow in the block axis;
any overflowing content is simply not displayed.
Examples: billboards

scroll

Overflowing content in the block axis is exposed by allowing users to scroll to it.
Examples: computer screens

optional-paged

Overflowing content in the block axis is exposed by allowing users to scroll to it,
but page breaks can be manually triggered
(such as via break-inside/etc)
to cause the following content to display on the following page.
Examples: slideshows

paged

Content is broken up into discrete pages;
content that overflows one page in the block axis is displayed on the following page.
Examples: printers, ebook readers

The overflow-inline media feature describes the behavior of the device
when content overflows the initial containing block in the inline axis.

none

There is no affordance for overflow in the inline axis;
any overflowing content is simply not displayed.

scroll

Overflowing content in the inline axis is exposed by allowing users to scroll to it.

Note: There are no known implementations of paged overflow of inline-overflowing content,
and the very concept doesn’t seem to make much sense,
so there is intentionally no paged value for overflow-inline.

For example, these two media queries express that a style sheet applies to all color devices:

@media (color) { … }
@media (min-color: 1) { … }

This media query expresses that a style sheet applies to color devices
with at least 8 bits per color component:

@media (color >= 8) { … }

If different color components are represented by different number of bits,
the smallest number is used.

For instance, if an 8-bit color system
represents the red component with 3 bits, the green component with 3 bits, and the blue component with 2 bits,
the color media feature will have a value of 2.

In a device with indexed colors,
the minimum number of bits per color component in the lookup table is used.

Note: The described functionality is only able to describe color capabilities at a superficial level.
If further functionality is required,
RFC2531 [RFC2531] provides more specific media features which may be supported at a later stage.

The color-gamut media feature describes the approximate range of colors
that are supported by the UA and output device.
That is, if the UA receives content with colors in the specified space
it can cause the output device to render the appropriate color,
or something appropriately close enough.

Note: The query uses approximate ranges for a few reasons.
Firstly, there are a lot of differences in display hardware.
For example, a device might claim to support "Rec. 2020",
but actually renders a significantly lower range of the full gamut.
Secondly, there are a lot of different color ranges that different devices support,
and enumerating them all would be tedious.
In most cases the author does not need to know the exact capabilities of the display,
just whether it is better than sRGB,
or significantly better than sRGB.
That way they can serve appropriate images,
tagged with color profiles,
to the user.

srgb

The output device can support approximately the sRGB gamut [SRGB] or more.

Note: It is expected that the vast majority of color displays
will be able to return true to a query of this type.

p3

The output device can support approximately the gamut
specified by the DCI P3 Color Space or more.

For example, this media query applies when the display supports colors
in the range of DCI P3:

@media(color-gamut: p3) { … }

Note: An output device can return true for multiple values of this media feature,
if its full output gamut is large enough,
or one gamut is a subset of another supported gamut.
As a result,
this feature is best used in an "ascending" fashion—set a base value when (color-gamut: srgb) is true,
then override it if (color-gamut: p3) is true, etc.

Note: Some output devices,
such as monochrome displays,
cannot support even the srgb gamut.
To test for these devices,
you can use this feature in a negated boolean-context fashion: not (color-gamut).

Or should we add a value specifically for the "less than sRGB" case,
like narrow?
It would have to work differently than the others,
and only match if the gamut was extra-low.

7. Interaction Media Features

The “interaction” media features reflect various aspects of how the user interacts with the page.

Typical examples of devices matching combinations of pointer and hover:

The pointer and hover features relate to the characteristics of the “primary” input mechanism,
while any-pointer and any-hover can be used to query the properties of all potentially available input mechanisms.

Note: While this specification does not define how User Agents should decide what the “primary” input 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 input mechanisms available,
and a notion of which of these inputs is generally and/or currently being used.
User Agents may also decide to dynamically change what type of input is deemed to be primary,
in response to changes in the user environment
or in the way the user is interacting with the UA.

The pointer media feature is used to query the presence and accuracy of a pointing device such as a mouse.
If a device has multiple input mechanisms,
the pointer media feature must reflect the characteristics of the “primary” input mechanism,
as determined by the user agent.
(To query the capabilities of any available input mechanism,
see the any-pointer media feature.)

none

The primary input mechanism of the device does not include a pointing device.

coarse

The primary input mechanism of the device includes a pointing device of limited accuracy.
Examples include touchscreens and motion-detection sensors (like the Kinect peripheral for the Xbox.)

fine

The primary input mechanism of the device includes an accurate pointing device.
Examples include mice, touchpads, and drawing styluses.

Both coarse and fine indicate the presence of a pointing device,
but differ in accuracy.
A pointing device with which it would be difficult or impossible
to reliably pick one of several small adjacent targets at a zoom factor of 1
would qualify as coarse.
Changing the zoom level does not affect the value of this media feature.

Note: As the UA may provide the user with the ability to zoom,
or as secondary pointing devices may have a different accuracy,
the user may be able to perform accurate clicks even if the value of this media feature is coarse.
This media feature does not indicate that the user will never be able to click accurately,
only that it is inconvenient for them to do so.
Authors are expected to react to a value of coarse by designing pages that do not rely on accurate clicking to be operated.

For accessibility reasons,
even on devices whose pointing device can be described as fine,
the UA may give a value of coarse or none to this media query,
to indicate that the user has difficulties manipulating the pointing device accurately or at all.
In addition, even if the primary input mechanism has fine pointing accuracy,
there may be additional coarse input mechanisms available to the user. Authors may
wish to query the any-pointer media feature to take these other coarse potential
input mechanisms into account.

The hover media feature is used to query the user’s ability to hover over elements on the page.
If a device has multiple input mechanisms,
the hover media feature must reflect the characteristics of the “primary” input mechanism,
as determined by the user agent.
(To query the capabilities of any available input mechanism,
see the any-hover media feature.)

none

Indicates that the primary pointing system can’t hover,
or there is no pointing system.
Examples include touchscreens and screens that use a drawing stylus.

Pointing systems that can hover,
but for which doing so is inconvenient and not part of the normal way they are used,
also match this value.
For example, a touchscreen where a long press is treated as hovering
would match hover: none.

hover

Indicates that the primary pointing system can easily hover over parts of the page.
Examples include mice and devices that physically point at the screen, like the Nintendo Wii controller.

For example, on a touch screen device that can also be controlled by an optional mouse,
the hovermedia feature should match none,
as the primary interaction mode (touching the screen) can’t hover.

Authors should therefore be careful not to assume that the ':hover' pseudo class
will never match on device where 'hover:none' is true,
but they should design layouts that do not depend on hovering to be fully usable.

For accessibility reasons, even on devices that do support hovering,
the UA may give a value of hover: none to this media query,
to opt into layouts that work well without hovering.
Note that even if the primary input mechanism has 'hover: hover' capability,
there may be additional input mechanisms available to the user that do not provide hover capabilities.

The any-pointer and any-hover media features are identical to the pointer and hover media features,
but they correspond to the union of capabilities of all the pointing devices available to the user.
More than one of their values can match,
if different pointing devices have different characteristics.
They must only match none if all of the pointing devices would match none for the corresponding query,
or there are no pointing devices at all.

While pointer and hover can be used to design the main style and interaction
mode of the page to suit the primary input mechanism, any-pointer and any-hover can be used to potentially take into account all possible types of pointers
that have been detected.

Designing a page that relies on hovering or accurate pointing
only because any-hover or any-pointer indicate that at least one of the available
input mechanisms has these capabilities is likely to result in a poor experience.
However, authors may use this information to inform their decision about the style and
functionality they wish to provide based on additional input mechanisms that
are available to the user.

A number of smart TVs come with a way to control an on-screen cursor,
but it is often fairly basic controller which is difficult to operate accurately.

A browser in such a smart TV would have coarse as the value of both pointer and any-pointer,
allowing authors to provide a layout with large and easy to reach click targets.

The user may also have paired a Bluetooth mouse with the TV,
and occasionally use it for extra convenience,
but such the mouse is not the main way the TV is operated. pointer still matches coarse, while any-pointer now both matches coarse and fine.

Switching to small click targets based on the fact that (any-pointer: fine) is now true
would not be appropriate.
It would not only surprise the user
by providing an experience out of line with what they expect on a TV,
but may also be quite inconvenient:
the mouse, not being the primary way to control the TV, may be out of reach,
hidden under one of the cushions on the sofa...

By contrast, consider scrolling on the same TV.
Scrollbars are difficult to manipulate without an accurate pointing device.
Having prepared an alternative way to indicate that there is more content to be seen
based on (pointer: coarse) being true,
an author may want to still show the scrollbars in addition if (any-pointer: fine) is true,
or to hide them altogether to reduce visual clutter if (any-pointer: fine) is false.

8. Scripting Media Features

The scripting media feature is used to query whether scripting languages,
such as JavaScript,
are supported on the current document.

enabled

Indicates that the user agent supports scripting of the page
and that support is active for the current document.

initial-only

Indicates that scripting is enabled during the initial page load,
but is not supported afterwards.
Examples are printed pages,
or pre-rendering network proxies
that render a page on a server
and send a nearly-static version of the page to the user.

Should there be an explicit minimum threshold to meet
before a UA is allowed to claim initial-only?
Having one would mean authors would know
what they can depend on,
and could tailor their scripts accordingly.
On the other hand, pinpointing that threshold is difficult:
if it is set too low,
the scripting facilities that authors can depend on
may be to constrained to be practical,
even though actual UAs may potentially
all support significantly more.
But trying to set it higher may cause us to exclude
UAs that do support scripting at loading time,
but restrict it in some cases based on complex heuristics.
For instance, conservative definitions likely include at least
running all inline scripts and firing the DOMContentLoaded event.
But it does not seem useful for authors to constrain themselves to this
if most (or maybe all) initial-only UAs
also load external scripts (including async and defer)
and fire the load event.
On the other hand,
requiring external scripts to be loaded
and the load event to be fired
could exclude UAs like Opera mini,
which typically do run them,
but may decide not to based on timeouts and other heuristics.

none

Indicates that the user agent will not run scripts for this document;
either it doesn’t support a scripting language,
or the support isn’t active for the current document.

Some user agents have the ability to turn off scripting support on a per script basis or per domain basis,
allowing some, but not all, scripts to run in a particular document.
The scripting media feature does not allow fine grained detection of which script is allowed to run.
In this scenario, the value of the scripting media feature should be enabled if scripts originating on the same domain as the document are allowed to run,
and none otherwise.

Note: A future level of CSS may extend this media feature to allow fine-grained detection of which script is allowed to run.

9. Appendix A: Deprecated Media Features

The following media features are deprecated. They
kept for backward compatibility, but are not appropriate for newly
written style sheets. Authors must not use them. User agents must support them
as specified.

To query for the size of the viewport (or the page box
on page media), the width, height and aspect-ratiomedia features should be used, rather than device-width, device-height and device-aspect-ratio, which refer to the physical size of the the device
regardless of how much space is available for the document being laid out. The
device-* media features are also sometimes used as a proxy to detect
mobile devices. Instead, authors should use media features that better
represent the aspect of the device that they are attempting to style against.

device-width

The device-width media feature describes the width of the rendering surface of the output device.
For continuous media, this is the width of the Web-exposed screen area.
For paged media, this is the width of the page sheet size.

device-height

The device-height media feature describes the height of the rendering surface of the output device.
For continuous media, this is the height of the Web-exposed screen area.
For paged media, this is the height of the page sheet size.

10. Privacy and Security Considerations

This specification introduces no new security considerations.

Media Queries enable CSS to query various aspects of the page’s environment,
including things that can be difficult or impossible to find via scripting.
This is potentially a privacy hazard,
allowing enhanced fingerprinting of a user,
but the risk is generally low.
At minimum, the same information should be inferrable via scripting by examining the User Agent string.
However, UA string spoofing does not affect Media Queries,
making this a somewhat more robust detection technique.

That said, the information granted by Media Queries is relatively coarse,
and does not contribute much entropy in this regard.

A few legacy Media Features (device-width, device-height, and device-aspect-ratio)
expose information about the environment in which the UA is running
without any clear benefit to doing so.
They are retained for compatibility reasons,
but for the sake of privacy and security,
UAs have been allowed to report inacurate information.

Conformance

Document conventions

Conformance requirements are expressed with a combination of
descriptive assertions and RFC 2119 terminology. The key words “MUST”,
“MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
document are to be interpreted as described in RFC 2119.
However, for readability, these words do not appear in all uppercase
letters in this specification.

All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example”
or are set apart from the normative text with class="example",
like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the
normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are
set apart from other normative text with <strong class="advisement">, like
this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification
is defined for three conformance classes:

A style sheet is conformant to this specification
if all of its statements that use syntax defined in this module are valid
according to the generic CSS grammar and the individual grammars of each
feature defined in this module.

A renderer is conformant to this specification
if, in addition to interpreting the style sheet as defined by the
appropriate specifications, it supports all the features defined
by this specification by parsing them correctly
and rendering the document accordingly. However, the inability of a
UA to correctly render a document due to limitations of the device
does not make the UA non-conformant. (For example, a UA is not
required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification
if it writes style sheets that are syntactically correct according to the
generic CSS grammar and the individual grammars of each feature in
this module, and meet all other conformance requirements of style sheets
as described in this module.

Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements
for implementing CSS responsibly,
in a way that promotes interoperability in the present and future.

Partial Implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid
(and ignore as appropriate)
any at-rules, properties, property values, keywords, and other syntactic constructs
for which they have no usable level of support.
In particular, user agents must not selectively ignore
unsupported property values and honor supported values in a single multi-value property declaration:
if any value is considered invalid (as unsupported values must be),
CSS requires that the entire declaration be ignored.

Implementations of Unstable and Proprietary Features

Implementations of CR-level Features

Once a specification reaches the Candidate Recommendation stage,
implementers should release an unprefixed implementation
of any CR-level feature they can demonstrate
to be correctly implemented according to spec,
and should avoid exposing a prefixed variant of that feature.

To establish and maintain the interoperability of CSS across
implementations, the CSS Working Group requests that non-experimental
CSS renderers submit an implementation report (and, if necessary, the
testcases used for that implementation report) to the W3C before
releasing an unprefixed implementation of any CSS features. Testcases
submitted to W3C are subject to review and correction by the CSS
Working Group.

Issues Index

Or should we add a value specifically for the "less than sRGB" case,
like narrow?
It would have to work differently than the others,
and only match if the gamut was extra-low. ↵

Should there be an explicit minimum threshold to meet
before a UA is allowed to claim initial-only?
Having one would mean authors would know
what they can depend on,
and could tailor their scripts accordingly.
On the other hand, pinpointing that threshold is difficult:
if it is set too low,
the scripting facilities that authors can depend on
may be to constrained to be practical,
even though actual UAs may potentially
all support significantly more.
But trying to set it higher may cause us to exclude
UAs that do support scripting at loading time,
but restrict it in some cases based on complex heuristics.
For instance, conservative definitions likely include at least
running all inline scripts and firing the DOMContentLoaded event.
But it does not seem useful for authors to constrain themselves to this
if most (or maybe all) initial-only UAs
also load external scripts (including async and defer)
and fire the load event.
On the other hand,
requiring external scripts to be loaded
and the load event to be fired
could exclude UAs like Opera mini,
which typically do run them,
but may decide not to based on timeouts and other heuristics. ↵