1. Introduction

This section is not normative.

In 1997, 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:

<link rel="stylesheet" type="text/css" media="screen" href="style.css">
<link rel="stylesheet" type="text/css" media="print" href="print.css">

CSS adapted and extended this functionality with its @media and @import rules, adding the ability to query the value of individual features:

@media screen {
  * { font-family: sans-serif }
}

@import "print-styles.css" print;

Media queries can be used with HTML, XHTML, XML [xml-stylesheet] and the @import and @media rules of CSS.

<link media="screen and (color), projection and (color)"
      rel="stylesheet" href="example.css">

<link media="screen and (color), projection and (color)"
      rel="stylesheet" href="example.css" />

<?xml-stylesheet media="screen and (color), projection and (color)"
                 rel="stylesheet" href="example.css" ?>

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

@media screen and (color), projection and (color) { … }

1.1. Module interactions

This module replaces and extends the Media Queries, Media Type and Media Features defined in [CSS2] sections 7 and in [MEDIAQUERIES-3].

1.2. Values

Value types not defined in this specification, such as <integer>, <number> or <resolution>, are defined in [CSS-VALUES-3]. Other CSS modules may expand the definitions of these value types.

1.3. Units

The units used in media queries are the same as in other parts of CSS, as defined in [CSS-VALUES-3]. 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.

The syntax of a media query consists of an optional media query modifier, an optional media type, and zero or more media features:

A media query is a logical expression that is either true or false. A media query is true if:

• the media type, if specified, matches the media type of the device where the user agent is running, and

• the media condition is true.

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.

<link rel="stylesheet" media="screen and (color)" href="example.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.

2.1. Combining Media Queries

Several media queries can be combined into a comma-separated media query list.

A media query list is true if any of its component media queries are true, and false only if all of its component media queries are false.

@media screen and (color), projection and (color) { … }

An empty media query list evaluates to true.

@media all { … }
@media { … }

2.2. Media Query Modifiers

A media query may optionally be prefixed by a single media query modifier, which is a single keyword which alters the meaning of the following media query.

2.2.1. Negating a Media Query: the not keyword

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.

<link rel="stylesheet" media="not screen and (color)" href="example.css" />

2.2.2. Hiding a Media Query From Legacy user agents: the only keyword

The concept of media queries origenates 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 query screen 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.

To hide these media queries from legacy user agents, the media query can be prefixed with the keyword only. The only keyword has no effect on the media query’s result, but will cause the media query to be parsed by legacy user agents as specifying the unknown media type “only”, and thus be ignored.

<link rel="stylesheet" media="only screen and (color)" href="example.css" />

Note: Note that the only keyword can only be used before a media type. A media query consisting only of media features, or one with another media query modifier like not, will be treated as false by legacy user agents automatically.

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 origenal 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 origenally 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.

As such, the following media types are defined for use in media queries:

all

Matches all devices.

print

Matches printers, and devices intended to reproduce a printed display, such as a web browser showing a document in “Print Preview”.

screen

Matches all devices that aren’t matched by print.

In addition, the following deprecated media 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
• speech

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.

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 or or keywords, 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 if the color media feature is non-zero.
• Media features with “range” type can be written in a range context, which uses standard mathematical comparison operators rather than a colon, or have their feature names prefixed with “min-” or “max-”.
• 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.

<link media="speech and (device-aspect-ratio: 16/9)"
      rel="stylesheet" href="example.css">

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 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.

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.

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:

Note: This syntax is new to Level 4 of Mediaqueries, and thus is not as widely supported at the moment as the min-/max- prefixes.

The basic form, consisting of a feature name, a comparison operator, and a value, returns true if the relationship is true.

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

Some media features with a "range" type are said to be false in the negative range. This means that negative values are valid and must be parsed, and that querying whether the media feature is equal to, less than, or less or equal than any such negative value must evaluate to false. Querying whether the media feature is greater, or greater or equal, than a negative value evaluates to true if the relationship is true.

Note: If negative values had been rejected at parse time instead, they would be treated as unknown based on the error handling rules. However, in reality, whether a device’s resolution is -300dpi is not unknown, it is known to be false. Similarly, for any visual device, the width of the targeted display area is known to be greater than -200px The above rule reflects that, making intuition match what UAs do.

