CSS Color Module Level 5

Editor’s Draft,

Specification Metadata
This version:
https://drafts.csswg.org/css-color-5/
Latest published version:
https://www.w3.org/TR/css-color-5/
Previous Versions:
Issue Tracking:
Inline In Spec
GitHub Issues
Editors:
(W3C)
Una Kravets (Google)
Lea Verou (Invited Expert)
Adam Argyle (Google)
Suggest an Edit for this Spec:
GitHub Editor
Delta Spec:
yes

Abstract

This module extends CSS Color [css-color-4] to add color modification functions.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, 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 https://www.w3.org/TR/.

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Please send feedback by filing issues in GitHub (preferred), including the spec code “css-color” in the title, like this: “[css-color] …summary of comment…”. All issues and comments are archived. Alternately, feedback can be sent to the (archived) public mailing list www-style@w3.org.

This document is governed by the 15 September 2020 W3C Process Document.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

1. Introduction

This section is not normative.

Web developers, design tools and design system developers often use color functions to assist in scaling the design of their component color relations. With the increasing usage of design systems that support multiple platforms and multiple user preferences, like the increased capability of Dark Mode in UI, this becomes even more useful to not need to manually set color, and to instead have a single source from which schemes are calculated.

LC color picker
chloropleth map of the US

Above, a color picker operating in LCH space. Here, a pair of colors are being used to define a color scale on the Chroma-Lightness plane (constant Hue). Below, the color scale in use on a chloropleth map.

Currently Sass, calc() on HSL values, or PostCSS is used to do this. However, preprocessors are unable to work on dynamically adjusted colors; all current solutions are restricted to the sRGB gamut and to the perceptual limitations of HSL (colors are bunched up in the color wheel, and two colors with visually different lightness, like yellow and blue, can have the same HSL lightness).

This module adds three functions: color-mix, color-contrast, and a way to modify colors.

The perceptually uniform ``lch()`` colorspace is used for mixing by default, as this has no gamut restrictions and colors are evenly distributed. However, other colorspaces can be specified, including ``hsl()`` or ``srgb`` if desired.

2. Colorspaces

Mixing or otherwise combining colors has different results depending on the colorspace used. In some cases, the result of physically mixing two colored lights is desired (in that case, the CIE XYZ colorspace is appropriate, because it is linear in light intensity). In other cases, colors which are evenly spaced perceptually are desired (in which case, the CIE Lab colorspace is designed to be perceptually uniform). Alternatively, maximising chroma so that color mixtures follow along the hue wheel is wanted (CIE LCH works well for this). Lastly, compatibility with legacy Web content may be the most important consideration. (the sRGB colorspace, which is neither linear-light nor perceptually uniform, is the choice here).

<colorspace> = srgb | hsl | hwb | xyz | lab | lch

When no colorspace is specified, the mixing is done in the lch colorspace. The xyz colorspace is CIE XYZ, with a D50 whitepoint, and allows computation to be done in a linear-light-intensity space.

3. Mixing colors: the color-mix() function

This function takes two <color> specifications and returns the result of mixing them, in a given colorspace, by a specified amount.

Multiple color-adjusters can be specified.

