spec:css2; type:dfn; text:canvas

spec:css-color-4; type:property; text:color

spec:fill-stroke-3; type:property;

text:fill

text:stroke

url: https://html.spec.whatwg.org/multipage/semantics.html#meta-color-scheme;

type: attr-value; for: meta/name; spec: html; text: color-scheme;

Introduction {#intro}

=====================

This specification introduces three new features

related to controlling how/when colors are auto-adjusted

by the user agent:

* [=Color schemes=]

and the 'color-scheme' property,

which controls whether or not browser-provided parts of the page's UI

respect the user's chosen [=color scheme=].

* [=Forced colors mode=]

and the 'forced-color-adjust' property,

which controls whether or not [=forced colors mode=] is allowed to apply to a given element.

* The 'print-color-adjust' property,

which controls whether the browser is allowed

to automatically adjust colors to the user's assumed performance preferences,

such as suppressing background colors when printing to save ink.

Together with the 'prefers-color-scheme', 'prefers-contrast', and 'forced-colors' [=media queries=] [[!MEDIAQUERIES-5]],

this module allows color scheme negotiation

between the author and the user.

Value Definitions {#values}

---------------------------

This specification follows the <a href="https://www.w3.org/TR/CSS2/about.html#property-defs">CSS property definition conventions</a> from [[!CSS2]]

using the <a href="https://www.w3.org/TR/css-values-3/#value-defs">value definition syntax</a> from [[!CSS-VALUES-3]].

Value types not defined in this specification are defined in CSS Values &amp; Units [[!CSS-VALUES-3]].

Combination with other CSS modules may expand the definitions of these value types.

In addition to the property-specific values listed in their definitions,

all properties defined in this specification

also accept the <a>CSS-wide keywords</a> as their property value.

For readability they have not been repeated explicitly.

<!--

██████ ███████ ██ ███████ ████████ ██████ ██████ ██ ██ ████████ ██ ██ ████████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ███ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ████ ██

██ ██ ██ ██ ██ ██ ████████ ███████ ██████ ██ █████████ ██████ ██ ███ ██ ██████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██████ ███████ ████████ ███████ ██ ██ ██████ ██████ ██ ██ ████████ ██ ██ ████████

-->

Preferred Color Schemes {#preferred}

=======================

Operating systems and user agents often give users

the ability to choose their <dfn export>preferred color scheme</dfn>

for user interface elements.

This <dfn export>color scheme</dfn> is typically reflected in the user agent's rendering

of its navigation interface as well as in-page interface elements

such as form controls and scrollbars.

A UA can also allow the user to indicate a preference

for the [=color scheme=] of the pages they view,

requesting that the author adapt the page to those color preferences.

(It is not required to express such a preference;

users can have preferences for operating system interface colors

that they do not want imposed on pages.)

The most common [=color scheme=] preferences are:

* A <dfn export local-lt=light>light color scheme</dfn> ("day mode")

consists of light background colors and dark foreground/text colors.

* A <dfn export local-lt=dark>dark color scheme</dfn> ("night mode")

consists of the opposite,

with dark background colors and light foreground/text colors.

Advisement: <strong>The [=light=] and [=dark color schemes=]

don't represent an exact color palette (such as black-and-white),

but a range of possible palettes.

To guarantee specific colors, authors must specify those colors themselves.</strong>

Note also that, consequently,

pairing default or <<system-color>> colors with author-specified colors

cannot guarantee any particular contrast level;

it might be necessary to set both foreground and background colors together

to ensure legibility [[WCAG21]].

To enable pages to adapt to the user's [=preferred color scheme=],

user agents will match the '@media/prefers-color-scheme' media query

to the user's [=preferred color scheme=].

[[!MEDIAQUERIES-5]]

Complementing this, the 'color-scheme' property defined here

lets the author indicate appropriate [=color schemes=]

for UA-provided UI and colors in the page.

User agents <em>may</em> support additional [=color schemes=],

however CSS does not support negotiation of additional [=color schemes=]:

user agents should pursue standardization of these schemes,

so that '@media/prefers-color-scheme' and 'color-scheme' can reflect the additional values.

Opting Into a Preferred Color Scheme: the 'color-scheme' property {#color-scheme-prop}

-----------------------------------------------------------------

<pre class=propdef>

<wpt>

parsing/color-scheme-computed.html

parsing/color-scheme-invalid.html

parsing/color-scheme-valid.html

rendering/dark-color-scheme/color-scheme-change-checkbox.html

rendering/dark-color-scheme/color-scheme-color-property.html

rendering/dark-color-scheme/color-scheme-iframe-background-mismatch-alpha.html

rendering/dark-color-scheme/color-scheme-iframe-background-mismatch-opaque-cross-origin.sub.html

rendering/dark-color-scheme/color-scheme-iframe-background-mismatch-opaque.html

rendering/dark-color-scheme/color-scheme-iframe-background-mismatch-used-preferred.html

rendering/dark-color-scheme/color-scheme-iframe-background.html

rendering/dark-color-scheme/color-scheme-iframe-dynamic.html

rendering/dark-color-scheme/color-scheme-iframe-preferred-change.html

rendering/dark-color-scheme/color-scheme-iframe-preferred-page-dark.html

rendering/dark-color-scheme/color-scheme-iframe-preferred-page-light.html

rendering/dark-color-scheme/color-scheme-iframe-preferred.html

rendering/dark-color-scheme/color-scheme-link-crash.html

rendering/dark-color-scheme/color-scheme-root-background.html

rendering/dark-color-scheme/color-scheme-rule-cache.html

rendering/dark-color-scheme/color-scheme-system-colors.html

rendering/dark-color-scheme/color-scheme-table-border-currentcolor-responsive.html

rendering/dark-color-scheme/color-scheme-visited-link-initial.html

</wpt>

While the 'prefers-color-scheme' media feature

allows an author to adapt the page’s colors to the user’s preferred color scheme,

many parts of the page are not under the author's control

(such as form controls, scrollbars, etc).

The 'color-scheme' property allows an element to indicate

which [=color schemes=] it is designed to be rendered with.

These values are negotiated with the user's preferences,

resulting in a <dfn export>used color scheme</dfn>

that affects things such as

the default colors of form controls and scrollbars.

(See [[#color-scheme-effect]].)

Note: Because many pages were authored before color scheme support existed,

user agents cannot automatically adapt the colors used in elements under their control,

as it might cause unreadable color contrast with the surrounding page.

Host languages can define the <dfn export>page's supported color schemes</dfn>,

a list of [=color schemes=] supported by default for all elements on that page.

Note: [[HTML]] specifies a

<a id="color-scheme-meta" href="https://html.spec.whatwg.org/multipage/semantics.html#meta-color-scheme">color-scheme</a>

<{meta}> tag which can be used to set the [=page's supported color schemes=].

Values are defined as follows:

<dl dfn-type=value dfn-for=color-scheme>

: <dfn>normal</dfn>

::

Indicates that the element supports the [=page's supported color schemes=],

if they are set, or that it supports no [=color schemes=] at all otherwise.

: <dfn>light</dfn>

::

Indicates that the element supports a [=light color scheme=].

: <dfn>dark</dfn>

::

Indicates that the element supports a [=dark color scheme=].

: <dfn>only</dfn>

::

Forbids the user agent from [=overriding the color scheme=] for the element.

: <dfn><<custom-ident>></dfn>

::

<<custom-ident>> values are meaningless,

and exist only for future compatibility,

so that future added color schemes do not invalidate the 'color-scheme' declaration

in legacy user agents.

User agents <em>must not</em> interpret any <<custom-ident>> values as having a meaning;

any additional recognized color schemes

must be explicitly added to this property’s grammar.

Note: To avoid confusion,

authoring tutorials and references

should omit <<custom-ident>> from their materials.

The ''color-scheme/normal'', ''light'', ''dark'', and ''only'' keywords

are not valid <<custom-ident>>s in this property.

</dl>

Note: [=Light=] and [=dark=] [=color schemes=]

are not specific color palettes.

For example,

a stark black-on-white scheme and a sepia dark-on-tan scheme

would both be considered [=light color schemes=].

To ensure particular foreground or background colors,

they need to be specified explicitly.

<div algorithm>

To <dfn noexport>determine the used color scheme</dfn> of an element:

1. If the user's [=preferred color scheme=],

as indicated by the 'prefers-color-scheme' media feature,

is present among the listed [=color schemes=],

and is supported by the user agent,

that's the element's [=used color scheme=].

2. Otherwise,

if the user has indicated an overriding preference for their chosen color scheme,

and the ''only'' keyword is not present in 'color-scheme' for the element,

the user agent must [=override the color scheme=]

with the user's [=preferred color scheme=].

See [[#color-scheme-override]].

3. Otherwise,

if the user agent supports at least one of the listed [=color schemes=],

the [=used color scheme=] is

the first supported [=color scheme=] in the list.

4. Otherwise,

the [=used color scheme=] is the browser default.

(Same as ''color-scheme/normal''.)

</div>

Note: User agents are <strong>not required</strong>

to support any particular [=color scheme=],

so only using a single keyword,

such as ''color-scheme: dark'',

to indicate a required [=color scheme=]

is still not guaranteed to have any effect on the rendering of the element.

<div class=example>

A page that responds to user preferences for light or dark display

by using the 'prefers-color-scheme' media feature

to alter the colors it uses

can easily opt the browser-controlled UI

(scrollbars, inputs, etc)

to match

with a simple global declaration:

<pre highlight=css>

:root {

color-scheme: light dark;

}

</pre>

If a page limits itself to using <em>only</em> the <<system-color>>s,

the 'color-scheme' declaration, above,

will support the user's preferred color scheme

even without the author needing to use ''@media'' at all.

</div>

<div class=example>

If a page cannot reasonably accommodate all color schemes,

such as for branding or theatrical reasons,

'color-scheme' can still indicate which color schemes the page <em>can</em> support,

causing the UI to match.

If the page's color scheme is primarily light,

the following will indicate that explicitly:

<pre highlight=css>

:root {

color-scheme: light;

}

</pre>

While if the page is primarily dark,

indicating that explicitly will make the page look more coherent as well:

<pre highlight=css>

:root {

color-scheme: dark;

}

</pre>

However, it is better to support both color schemes,

of course.

</div>

<div class=example>

A page might be generally capable of handling multiple color schemes,

while still having a sub-section that needs to be rendered in a particular color scheme.

For example,

a style guide might give several UI examples that are using light or dark colors,

showing off the light or dark theme specifically.

This can be indicated as:

<pre highlight=css>

:root {

color-scheme: light dark;

}

.light-theme-example {

color-scheme: light;

}

.dark-theme-example {

color-scheme: dark;

}

</pre>

Only the subsections rooted at ''.light-theme-example'' or ''.dark-theme-example''

will be opted into the ''light'' or ''dark'' themes specifically;

the rest of the page will respect the user's preference.

</div>

Note: Repeating a keyword, such as ''color-scheme: light light'',

is valid but has no additional effect

beyond what the first instance of the keyword provides.

Effects of the Used Color Scheme {#color-scheme-effect}

--------------------------------

For all elements,

the user agent must match the following to the [=used color scheme=]:

* the default colors of scrollbars and other interaction UI

* the default colors of form controls and other "specially-rendered" elements

* the default colors of other browser-provided UI, such as "spellcheck" underlines

On the root element,

the [=used color scheme=] additionally must affect

the surface color of the [=canvas=],

and the viewport's scrollbars.

In order to preserve expected color contrasts,

in the case of embedded documents typically rendered over a transparent [=canvas=]

(such as provided via an HTML <{iframe}> element),

if the [=used color scheme=] of the element

and the [=used color scheme=] of the embedded document’s root element

do not match,

then the UA must use an opaque [=canvas=] of the ''Canvas'' color

appropriate to the embedded document’s [=used color scheme=]

instead of a transparent canvas.

This rule does not apply to documents embedded

via elements intended for graphics

(such as <{img}> elements embedding an SVG document).

Note: Aside from the small list of adjustments given above,

user agents generally do not further adjust a page

to match the user's preferred [=color scheme=],

because the chance of accidentally ruining a page is too high.

However, when particular color choices are required by the user

(for accessibility reasons, for example),

more invasive changes might be applied;

see [[#forced]].

Overriding the Color Scheme {#color-scheme-override}

---------------------------

If the user has indicated an <em>overriding</em> preference for a particular color scheme,

and the author has not disallowed this (by using the ''only'' keyword),

the user agent may <dfn>override the color scheme</dfn>,

forcing the [=used color scheme=] to the user's [=preferred color scheme=].

If the element does not support that [=color scheme=],

the user agent must also auto-adjust other colors into this chosen [=color scheme=],

such as by inverting their brightness,

while preserving any color contrast necessary for readability of the page.

In this case, UA may also auto-adjust colors within replaced elements, background images, and other external resources as appropriate.

Note: The specifics of such auto-adjustments are UA-defined,

and can differ from UA to UA.

But it is not intended to force all colors into a fixed palette,

as [=forced colors mode=] does,

only to force all colors on the page

to conform to either a [=dark=] or [=light=] color scheme.

For example, a UA might have a “dark room” mode,

which forces all pages into a [=dark=] color scheme.

For pages that already support [=dark=] color schemes,

and have indicated so using the 'color-scheme' property

or <{meta/name/color-scheme}> <{meta}> name,

this has no effect other than reporting a ''@media/prefers-color-scheme/dark'' value

for the 'prefers-color-scheme' [=media query=]

and selecting a [=dark=] [=used color scheme=].

But for pages that do not explicitly support a [=dark=] color scheme,

and have not explicitly forbidden this auto-adjustment

by specifying ''color-scheme: only light'',

this mode triggers auto-adjustment of the page’s colors

to <em>force</em> the page to conform to the desired [=dark=] color scheme.

<!--

████████ ███████ ████████ ██████ ████████ ████████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██

██████ ██ ██ ████████ ██ ██████ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ███████ ██ ██ ██████ ████████ ████████

-->

Forced Color Palettes {#forced}

=====================

<dfn export>Forced colors mode</dfn> is an accessibility feature

intended to increase the readability of text through color contrast.

Individuals with limited vision

often find it more comfortable to read content

when there is a particular type of contrast

between foreground and background colors.

Operating systems can provide built-in color themes,

such as Windows’ high contrast black-on-white

and high-contrast white-on-black themes.

Users can also customize their own themes,

for example to provide low contrast or hue contrast.

In <a>forced colors mode</a>,

the user agent enforces the user’s preferred color palette on the page,

overriding the author’s chosen colors for specific properties,

see [[#forced-colors-properties]].

It may also enforce a “backplate” underneath text

(similar to the way backgrounds are painted on the ''::selection'' pseudo-element)

to ensure adequate contrast for readability.

To enable pages to adapt to <a>forced colors mode</a>

user agents will match the '@media/forced-colors' media query

<!-- (see [[MEDIAQUERIES-5]]) -->

and must provide the required color palette

through the CSS system colors

(see [[CSS-COLOR-4]]).

Additionally,

if the UA determines, based on Lab lightness,

that the ''Canvas'' color

is clearly either dark (L < 33%) or light (L > 67%),

then it must match the appropriate value

of the '@media/prefers-color-scheme' media query

and express a corresponding user preference for 'color-scheme'.

This will allow pages that support light/dark color schemes

to automatically adjust to more closely match

the forced color scheme.

Behavior between the above dark vs. light thresholds

is UA-defined,

and may result in assuming either

''prefers-color-scheme/light'' or ''prefers-color-scheme/dark''

as the user’s preferred color scheme.

<!--THOUGHTS

This advice (below) maybe makes sense for (prefers-contrast),

but is it really applicable to forced-colors as well?

If so, should forced-colors be instead a 'forced' value on 'prefers-contrast',

so that a (prefers-contrast) query will catch all of these cases at once?

Authors are encouraged to simplify the contrast in their pages

when '@media/forced-colors' is ''active'',

reducing effects such as shadows, fades, blurs, filters, gradients,

and image or pattern fills

that add complexity to discerning shape outline

-->

Properties Affected by Forced Colors Mode {#forced-colors-properties}

-----------------------------------------

When <a>forced colors mode</a> is active

and 'forced-color-adjust' is ''forced-color-adjust/auto'' (see below) on an element,

colors on the element are force-adjusted to the user’s preferred color palette.

Specifically, for each of the following properties:

<ul>

<li>'color'

<li>'fill'

<li>'stroke'

<li>'text-decoration-color'

<li>'text-emphasis-color'

<li>'border-color'

<li>'outline-color'

<li>'column-rule-color'

<li>'scrollbar-color'

<li>'-webkit-tap-highlight-color'

<li>'background-color'

<li>'caret-color'

<li>'flood-color'

<li>'lighting-color'

<li>'stop-color'

</ul>

if its [=computed value=] is a color other than a [=system color=],

its [=used value=] is instead forced to a [=system color=] as follows:

* For 'background-color' in particular,

it is forced to

the color opposite the 'color' property’s [=system color=] value

in the [=system color pairings=],

using ''CanvasText'' as the opposite of ''Canvas''.

However, its alpha channel is taken from

the original 'background-color' value

so that transparent backgrounds remain transparent.

* In all other cases, the UA determines

the appropriate forced [=system color=]--

which should match the color that would result

from an empty [=author style sheet=]

whenever all of the element’s affected properties

are likewise UA-determined.

<div class="note">

UAs need to be careful about inheritance when forcing colors.

For example,

suppose the UA’s button 'color' and 'background-color'

are the opposite of its canvas 'color' and 'background-color'.

Given markup such as

<xmp highlight=html>

<button>Push <em>this</em> button</button>

</xmp>

Normally, <{em}> will inherit from <{button}>,

ensuring its readability.

However in [=forced colors mode=],

the 'color' of both <{button}> and <{em}> will need to be forced.

It's easy to see that <{button}>’s color should be forced to the button color,

but <{em}> also needs to be forced to the button color;

if it were forced to the canvas 'color' like it is everywhere else in the document,

its text will be unreadable.

</div>

Additionally:

* 'box-shadow' and 'text-shadow' compute to ''box-shadow/none''

* 'background-image' computes to ''background-image/none''

unless the original value contains a ''url()'' function

* 'color-scheme' computes to ''light dark''

* 'scrollbar-color' computed to ''scrollbar-color/auto''

* 'accent-color' computed to ''accent-color/auto''

UAs may further tweak these <a>forced colors mode</a> heuristics

to provide better user experience.

Opting Out of a Forced Color Palette: the 'forced-color-adjust' property {#forced-color-adjust-prop}

-----------------------------------------------------------------

<pre class=propdef>

The 'forced-color-adjust' property

allows authors to opt particular elements

out of <a>forced colors mode</a>,

restoring full control over the colors to CSS.

Values have the following meanings:

<dl dfn-type=value dfn-for=forced-color-adjust>

: <dfn>auto</dfn>

:: The element’s colors are automatically adjusted by the UA

in <a>forced colors mode</a>.

: <dfn>none</dfn>

:: The element’s colors are not automatically adjusted by the UA

in <a>forced colors mode</a>.

Advisement: Authors should only use this value

when they are themselves adjusting the colors

to support the user’s color and contrast needs

and need to make changes to the UA’s default adjustments

to provide a more appropriate user experience

for those elements.

: <dfn>preserve-parent-color</dfn>

:: In [=forced colors mode=],

if the 'color' property inherits from its parent

(i.e. there is no [=cascaded value=]

or the [=cascaded value=] is ''currentColor'', ''inherit'',

or another keyword that inherits from the parent),

then it computes to the [=used value|used=] color of its parent’s 'color' value.

In all other respects, behaves the same as ''none''.

Note: This value is intended solely to get a reasonable behavior

from embedded SVG elements that expect to receive the outer document's text color

(and stay consistent with adjustments from [=forced colors mode=]),

while otherwise defaulting SVGs

to preserving their exact colors,

as [=forced colors mode=] can't generally be usefully applied to illustrations.

</dl>

In order to not break SVG content,

UAs are expected to add the following rules to their UA style sheet:

<pre highlight=css>

@namespace "http://www.w3.org/2000/svg";

svg|svg { forced-color-adjust: preserve-parent-color; }

svg|foreignObject { forced-color-adjust: auto; }

</pre>

UAs must propagate the 'forced-color-adjust' value set on the root element

to the document viewport

(where it can affect e.g. the canvas background).

Note that 'forced-color-adjust' is <em>not</em> propagated from HTML <{body}>.

/css/css-forced-color-adjust/inheritance.html

/css/css-forced-color-adjust/parsing/forced-color-adjust-computed.html

/css/css-forced-color-adjust/parsing/forced-color-adjust-invalid.html

/css/css-forced-color-adjust/parsing/forced-color-adjust-valid.html

<!--

██████ ███████ ██ ███████ ████████ ███ ████████ ██ ██ ██ ██████ ████████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ████████ ███████ ██ ██ ██ ██ ██ ██ ██ ██████ ██

██ ██ ██ ██ ██ ██ ██ ██ █████████ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██████ ███████ ████████ ███████ ██ ██ ██ ██ ████████ ██████ ███████ ██████ ██

-->

Performance-based Color Adjustments {#perf}

===================================

On most monitors,

the color choices that authors make have no significant difference

in terms of how the device performs;

displaying a document with a white background or a black background is approximately equally easy.

However, some devices have limitations and other qualities that make this assumption untrue.

For example,

printers tend to print on white paper;

a document with a white background thus has to spend no ink on drawing that background,

while a document with a black background will have to expend a large amount of ink filling in the background color.

This tends to look fairly bad,

and sometimes has deleterious physical effects on the paper,

not to mention the vastly increased printing cost from expending the extra ink.

Even fairly small differences,

such as coloring text black versus dark gray,

can be quite different when printing,

as it switches from using a single black ink

to a mixture of cyan, magenta, and yellow ink,

resulting in higher ink usage and lower resolution.

As a result, in some circumstances user agents will alter the styles an author specifies in some particular context,

adjusting them to be more appropriate for the output device

and to accommodate what they assume the user would prefer.

However, in some cases the document may be using colors in important, well-thought-out ways that the user would appreciate,

and so the document would like some way to hint to the user agent that it might want to respect the page's color choices.

This section defines properties for controlling these automatic adjustments.

Ink Economy: the 'print-color-adjust' property {#print-color-adjust}

----------------------------------------------

<pre class='propdef'>

<wpt>

parsing/print-color-adjust.html

</wpt>

The 'print-color-adjust' property provides a hint to the user-agent

about how it should treat color and style choices

that might be expensive or generally unwise on a printer or similar device,

such as using light text on a dark background.

If user agents allow users to control this aspect of the document's display,

the user preference <strong>must</strong> be respected more strongly

than the hint provided by 'print-color-adjust'.

It has the following values:

<dl dfn-type=value dfn-for=print-color-adjust>

<dt><dfn>economy</dfn>

<dd>

The user agent should make adjustments to the page's styling

as it deems necessary and prudent for the output device.

For example, if the document is being printed,

a user agent might ignore any backgrounds

and adjust text color to be sufficiently dark,

to minimize ink usage.

<dt><dfn>exact</dfn>

<dd>

This value indicates that the page is using color and styling on the specified element

in a way which is important and significant,

and which should not be tweaked or changed except at the user's request.

For example,

a mapping website offering printed directions

might "zebra-stripe" the steps in the directions,

alternating between white and light gray backgrounds.

Losing this zebra-striping and having a pure-white background

would make the directions harder to read with a quick glance

when distracted in a car.

</dl>

UAs must propagate the 'print-color-adjust' value set on the root element

to the document viewport

(where it can affect e.g. the canvas background).

Note that 'print-color-adjust' is <em>not</em> propagated from HTML <{body}>.

The 'color-adjust' Shorthand {#color-adjust}

--------------------------------------------

<pre class="propdef shorthand">

The 'color-adjust' shorthand allows an author

to set all of the performance-motivated color adjustment properties

in one declaration.

(Currently, there is only one such property--

'print-color-adjust'--

but more might be added in the future.)

Advisement: The 'color-adjust' shorthand is currently <em>deprecated</em>.

Authors should use the more specific 'print-color-adjust' property,

to avoid accidentally resetting performance-based color adjustments

in other contexts than the one intended.

animation/color-scheme-no-interpolation.html

animation/forced-color-adjust-no-interpolation.html

inheritance.html

Privacy Considerations {#privacy}

===================================

Applying user color preferences via [=color schemes=] or [=forced colors mode=]

exposes the user's color preferences to the page

via {{getComputedStyle()}},

which can increase fingerprinting surface.

<div class=note>

Avoiding this comes with unfortunate drawbacks that were deemed too significant to be ignored.

Namely:

* preserving system colors as keywords until actual-value time

would break a significant amount of deployed script,

as the initial value of 'color' is a system color already

(but a huge amount of script implicitly expects to see an RGB color from 'color')

* lying about system colors from the scripting APIs

(pretending they're always some static values)

can result in any colors calculated <em>from</em> page colors in script

being unreadable when used with the <em>actual</em> system colors.

See <a href="https://github.com/w3c/csswg-drafts/issues/5710#issuecomment-840772752">Issue 5710</a>

for discussion on this topic.

</div>

Security Considerations {#security}

===================================

It may be possible for an embedded document

to use timing attacks to determine whether its own 'color-scheme'

matches that of its embedding <{iframe}> or not.

Acknowledgements {#acknowledgements}

================

This specification would not be possible

without the development efforts

of various color adjustment features

at Apple, Google, and Microsoft

as well as discussions about print adjustments on www-style.

In particular, the CSS Working Group would like to thank:

Alison Maher,

François Remy,

イアンフェッティ

ISSUE: List additional MSFT / Apple / Google people here.

Changes {#changes}

=======

Changes since the <a href="https://www.w3.org/TR/2022/CR-css-color-adjust-1-20220210/">10 February 2022 Candidate Recommendation Snapshot</a>:

<ul>

<li>Removed special handling of ''color()'' fallback system colors, since the feature was removed from [[CSS-COLOR-4]].

(<a href="https://github.com/w3c/csswg-drafts/issues/7007">Issue 7007</a>)

</ul>

<strong>See also <a href="https://www.w3.org/TR/2022/CR-css-color-adjust-1-20220210/#changes">Changes prior to Candidate Recommendation</a>.</strong>