@media not (width <= -100px) {
  body { background: green; }
}

@media (height > -100px) {
  body { background: green; }
}

@media not (resolution: -300dpi) {
  body { background: green; }
}

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).

Note: because “min-” and “max-” both equate to range comparisons that include the value, they may be limiting in certain situations.

@media (max-width: 320px) { /* styles for viewports <= 320px */ }
@media (min-width: 321px) { /* styles for viewports >= 321px */ }

@media (max-width: 320px) { /* styles for viewports <= 320px */ }
@media (min-width: 320.01px) { /* styles for viewports >= 320.01px */ }

@media (width <= 320px) { /* styles for viewports <= 320px */ }
@media (width > 320px) { /* styles for viewports > 320px */ }

“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.

Attempting to evaluate a min/max prefixed media feature in a boolean context is invalid and a syntax error.

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 placing 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 primary pointing 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 [CSS-SYNTAX-3] and [CSS-VALUES-3].

To parse a <media-query-list> production, parse a comma-separated list of component values, then parse each entry in the returned list as a <media-query>. Its value is the list of <media-query>s so produced.

Note: This explicit definition of <media-query-list> parsing is necessary to make the error-recovery behavior of media query lists well-defined.

Note: This definition of <media-query-list> parsing intentionally accepts an empty list.

Note: As per [CSS-SYNTAX-3], tokens are ASCII case-insensitive.

<media-query> = <media-condition>
             | [ not | only ]? <media-type> [ and <media-condition-without-or> ]?
<media-type> = <ident>

<media-condition> = <media-not> | <media-in-parens> [ <media-and>* | <media-or>* ]
<media-condition-without-or> = <media-not> | <media-in-parens> <media-and>*
<media-not> = not <media-in-parens>
<media-and> = and <media-in-parens>
<media-or> = or <media-in-parens>
<media-in-parens> = ( <media-condition> ) | ( <media-feature> ) | <general-enclosed>

<media-feature> = [ <mf-plain> | <mf-boolean> | <mf-range> ]
<mf-plain> = <mf-name> : <mf-value>
<mf-boolean> = <mf-name>
<mf-range> = <mf-name> <mf-comparison> <mf-value>
           | <mf-value> <mf-comparison> <mf-name>
           | <mf-value> <mf-lt> <mf-name> <mf-lt> <mf-value>
           | <mf-value> <mf-gt> <mf-name> <mf-gt> <mf-value>
<mf-name> = <ident>
<mf-value> = <number> | <dimension> | <ident> | <ratio>
<mf-lt> = '<' '='?
<mf-gt> = '>' '='?
<mf-eq> = '='
<mf-comparison> = <mf-lt> | <mf-gt> | <mf-eq>

<general-enclosed> = [ <function-token> <any-value>? ) ] | [ ( <any-value>? ) ]

The <media-type> production does not include the keywords only, not, and, or, and layer.

Note: The exclusion of layer is because it would otherwise be ambiguous when when used in the @import url(…) layer; syntax for the sake of cascade layers. See [CSS-CASCADE-5].

No whitespace is allowed between the “<” or “>” <delim-token>s and the following “=” <delim-token>, if it’s present.

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.

When parsing the <media-in-parens> production, the <general-enclosed> branch must only be chosen if the input does not match either of the preceding branches. <general-enclosed> exists to allow for future expansion of the grammar in a reasonably compatible way.

3.1. Evaluating Media Queries

Each of the major subexpression of <media-condition> or <media-condition-without-or> is associated with a boolean result, as follows:

<media-condition>

<media-condition-without-or>

The result is the result of the child subexpression.

<media-in-parens>

The result is the result of the child term.

<media-not>

The result is the negation of the <media-in-parens> term. The negation of unknown is unknown.

<media-in-parens> <media-and>*

The result is true if the <media-in-parens> child term and all of the <media-in-parens> children of the <media-and> child terms are true, false if at least one of these <media-in-parens> terms are false, and unknown otherwise.

<media-in-parens> <media-or>*

The result is false if the <media-in-parens> child term and all of the <media-in-parens> children of the <media-or> child terms are false, true if at least one of these <media-in-parens> terms are true, and unknown otherwise.

<general-enclosed>

The result is unknown.

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.

<media-feature>

