1. Introduction
Note: At the time of writing, [MEDIAQUERIES-4] is not completely finalized yet. To avoid accidental divergences and maintenance overhead, This specification is written as a delta specification over Media Queries Level 4. Once the level 4 specification is final, its content will be integrated into this specification, which will then replace it. Until then, Media Queries Level 5 only contains additions and extensions to level 4.
1.1. Media Features
1.1.1. Evaluating Media Features in a Boolean Context
Copy level 4 prose when final, except the following paragraph which is changed compared to level 4.
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, the keyword none, or a value explicitely defined by that media feature to evaluate as false in a boolean context, the media feature evaluates to true. Otherwise, it evaluates to false.
2. Environment Media Features
2.1. Detecting the ambient light level: the light-level feature
| Name: | light-level |
|---|---|
| For: | @media |
| Value: | dim | normal | washed |
| Type: | discrete |
The light-level media feature is used to query about the ambient light-level in which the device is used, to allow the author to adjust style of the document in response. The following values are valid:
- dim
- The device is used in a dim environment, where excessive contrast and brightness would be distracting or uncomfortable to the reader. For example: night time, or a dimly illuminated indoor environment.
- normal
- The device is used in a environment with a light level in the ideal range for the screen, and which does not necessitate any particular adjustment.
- washed
- The device is used in an exceptionally bright environment, causing the screen to be washed out and difficult to read. For example: bright daylight.
User agents should set the thresholds between the three levels in a way that takes into account the characteristics of the device.
- Devices equipped with a light sensor usually adjust the brightness of the screen automatically. Depending on the level of adjustment, the thresholds for needing a low contrast or hight contrast content may vary.
- Different screen technologies wash out at very different ambient light levels; e-ink displays remain readable in bright daylight, while liquid crystal displays do not.
- Many embedded light sensors are inaccurately calibrated, making it difficult to establish useful thresholds valid across devices.
For accessibility purposes, user agents may offer manual controls allowing the user to switch between the three levels of independently of the ambient light level, as high contrast or low contrast styles may be more suitable for users with visual disabilities.
Using this media feature for accessibility purposes overlaps a lot with the high-contrast media feature proposed by Microsoft. Can we adjust this so that it covers all use cases for both, or somehow modify them to work in an orthogonal, rather than overlapping, fashion?
@media (light-level: normal) {
p { background: url("texture.jpg"); color: #333 }
}
@media (light-level: dim) {
p { background: #222; color: #ccc }
}
@media (light-level: washed) {
p { background: white; color: black; font-size: 2em; }
}
3. Scripting Media Features
3.1. Scripting Support: the scripting feature
| Name: | scripting |
|---|---|
| For: | @media |
| Value: | none | initial-only | enabled |
| Type: | discrete |
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 scripting in the current document is enabled for the lifetime of the document.
- initial-only
-
Indicates that the user agent supports scripting of the page,
and that scripting in the current document 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. <https://github.com/w3c/csswg-drafts/issues/503>
- 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 or initial-only 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.
4. Custom Media Queries
When designing documents that use media queries, the same media query may be used in multiple places, such as to qualify multiple @import statements. Repeating the same media query multiple times is an editing hazard; an author making a change must edit every copy in the same way, or suffer from difficult-to-find bugs in their CSS.
To help ameliorate this, this specification defines a method of defining custom media queries, which are simply-named aliases for longer and more complex media queries. In this way, a media query used in multiple places can instead be assigned to a custom media query, which can be used everywhere, and editing the media query requires touching only one line of code.
A custom media query is defined with the @custom-media rule:
@custom-media = @custom-media <extension-name> [ <media-query-list> | true | false ] ;
The <extension-name> can then be used in a media feature. It must be used in a boolean context; using them in a normal or range context is a syntax error. If a <media-query-list> is given, the custom media query evaluates to true if the <media-query-list> it represents evaluates to true, and false otherwise. If true or false is given, the custom media query evaluates to true or false, respectively.
A @custom-media rule can refer to other custom media queries. However, loops are forbidden, and a custom media query must not be defined in terms of itself or of another custom media query that directly or indirectly refers to it. Any such attempt of defining a custom media query with a circular dependency must cause all the custom media queries in the loop to fail to be defined.
If multiple @custom-media rules declare the same <extension-name>, the truth value is based on the last one alone, ignoring all previous declarations of the same <extension-name>.
Note: For error handling purposes, an undefined media feature is different from a media feature that evaluates to false. See Media Queries 4 §3.2 Error Handling for details.
@custom-media --narrow-window (max-width: 30em);
@media (--narrow-window) {
/* narrow window styles */
}
@media (--narrow-window) and (script) {
/* special styles for when script is allowed */
}
/* etc */
4.1. Script-based Custom Media Queries
<script>
CSS.customMedia.set('--foo', 5);
</script>
<style>
@media (_foo: 5) { ... }
@media (_foo < 10) { ... }
</style>
5. User Preference Media Features
5.1. Detecting the desire for inverted colors on the display: the inverted-colors feature
| Name: | inverted-colors |
|---|---|
| For: | @media |
| Value: | none | inverted |
| Type: | discrete |
The inverted-colors media feature indicates whether the content is displayed normally, or whether colors have been inverted.
Note: This is an indication that the user agent or underlying operating system has forcibly inverted all colors, not a request to do so. This is sometimes provided as a simple accessibility feature, allowing users to switch between light-on-dark and dark-on-light text. However, this has unpleasant side effects, such as inverting pictures, or turning shadows into highlights, which reduce the readability of the content.
- none
- Colors are displayed normally.
- inverted
- All pixels within the displayed area have been inverted.
@media (inverted-colors) {
img { filter: invert(100%); }
* { text-shadow: none !important; box-shadow: none !important; }
}
5.2. Detecting the desire for less motion on the page: the prefers-reduced-motion feature
| Name: | prefers-reduced-motion |
|---|---|
| For: | @media |
| Value: | no-preference | reduce |
| Type: | discrete |
The prefers-reduced-motion media feature is used to detect if the user has requested the system minimize the amount of animation or motion it uses.
- no-preference
- Indicates that the user has made no preference known to the system. This keyword value evaluates as false in the boolean context.
- reduce
- Indicates that user has notified the system that they prefer an interface that minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed.
5.3. Detecting the desire for reduced transparency on the page: the prefers-reduced-transparency feature
| Name: | prefers-reduced-transparency |
|---|---|
| For: | @media |
| Value: | no-preference | reduce |
| Type: | discrete |
The prefers-reduced-transparency media feature is used to detect if the user has requested the system minimize the amount of transparent or translucent layer effects it uses.
- no-preference
- Indicates that the user has made no preference known to the system. This keyword value evaluates as false in the boolean context.
- reduce
- Indicates that user has notified the system that they prefer an interface that minimizes the amount of transparent or translucent layer effects.
Changes
Changes Since the Media Queries Level 4
The following changes were made to this specification since the 6 July 20126 Working Draft of Media Queries Level 4:
- Reinstate light-level, inverted-colors and Custom Media Queries sections from the Media Queries Level 4 drafts.
- Add prefers-reduced-motion media feature.
- Add prefers-reduced-transparency media feature.
Acknowledgments
This specification is the product of the W3C Working Group on Cascading Style Sheets.
Comments from James Craig improved this specification.