color-mix() = color-mix(<colorspace>?, <mix-component>#{2})
<mix-component> = <color> [ <percentage> | <color-adjuster>+ ]?
<color-adjuster> = [ [
      <srgb-adjuster> | <hsl-adjuster> | <hwb-adjuster>
    | <xyz-adjuster> | <lab-adjuster> | <lch-adjuster>
  ] | alpha ] <percentage>?
<srgb-adjuster> = red || green || blue
<hsl-adjuster> = <hue-adjuster> || saturation || lightness
<hwb-adjuster> = <hue-adjuster> ||  whiteness || blackness
<xyz-adjuster> = x || y || z
<lab-adjuster> = lightness || a || b
<lch-adjuster> = lightness || chroma || <hue-adjuster>
<hue-adjuster> = hue [shorter | longer | increasing | decreasing | specified ]?

Arguments are normalized as follows:

  1. When a percentage is specified without any color-adjusters, it is expanded to all adjusters available for the given colorspace plus alpha.

  2. If a percentage is omitted and there are no adjusters present on any color arguments, it defaults to 50% (an equal mix of the two colors).

  3. Adjusters that are not present on a color default to 0% (i.e. the corresponding components are taken from the other color).

  4. Adjusters that are only present on one of the colors default to 100% - p on the second color, where p is the percentage of the corresponding adjuster in the other color.

  5. If the sum of corresponding adjusters across all colors is not 100%, percentages are scaled proportionally so that the sum is exactly 100%.

Do missing adjusters default to 0% everywhere, or only in the second color? If the former, we can end up with adjusters that sum to 0% pretty easily.

The meaning of the adjusters is defined by colorspace. For example, if the colorspace is hsl, hue means the HSL hue, which is not the same as the LCH hue; if the colorspace is lch, lightness means the LCH Lightness, which is the same as Lab lightness, but different to the HSL Lightness.

Only the color-adjusters defined for a given colorspace are available. For example, it is not possible to use the HWB whiteness adjuster unless the colorspace is hwb. The alpha adjuster is available on any colorspace.

If the specified colorspace has a smaller gamut than the one in which the color to be adjusted is specified, gamut mapping will occur.

Note: not all color-adjusters are equally useful. Adjustments in LCH are the most useful, which is why it is the default. Adjustments on the a and b axes are rarely needed. Adjustments in the srgb-related spaces (srgb itself, hsl, hwb) are provided mainly for backward compatibility with the sorts of adjustments currently done in CSS preprocessors. Adjusting the individual x, y and z channels will produce significant hue shifts; however, adjusting all three channels together is useful and will lighten or darken the color.

The hue-adjuster takes optional keywords, to specify the § 6.2 Hue interpolation algorithm. If no keyword is specified, it is as if shorter were specified.

This example produces a mixture of 40% peru and 60% lightgoldenrod.
color-mix(peru  40%, lightgoldenrod)

The mixing is done in lch() colorspace. Here is a top-down view, looking along the neutral L axis:

Mixtures of peru and lightgoldenrod. Peru has a hue angle, measured from the positive a axis, of 63.677 degrees while lightgoldenrod has a hue angle of 98.821 degrees. Peru has a chroma, or distance from the central neutral axis, of 54.011 while lightgoldenrod has a chroma of 31.415. Mixtures lie along the curve. A 40%/60% mixture is shown.

The calculation is as follows:

This example produces the mixture of teal and olive, in lch colorspace (the default), with each lch channel being 65% of the value for teal and 35% of the value for olive.

Note: interpolating on hue and chroma keeps the intermediate colors as saturated as the endpoint colors.

color-mix(teal 65%, olive);
Mixtures of teal and olive. Teal has a hue angle, measured from the positive a axis, of 196.4524 degrees while olive has a hue angle of 99.5746 degrees. Teal has a chroma, or distance from the central neutral axis, of 31.6903 while olive has a chroma of 56.8124. Mixtures lie along the dashed curve. A 65%/35% mixture is shown.

The calculation is as follows:

Instead of mixing all channels equally, color-adjusters can be used to only mix certain channels. The unmixed channels in the result are copied across from the first color.

This example produces the mixture of a deep green and a sky blue, in lch() colorspace (the default), with the lightness being 40% of the lightness of the green (and thus, 60% of the lightness of the blue). The chroma and hue of the green are used unchanged in the mixed result.
color-mix(rgb(0% 42.35% 33.33%) lightness 40%, rgb(41.2% 69.88% 96.64%));

The calculation is as follows:

This example produces the mixture of a red and a sky blue, in lch() colorspace (the default), with the hue being 75.23% of that of the red (and thus, 24.77% of that of the blue). The shorter hue arc will be used. The chroma and lightness of the red are left unchanged.
color-mix(lch(52% 58.1 22.7) hue 75.23%, lch(56% 49.1 257.1));
Mixtures of a red and a sky blue. The red has a hue angle, measured from the positive a axis, of 22.7 degrees while the blue has a hue angle of 257.1 degrees. The red has a chroma, or distance from the central neutral axis, of 58.1 and the chroma is not interpolated here, just the hue. Thus, mixtures lie along the dashed circle.

The calculation is as follows:

This example produces the mixture of a red and a sky blue, in lch() colorspace (the default), with the hue being 75.23% of that of the red (and thus, 24.77% of that of the blue). The longer hue arc has been specified. The chroma and lightness of the red are left unchanged.
color-mix(lch(52% 58.1 22.7) hue longer 75.23%, lch(56% 49.1 257.1) );
Mixtures of a red and a sky blue. The red has a hue angle, measured from the positive a axis, of 22.7 degrees while the blue has a hue angle of 257.1 degrees. The red has a chroma, or distance from the central neutral axis, of 58.1 and the chroma is not interpolated here, just the hue. Thus, mixtures lie along the dashed circle.

The calculation is as follows:

This example produces the mixture of the same two colors as the previous example (a red and a sky blue), in lch() colorspace (the default), with the hue being 75.23% of that of the red (and thus, 24.77% of that of the blue). This time, the lightness is set to 68.4% and the chroma is left unchanged.
color-mix(rgb(82.02% 30.21% 35.02%) hue 75.23% lightness 68.4%, rgb(5.64% 55.94% 85.31%) );

The calculation is as follows:

This example produces the mixture of the same two colors as the previous examples (a red and a sky blue), in xyz colorspace, with the mixture being 75.23% of that of the red (and thus, 24.77% of that of the blue).
color-mix(xyz rgb(82.02% 30.21% 35.02%) 75.23%, rgb(5.64% 55.94% 85.31%));

The calculation is as follows:

This example produces the mixture of red and yellow, in lch() colorspace (the default), with the lightness being 30% of the lightness of red (and thus, 70% of the lightness of yellow). The chroma and hue of red are left unchanged.
color-mix(red lightness 30%, yellow );

The calculation is as follows:

This example demonstrates that not all colors which can be mixed, can be displayed on current devices.

This example produces the mixture of the same two colors as the previous example (a red and a sky blue), in Lab colorspace, with 38% of a and 38% of b. The lightness of the red is left unchanged.

This shows a desaturated result, compared to LCH interpolation, because interpolation is in a stright line on the a,b plane and can thus pass close to the central, neutral axis.

color-mix(lab rgb(82.02% 30.21% 35.02%) a 38% b 38%, rgb(5.64% 55.94% 85.31%));
Mixtures of a red and a sky blue. The red has a hue angle, measured from the positive a axis, of 22.7 degrees while the blue has a hue angle of 257.1 degrees. Interpolation is on the a,b plane. Thus, mixtures lie along the dashed line and pass closer to the neutral axis.

The calculation is as follows:

color-mix to allow more than two colors?

4. Selecting the most contrasting color: the color-contrast() function

This function takes, firstly, a single color (typically a background, but not necessarily), and then second, a list of two or more colors; it selects from that list the color with highest luminance contrast [WCAG21] to the single color.

color-contrast() = color-contrast( <color> vs <color>#  )

add target contrast ratio to color-contrast?

color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e)

The calculation is as follows:

Suppose myAccent has the value #b22222:

The highest contrast ratio is 5.081 so var(--myAccent) wins

The colors in the list (after the keyword vs) are tested sequentially, from left to right; a color is the temporary winner if it has the highest contrast of all those tested so far, and once the end of the list is reached, the current temporary winner is the overall winner. Thus, if two colors in the list happen to have the same contrast, the earlier in the list wins because the later one has the same contrast, not higher.

foo {
  --bg: hsl(200 50% 80%);
  --purple-in-hsl: hsl(300 100% 25%);
  color: color-contrast(var(--bg) vs hsl(200 83% 23%), purple, var(--purple-in-hsl));
  }

The calculation is as follows:

The calculated values here are shown to six significant figures, to demonstrate that early rounding to a lower precision would have given the wrong result (0.061575 is very close to 0.061487; 6.08409 is very close to 6.08889).

5. Modifying colors

Note: There are currently two proposals for modifying colors: color-adjust and Relative color syntax.

there are two proposals for color modification (proposal 1, proposal 2). The CSS WG expects that the best aspects of each will be chosen to produce a single eventual solution. <https://github.com/w3c/csswg-drafts/issues/3187>

5.1. Adjusting colors: the color-adjust function

This function takes one <color> specification and returns the result of adjusting that color, in a given colorspace, by a specified color-adjuster.

Unless otherwise specified, the adjustment is done in the lch colorspace.

Multiple color functions can be specified.

color-adjust() = color-adjust( <color> [ color-adjuster <colorspace>? ]? )
This example produces the adjustment of peru (#CD853F), in lch() colorspace (the default), with the lightness being reduced by 20%. The chroma and hue of red are left unchanged.
color-adjust(peru lightness -20%);

The calculation is as follows:

5.2. Relative color syntax

Besides specifying absolute coordinates, all color functions can also be used with a *relative syntax* to produce colors in the function’s target colorspace, based on an existing color (henceforth referred to as "origin color"). This syntax consists of the keyword from, a <color> value, and optionally numerical coordinates specific to the color function. To allow calculations on the original color’s coordinates, there are single-letter keywords for each coordinate and `alpha` that corresponds to the color’s alpha. If no coordinates are specified, the function merely converts the origin color to the target function’s colorspace.

The following sections outline the relative color syntax for each color function.

A future version of this specification may define a relative syntax for color() as well.

5.2.1. Relative RGB colors

The grammar of the rgb() function is extended as follows:

rgb() = rgb([from <color>]? <percentage>{3} [ / <alpha-value> ]? ) |
    rgb([from <color>]? <number>{3} [ / <alpha-value> ]? )
<alpha-value> = <number> | <percentage>

When an origin color is present, the following keywords can also be used in this function (provided the end result conforms to the expected type for the parameter) and correspond to:

To manipulate color channels in the sRGB colorspace:
rgb(from  indianred 255 g b)

This takes the sRGB value of indianred (205 92 92) and replaces the red channel with 255 to give rgb(255 92 92).

5.2.2. Relative HSL colors

The grammar of the hsl() function is extended as follows:

hsl() = hsl([from <color>]? <hue> <percentage> <percentage> [ / <alpha-value> ]? )
<hue> = <number> | <angle>

When an origin color is present, the following keywords can also be used in this function (provided the end result conforms to the expected type for the parameter) and correspond to:

This adds 180 degrees to the hue angle, giving a complementary color.
--accent:  lightseagreen;
--complement:   hsl(from var(--accent) calc(h+180) s l);

lightseagreen is hsl(177deg 70% 41%), so --complement is hsl(357deg 70% 41%)

5.2.3. Relative HWB colors

The grammar of the hwb() function is extended as follows:

hwb() = hwb([from <color>]? <hue> <percentage> <percentage> [ / <alpha-value> ]? )

When an origin color is present, the following keywords can also be used in this function (provided the end result conforms to the expected type for the parameter) and correspond to:

5.2.4. Relative Lab colors

The grammar of the lab() function is extended as follows:

lab() = lab([from <color>]? <percentage> <number> <number> [ / <alpha-value> ]? )

When an origin color is present, the following keywords can also be used in this function (provided the end result conforms to the expected type for the parameter) and correspond to:

Multiple ways to adjust the transparency of a base color:

Note that all the adjustments are lossless in the sense that no gamut clipping occurs, since lab() encompasses all visible color. This is not true for the alpha adjustments in the sRGB based functions (such as’rgb()', 'hsl()', or 'hwb()'), which would also convert to sRGB in addition to adjusting the alpha transparency.

Fully desaturating a color to gray, keeping the exact same lightness:
--mycolor:  orchid;
// orchid is lab(62.753% 52.460 -34.103)
--mygray:  lab(from var(--mycolor) l 0 0)
// mygray is lab(62.753% 0 0) which is rgb(59.515% 59.515% 59.515%)

5.2.5. Relative LCH colors

The grammar of the lch() function is extended as follows:

lch() = lch([from <color>]? <percentage> <number> <hue> [ / <alpha-value> ]? )

When an origin color is present, the following keywords can also be used in this function (provided the end result conforms to the expected type for the parameter) and correspond to:

lch(from peru calc(l * 0.8) c h) produces a color that is 20% darker than peru or lch(62.2532% 54.0114 63.6769), with its chroma and hue left unchanged. The result is lch(49.80256% 54.0114 63.6769)
This adds 180 degrees to the hue angle, giving the complementary color.
--accent:  lightseagreen;
--complement:   LCH(from var(--accent) l c calc(h + 180));

lightseagreen is LCH(65.4937% 39.4484 190.1013), so --complement is LCH(65.4937% 39.4484 370.1013)

Fully desaturating a color to gray, keeping the exact same lightness:
--mycolor:  orchid;
// orchid is lch(62.753% 62.571 326.973)
--mygray:  lch(from var(--mycolor) l 0 h)
// mygray is lch(62.753% 0 326.973) which is rgb(59.515% 59.515% 59.515%)

But now (since the hue was preserved) re-saturating again

--mymuted:  lch(from var(--mygray) l 30 h);
// mymuted is lch(62.753% 30 326.973) which is rgb(72.710% 53.293% 71.224%)

6. Interpolation

Color interpolation happens with gradients, compositing, filters, transitions, animations, and color mixing and color modification functions.

In general, interpolation between <color> values of the same colorspace occurs by linearly interpolating each component of the computed value of the color separately, in that colorspace. This provides Web compatibility; legacy sRGB content interpolates in the sRGB space by default.

Should gamut mapping occur before or after interpolation?

How to handle achromatic interpolation? <https://github.com/w3c/csswg-drafts/issues/4928>

Interpolating to or from currentcolor is possible. The numerical value used for this purpose is the used value.

6.1. Color space for interpolation

If colors are not in the same color space, they are first converted to Lab and and interpolated as Lab colors. Host syntax can override the interpolation color space and specify which color space is used for interpolation. For example, color-mix and color-adjust override the default to LCH.

Should the colors at 0% and 100% be serialized with their original color spaces or converted to the interpolation space?

6.2. Hue interpolation

For color functions with a hue angle (LCH, HSL, HWB etc), there are multiple ways to interpolate. We typically want to avoid arcs over 360 for the difference between the angles, as they are rarely desirable, so in most cases angles are fixed up prior to interpolation so that per-component interpolation is done over less than 360 degrees, often less than 180.

Host syntax can specify any of the following algorithms for hue interpolation (angles in the following are in degrees, but the logic is the same regardless of how they are specified).

Unless the type of hue interpolation is specified, both angles need to be constrained to [0, 360) prior to interpolation. One way to do this is θ = ((θ % 360) + 360) % 360.

shorter

Angles are adjusted so that θ₂ - θ₁ ∈ [-180, 180]. In pseudo-Javascript:

if (θ₂ - θ₁ > 180) {
  θ₁ += 360;
}
else if (θ₂ - θ₁ < -180) {
  θ₂ += 360;
}
longer

Angles are adjusted so that θ₂ - θ₁ ∈ {0, [180, 360)}. In pseudo-Javascript:

if (0 < θ₂ - θ₁ < 180) {
  θ₁ += 360;
}
else if (-180 < θ₂ - θ₁ < 0) {
  θ₂ += 360;
}
increasing

Angles are adjusted so that θ₂ - θ₁ ∈ [0, 360). In pseudo-Javascript:

if (θ₂ < θ₁) {
  θ₂ += 360;
}
decreasing

Angles are adjusted so that θ₂ - θ₁ ∈ (-360, 0]. In pseudo-Javascript:

if (θ₁ < θ₂) {
  θ₁ += 360;
}
specified

No fixup is performed. Angles are interpolated in the same way as every other component.

Unless otherwise specified, if no specific hue interpolation algorithm is selected by the host syntax, the default is shorter.

If one of the angles has the value NaN, then for interpolation, NaN is replaced by the value of the other hue angle. If both angles have the value NaN, then for interpolation, NaN is replaced by the value 0 for both angles.

How do these work when interpolating between multiple colors? <https://github.com/w3c/csswg-drafts/issues/5277>

7. Security and Privacy Considerations

No new security or privacy considerations have been reported on this specification.

8. Accessibility Considerations

This specification introduces a new feature to help stylesheet authors write stylesheets which conform to WCAG 2.1 section 1.4.3 Contrast (Minimum).

9. Changes

9.1. Since the FPWD of 10 June 2020

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:

style sheet
A CSS style sheet.
renderer
A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool
A UA that writes a style sheet.

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.

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

To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

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.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

CR exit criteria

For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product. For the purposes of this criterion, we define the following terms:

independent
each implementation must be developed by a different party and cannot share, reuse, or derive from code used by another qualifying implementation. Sections of code that have no bearing on the implementation of this specification are exempt from this requirement.
interoperable
passing the respective test case(s) in the official CSS test suite, or, if the implementation is not a Web browser, an equivalent test. Every relevant test in the test suite should have an equivalent test created if such a user agent (UA) is to be used to claim interoperability. In addition if such a UA is to be used to claim interoperability, then there must one or more additional UAs which can also pass those equivalent tests in the same way for the purpose of interoperability. The equivalent tests must be made publicly available for the purposes of peer review.
implementation
a user agent which:
  1. implements the specification.
  2. is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or "nightly build"). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability.
  3. is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward).

The specification will remain Candidate Recommendation for at least six months.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSS-COLOR-3]
Tantek Çelik; Chris Lilley; David Baron. CSS Color Module Level 3. 19 June 2018. REC. URL: https://www.w3.org/TR/css-color-3/
[CSS-COLOR-4]
Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 5 November 2019. WD. URL: https://www.w3.org/TR/css-color-4/
[CSS-COLOR-ADJUST-1]
Elika Etemad; et al. CSS Color Adjustment Module Level 1. 2 April 2020. WD. URL: https://www.w3.org/TR/css-color-adjust-1/
[CSS-VALUES-3]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. 6 June 2019. CR. URL: https://www.w3.org/TR/css-values-3/
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 31 January 2019. WD. URL: https://www.w3.org/TR/css-values-4/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[SVG2]
Amelia Bellamy-Royds; et al. Scalable Vector Graphics (SVG) 2. 4 October 2018. CR. URL: https://www.w3.org/TR/SVG2/
[WCAG21]
Andrew Kirkpatrick; et al. Web Content Accessibility Guidelines (WCAG) 2.1. 5 June 2018. REC. URL: https://www.w3.org/TR/WCAG21/

Issues Index

Do missing adjusters default to 0% everywhere, or only in the second color? If the former, we can end up with adjusters that sum to 0% pretty easily.
color-mix to allow more than two colors?
add target contrast ratio to color-contrast?
there are two proposals for color modification (proposal 1, proposal 2). The CSS WG expects that the best aspects of each will be chosen to produce a single eventual solution. <https://github.com/w3c/csswg-drafts/issues/3187>
A future version of this specification may define a relative syntax for color() as well.
Should gamut mapping occur before or after interpolation?
How to handle achromatic interpolation? <https://github.com/w3c/csswg-drafts/issues/4928>
Should the colors at 0% and 100% be serialized with their original color spaces or converted to the interpolation space?
How do these work when interpolating between multiple colors? <https://github.com/w3c/csswg-drafts/issues/5277>