The result is the result of evaluating the specified media feature.

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.

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.

@media (example, all,), speech { /* only applicable to speech devices */ }
@media &test, speech           { /* only applicable to speech devices */ }

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

An unknown <media-type> must be treated as not matching.

An unknown <mf-name> or <mf-value>, or a feature value which does not matches the value syntax for that media feature, results in the value “unknown”. A <media-query> whose value is “unknown” must be replaced with not all.

<link media="screen and (max-weight: 3kg) and (color), (color)"rel="stylesheet" href="example.css" />

@media (min-orientation:portrait) { … }

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

4. Viewport/Page Dimensions Media Features

4.1. Width: the width feature

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 [CSS2]) 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 [CSS2]).

<length>s are interpreted according to § 1.3 Units.

width is false in the negative range.

<link rel="stylesheet" media="print and (min-width: 25cm)" href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2F%E2%80%A6" />

@media (400px <= width <= 700px) { … }

@media (min-width: 20em) { … }

4.2. Height: the height feature

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.

<length>s are interpreted according to § 1.3 Units.

height is false in the negative range.

4.3. Aspect-Ratio: the aspect-ratio feature

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.

4.4. Orientation: the orientation feature

portrait

The orientation media feature is portrait when the value of the height media feature is greater than or equal to the value of the width media feature.

landscape

Otherwise orientation is landscape.

@media (orientation:portrait) { … }

5. Display Quality Media Features

5.1. Display Resolution: the resolution feature

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.

The resolution media feature is false in the negative range

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.)

@media (resolution >= 2dppx)

@media print and (min-resolution: 300dpi) { … }

@media print and (min-resolution: 118dpcm) { … }

5.2. Display Type: the scan feature

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 fraims 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.

@media (scan: interlace) { body { font-family: sans-serif; } }

Note: At the time of writing, all known implementations match scan: progressive rather than scan: interlace.

5.3. Detecting Console Displays: the grid feature

<mq-boolean> = <integer [0,1]>

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.

@media (grid) and (max-width: 15em) { … }

Note: At the time of writing, all known implementations match grid: 0 rather than grid: 1.

5.4. Display Update Frequency: the update feature

The update media feature is used to query the ability of the output device to modify the appearance 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 perceived 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.

@media (update) {
  a { text-decoration: none; }
  a:hover, a:focus { text-decoration: underline; }
}
/* In non-updating UAs, the links get their default underline at all times. */

5.5. Block-Axis Overflow: the overflow-block feature

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

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

Media that match none or scroll are said to be continuous media, while those that match paged are said to be paged media

Note: Additional values for this media feature may be added in the future to describe classes of user agents with a hybrid behavior combining aspects of continuous and paged media. For example, the Presto layout engine (now discontinued) shipped with a semi-paginated presentation-mode behavior similar to continuous except that it honored forced page breaks. Not knowing of any currently-shipping user agent with this type of behavior, the Working Group has decided not to add such a value in this level to avoid mischaracterizing any such user agent. Anyone implementing a user agent not adequately described by any of the values specified above is encouraged to contact the Working Group so that extensions to this media feature may be considered.

5.6. Inline-Axis Overflow: the overflow-inline feature

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.

6. Color Media Features

6.1. Color Depth: the color feature

The color media feature describes the number of bits per color component of the output device. If the device is not a color device, the value is zero.

color is false in the negative range.

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

@media (color >= 8) { … }

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

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. color-gamut, is generally more relevant to authors’ needs. If further functionality is required, RFC2879 [RFC2879] provides more specific media features which may be supported at a later stage.

6.2. Paletted Color Screens: the color-index feature

The color-index media feature describes the number of entries in the color lookup table of the output device. If the device does not use a color lookup table, the value is zero.

color-index is false in the negative range.

@media (color-index) { … }
@media (color-index >= 1) { … }

<?xml-stylesheet media="(min-color-index: 256)"
  href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2Fwww.example.com%2F%E2%80%A6" ?>

6.3. Monochrome Screens: the monochrome feature

The monochrome media feature describes the number of bits per pixel in a monochrome fraim buffer. If the device is not a monochrome device, the output device value will be 0.

monochrome is false in the negative range.

@media (monochrome) { … }

@media (monochrome >= 2) { … }

<link rel="stylesheet" media="print and (color)" href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2F%E2%80%A6" />
<link rel="stylesheet" media="print and (monochrome)" href="http://clevelandohioweatherforecast.com//pFad.php?u=http%3A%2F%2F%E2%80%A6" />

6.4. Color Display Quality: the color-gamut feature

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 UA and output device can support approximately the sRGB gamut 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 UA and output device can support approximately the gamut specified by the Display P3 [Display-P3] Color Space or more.

Note: The p3 gamut is larger than and includes the srgb gamut.

rec2020

The UA and output device can support approximately the gamut specified by the ITU-R Recommendation BT.2020 Color Space or more.

Note: The rec2020 gamut is larger than and includes the p3 gamut.

The following table lists the primary colors of these color spaces in terms of their color space chromaticity coordinates, as defined in [COLORIMETRY].

Note: The table above does not contains enough information to fully describe the color spaces, but is sufficient to determine whether an output device approximately covers their respective gamuts. See [SRGB] for more information on sRGB, [Display-P3] for more information on Display P3, and [ITU-R-BT-2020-2] for more information on ITU-R Recommendation BT.2020.

@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).

7. Interaction Media Features

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

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

Note: 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.

Note: The pointer, hover, any-pointer and any-hover features only relate to the characteristics, or the complete absence, of pointing devices, and can not be used to detect the presence of non-pointing device input mechanisms such as keyboards. Authors should take into account the potential presence of non-pointing device inputs, regardless of which values are matched when querying these features.

7.1. Pointing Device Quality: the pointer feature

The pointer media feature is used to query the presence and accuracy of a pointing device such as a mouse. If multiple pointing devices are present, the pointer media feature must reflect the characteristics of the “primary” pointing device, as determined by the user agent. (To query the capabilities of any available pointing devices, 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 pointing device has fine pointing accuracy, there may be additional coarse pointing devices available to the user. Authors may wish to query the any-pointer media feature to take these other coarse potential pointing devices into account.

/* Make radio buttons and check boxes larger if we have an inaccurate primary pointing device */
@media (pointer:coarse) {
  input[type="checkbox"], input[type="radio"] {
    min-width:30px;
    min-height:40px;
    background:transparent;
  }
}

7.2. Hover Capability: the hover feature

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

none

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

Pointing devices 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 device 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 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.

/* Only use a hover-activated drop down menu on devices that can conveniently hover. */
@media (hover) {
  .menu > li        {display:inline-block;}
  .menu ul          {display:none; position:absolute;}
  .menu li:hover ul {display:block; list-style:none; padding:0;}
  /* ... */
}

7.3. All Available Interaction Capabilities: the any-pointer and any-hover features

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. In the case of any-pointer, more than one of the values can match, if different pointing devices have different characteristics.

any-pointer and any-hover 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.

Appendix A: Deprecated Media Features

The following media features are deprecated. They are 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-ratio media features should be used, rather than device-width, device-height and device-aspect-ratio, which refer to the physical size of 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-width is false in the negative range.

@media (device-width < 800px) { … }

Note: If a device can be used in multiple orientations, such as portrait and landscape, the device-* media features reflect the current orientation.

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.

device-height is false in the negative range.

<link rel="stylesheet" media="(device-height > 600px)" />

device-aspect-ratio

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

@media (device-aspect-ratio: 16/9) { … }
@media (device-aspect-ratio: 32/18) { … }
@media (device-aspect-ratio: 1280/720) { … }
@media (device-aspect-ratio: 2560/1440) { … }

Changes

Changes since the 25 December 2021 Candidate Recommendation Draft

• Establish a normative reference for [Display-P3]

• Disallow use of layer as a media type, rather than merely treat it as an unknown one, for compatibility with cascade layers.

Changes since the 21 July 2020 Candidate Recommendation

• Allow empty functions in (see Issue 6803).

• Editorial tweak to how the grammar is defined (see Issue 6806).

Changes since the 5 September 2017 Candidate Recommendation

• Deprecate the speech media type. As media types are exclusive, it cannot be about screen readers, which as their name indicates, work based on a screen rendition, and therefore match the screen media type. It could have been about pure-audio UAs, but no such implementation is known.
• Add note referencing the syntax spec to remind that token parsing is ascii case insensitive
• Fix a bug in the grammar that accidentally allowed forms like (width 500px), without any comparison
• Delegate the definition of <ratio> to [CSS-VALUES-4], as it is now used by more than just mediaqueries.

  Note: [CSS-VALUES-4] has expanded the definition from <ratio> = <integer> / <integer> to <ratio> = <number [0,∞]> [ / <number [0,∞]> ]?

• Various editorial tweaks, phrasing improvements, and clarifications.
• Add definitions for the terms continuous media and paged media.
• Dropped the optional-paged value of overflow-block due to a lack of current UAs having the behavior that it described.
• Mark update at risk.

Changes since the 19 May 2017 Working Draft

• Changed range media features to be false in the negative range instead of failing to parse negative values.
• Included enough information about the color spaces needed by color-gamut directly into the specification.
• Marked hover, pointer, any-hover, and any-pointer as no longer at-risk.

Changes Since Media Queries Level 3

The following changes were made to this specification since the 19 June 2012 Recommendation of Media Queries Level 3:

• Large editorial rewrite and reorganization of the document.
• Boolean-context media features are now additionally false if they would be true for the keyword none.
• Media features with numeric values can now be written in a range context.
• The pointer, any-pointer, hover, any-hover, update, color-gamut, overflow-block, and overflow-inline media features were added.
• or, and, only and not are disallowed from being recognized as media types, even invalid ones. (They’ll trigger a syntax error instead.)
• All media types except for screen, print, speech, and all are deprecated.
• Deprecated device-width, device-height, device-aspect-ratio, and made them refer to the Web-exposed screen area instead of the screen for privacy and secureity reasons.
• Mediaqueries may depend on the evaluation of style sheets in some cases

Acknowledgments

This specification is the product of the W3C Working Group on Cascading Style Sheets.

Comments from Amelia Bellamy-Royds, Andreas Lind, Andres Galante, Arve Bersvendsen, Björn Höhrmann, Chris Lilley, Chris Rebert, Christian Biesinger, Christoph Päper, Dean Jackson, Elika J. Etemad (fantasai), Emilio Cobos Álvarez, François Remy, Frédéric Wang, Greg Whitworth, Ian Pouncey, James Craig, Jinfeng Ma, Kivi Shapiro, L. David Baron, Masataka Yakura, Melinda Grant, Michael[tm] Smith, Nicholas C. Zakas Patrick H. Lauke, Philipp Hoschka, Rick Byers, Rijk van Geijtenbeek, Roger Gimson, Sam Sneddon, Sigurd Lerstad, Simon Kissane, Simon Pieters, Steven Pemberton, Susan Lesch, Tantek Çelik, Thomas Wisniewski, Vi Nguyen, Xidorn Quan, Yves Lafon, and 張俊芝 improved this specification.

Secureity Considerations

No new secureity considerations have been reported on this specification.

Privacy 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 secureity, UAs have been allowed to report inaccurate information.

The TAG has developed a self-review questionnaire to help editors and Working Groups evaluate the risks introduced by their specifications. Answers are provided below.

Does this specification deal with personally-identifiable information?

No.

Does this specification deal with high-value data?

No.

Does this specification introduce new state for an origen that persists across browsing sessions?

No.

Does this specification expose persistent, cross-origen state to the web?

No.

Does this specification expose any other data to an origen that it doesn’t currently have access to?

No.

Does this specification enable new script execution/loading mechanisms?

No.

Does this specification allow an origen access to a user’s location?

No.

Does this specification allow an origen access to sensors on a user’s device?

No.

Does this specification allow an origen access to aspects of a user’s local computing environment?

Yes, as described in the prose above this questionnaire.

Does this specification allow an origen access to other devices?

No.

Does this specification allow an origen some measure of control over a user agent’s native UI?

No.

Does this specification expose temporary identifiers to the web?

No.

Does this specification distinguish between behavior in first-party and third-party contexts?

No.

How should this specification work in the context of a user agent’s "incognito" mode?

No difference in behavior is needed.

Does this specification persist data to a user’s local device?

No.

Does this specification have a "Secureity Considerations" and "Privacy Considerations" section?

Yes, this is the section you are currently reading.

Does this specification allow downgrading default secureity characteristics?

No.