CSS Color Module Level 4

1. Introduction

This section is not normative.

This module describes CSS properties which allow authors to specify the foreground color and opacity of the text content of an element. This module also describes in detail the CSS <color> value type.

It not only defines the color-related properties and values that already exist in CSS1, CSS2, and CSS Color 3, but also defines new properties and values.

In particular, it allows specifying colors in other color spaces than sRGB; previously, the more saturated colors outside the sRGB gamut could not be used in CSS even if the display device supported them. In addition to the family of RGB color spaces, color spaces with other primaries such as CMYK or KCMYGOV are supported.

A draft implementation report is available.

1.1. Value Definitions

This specification follows the CSS property definition conventions from [CSS2] using the value definition syntax from [CSS-VALUES-3]. Value types not defined in this specification are defined in CSS Values & 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 CSS-wide keywords as their property value. For readability they have not been repeated explicitly.

2. Color Terminology

A color is a definition (numeric or textual) of the human visual perception of a light or a physical object illuminated with light. The objective study of human color perception is termed colorimetry.

The color of a physical object depends on how much light it reflects at each visible wavelength, plus the actual color of the light illuminating it (again, the amount of light at each wavelength). It is measured by a spectrophotometer .

The color of something that emits light (including colors on a computer screen) depends on how much light it emits at each visible wavelength. It is measured by a spectroradiometer.

If two objects have different spectra, but still produce the same physical sensation, we say they have the same color. We can calculate whether two colors are the same by converting the spectra to CIE XYZ (three numbers).

A color space is an organization of colors with respect to an underlying colorimetric model, such that there is a clear, objectively-measurable meaning for any color in that color space. This also means that the same color can be expressed in multiple color spaces, or transformed from one color space to another, while still looking the same.

 color(sRGB 0.41587 0.503670 0.36664);
 color(display-p3 0.43313 0.50108 0.37950);
 color(a98-rgb 0.44091 0.49971 0.37408);
 color(prophoto-rgb 0.36589 0.41717 0.31333);
 color(rec2020 0.42210 0.47580 0.35605);

An additive color space means that the coordinate system is linear in light intensity. The CIE XYZ color space is an additive color space (in addition, the Y component of XYZ is the luminance).

In an additive color space, calculations can be done to accurately predict color mixing. Most RGB spaces are not additive, because the components are gamma encoded. Undoing this gamma encoding produces linear-light values.

A chromaticity is a color measurement where the lightness component has been factored out. From the identical lights example above, the u',v' chromaticity with one light is (0.2537, 0.5268) and the chromaticity is the same with both lights (they are the same color, it is just brighter).

Chromaticities are additive, so they accurately predict the chromaticity (but not the resulting lightness) of a mixture. Being two-dimensional, chromaticity is easily represented on a chromaticity diagram to predict the chromaticity of a color mixture. Any two colors can be mixed, and the resulting colors will lie on the line joining them on the diagram. Three colors form a plane, and the resulting colors will lie in the triangle they form on the diagram.

RGB color spaces are additive, and their gamut is defined by the chromaticities of the red, green and blue primaries, plus the chromaticity of the white point (the color formed by all three primaries at full intensity).

Most color spaces use one of a few daylight-simulating white points, which are named by the color temperature of the corresponding black-body radiator. For example, D65 is a daylight whitepoint corresponding to a correlated color temperature of 6500 Kelvin (actually 6504, because the value of Plank’s constant has changed since the color was originally defined).

To avoid cumulative round-trip errors, it is important that the identical chromaticity values are used consistently, at all places in a calculation. Thus, for maximum compatibility, for this specification, the following two standard daylight-simulating white points are defined:

When the measured physical characteristics (such as the chromaticities of the primary colors it uses, or the colors produced in response to a given set of inputs) of a color space or a color-producing device are known, it is said to be characterized.

If in addition adjustments have been made so that a device meets calibration targets such as white point, neutrality of greys, predictability and consistency of tone response, then it is said to be calibrated.

Real physical devices cannot yet produce every possible color that the human eye can see. The range of colors that a given device can produce is termed the gamut (not to be confused with gamma). Devices with a limited gamut cannot produce very saturated colors, like those found in a rainbow.

The gamuts of different color spaces may be compared by looking at the volume (in cubic Lab units) of colors that can be expressed. The following table examines the predefined color spaces available in CSS.

3. Foreground Color: the color property

This property specifies the primary foreground color of the element. This is used as the fill color of its text content, and in addition specifies the used value that currentcolor resolves to, which allows indirect references to this foreground color and affects the initial values of various other color properties such as border-color and text-emphasis-color.

<color>

Sets the primary foreground color to the specified <color>.

em { color:  lime; }   /* color keyword  */
em { color:  rgb(0 255 0); } /* RGB range 0-255   */
em { color:  rgb(0% 100% 0%); } /* RGB range 0%-100% */
em { color:  color(sRGB 0 1 0); } /* sRGB range 0.0-1.0 */

When applied to text, this property, including its alpha component, has no effect on “color glyphs” (such as the emoji in some fonts), which are colored by a built-in palette. However, some colored fonts are able to refer to a contextual “foreground color”, such as by palette entry 0xFFFF in the COLR table of OpenType, or by the context-fill value in SVG-in-OpenType. In such cases, the foreground color is set by this property, identical to how it sets the currentcolor value.

4. Transparency: the opacity property

Opacity can be thought of as a postprocessing operation. Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering. See simple alpha compositing for details.

<alpha-value>

The opacity to be applied to the element. It is interpreted identically to its definition in rgb(), except that the resulting opacity is applied to the entire element, rather than a particular color.

The opacity property applies the specified opacity to the element as a whole, including its contents, rather than applying it to each descendant individually. This means that, for example, an opaque child occluding part of the element’s background will continue to do so even when opacity is less than 1, but the element and child as a whole will show the underlying page through themselves.

It also means that the glyphs corresponding to all characters in the element are treated as a whole; any overlapping portions do not increase the opacity.

If separate opacity for each glyph is desired, it can be achieved by using a color value which includes opacity, rather than setting the opacity property.

If a box has opacity less than 1, it forms a stacking context for its children. (This prevents its contents from interleaving in the z-axis with content outside it.)

Furthermore, if the z-index property applies to the box, the auto value is treated as 0 for the element; it is otherwise painted on the same layer within its parent stacking context as positioned elements with stack level 0 (as if it were a positioned element with z-index:0).

See section 9.9 and Appendix E of [CSS2] for more information on stacking contexts.

These rules about z-order do not apply to SVG elements, since SVG has its own rendering model ([SVG11], Chapter 3).

5. Representing Colors: the <color> type

CSS has several syntaxes for specifying color values. Some directly specify an sRGB color by its channels, such as the hex color notation or rgb() function. Others are more human-friendly to write and understand, such as the hsl() and lch() functions, or the long list of named colors.

5.1. The <color> syntax

Colors are represented as a list of components, also sometimes called “channels”, representing axises in the color space. Each channel has a minimum and maximum value, and can take any value between those two. Additionally, every color is accompanied by an alpha component, indicating how transparent it is, and thus how much of the backdrop one can see behind the color.

Colors in CSS are represented by the <color> type:

<color> = <absolute-color-base> | currentcolor | <system-color> | <device-cmyk()>

<absolute-color-base> = <hex-color> | <named-color> | transparent |
    <rgb()> | <rgba()> | <hsl()> | <hsla()> | <hwb()> |
    <lab()> | <lch()> |
    <oklab()> | <oklch()> |
    <color()>

The color-functions are <rgb()>, <rgba()>, <hsl()>, <hsla()>, <hwb()>, <lab()>, <lch()>, <oklab()>, <oklch()>, and <color()>.

Of those, <hsl()>, <hsla()>, <hwb()>, <lch()>, and <oklch()> are cylindrical polar color representations, which specify color using a <hue> angle, a central axis representing lightness (black-to-white), and a radius representing saturation or chroma (how far the color is from a neutral grey). The other color spaces are rectangular orthogonal color representations, which specify color using three (or more, in the case of CMYK or CMYKOGV) orthogonal component axes.

For easy reference in other specifications, opaque black is defined as the color rgb(0 0 0 / 100%); transparent black is the same color, but fully transparent—i.e. rgb(0 0 0 / 0%).

All of the <color> syntactic forms defined in this specification use space, not comma, to separate the color components. They also use a solidus ("/") to separate an optional alpha term from the color components.

For Web compatibility, <color> syntactic forms defined in earlier levels of this specification also support legacy color syntax which has the following differences:

• color components are separated by comma-whitespace

• non-opaque forms use a separate notation (for example hsla() rather than hsl())

• minimum required precision is lower, 8 bits per component

For the syntactic forms introduced in this or subsequent levels, where there is no Web compatibility issue, legacy color syntax is not supported, and attempting to use it is an error.

5.2. The <hue> syntax

Hue is represented as an angle of the color circle (the rainbow, twisted around into a circle, and with purple added between violet and red).

<hue> = <number> | <angle> | none

Because this value is so often given in degrees, the argument can also be given as a number, which is interpreted as a number of degrees.

This number is not constrained to the range [0,360] but is unbounded. Certain operations, such as hue interpolation, may normalize the hue angle during calculations.

The angles and spacing corresponding to particular hues depend on the color space. For example, in HSL and HWB, which use the sRGB color space, sRGB green is 120 degrees. In LCH, sRGB green is 134.39 degrees, display-p3 green is 136.01 degrees, a98-rgb green is 145.97 degrees and prophoto-rgb green is 141.04 degrees (because these are all different shades of green).

<hue> components are the most common components to become powerless; any achromatic color will have a powerless hue component.

5.3. “Missing” Color Components and the none Keyword

In certain cases, a color can have one or more missing color components.

In this specification, this happens automatically due to hue-based interpolation for some colors (such as white); other specifications can define additional situations in which components are automatically missing.

It can also be specified explicitly, by providing the keyword none for a component in a color function. All color functions allow any of their components to be specified as none.

For handling of missing component in color interpolation, see § 13.2 Interpolating with Missing Components

For all other purposes, a missing component behaves as a zero value, in the appropriate unit for that component: 0, 0%, or 0deg. This includes rendering the color directly, converting it to another color space, performing computations on the color component values, etc.

If a color with a missing component is serialized or otherwise presented directly to an author, then for legacy color syntax it represents that component as a zero value; otherwise, it represents that component as being the none keyword.

5.3.1. “Powerless” Color Components

Individual color syntaxes can specify that, in some cases, a given component of their syntax becomes a powerless color component. This indicates that the value of the component doesn’t affect the rendered color; any value you give it will result in the same color displayed in the screen.

For example, in hsl(), the hue component is powerless when the saturation component is 0%; a 0% saturation indicates a grayscale color, which has no hue at all, so 0deg and 180deg, or any other angle, will give the exact same result.

If a powerless component is manually specified, it acts as normal; the fact that it’s powerless has no effect. However, if a color is automatically produced by color space conversion, then any powerless components in the result must instead be set to missing, instead of whatever value was produced by the conversion process.

User agents may treat a component as powerless if the color is "sufficiently close" to the precise conditions specified. For example, a gray color converted into lch() may, due to numerical errors, have an extremely small chroma rather than precisely 0%; this can, at the user agent’s discretion, still treat the hue component as powerless. It is intentionally unspecified exactly what "sufficiently close" means for this purpose.

5.4. Accessibility and Conveying Information By Color

Although colors can add significant information to documents and make them more readable, color by itself should not be the sole means to convey important information. Authors should consider the W3C Web Content Accessibility Guidelines [WCAG21] when using color in their documents.

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element

5.5. Color Space of Tagged Images

An tagged image is an image that is explicitly assigned a color profile, as defined by the image format. This is usually done by including an International Color Consortium (ICC) profile [ICC].

For example JPEG [JPEG], PNG [PNG] and TIFF [TIFF] all specify a means to embed an ICC profile.

Image formats may also use other, equivalent methods, often for brevity.

For example, PNG specifies a means (the sRGB chunk) to explicitly tag an image as being in the sRGB color space, without including the sRGB ICC profile.

Tagged RGB images, and tagged images using a transformation of RGB such as YCbCr, if the color profile or other identifying information is valid, must be treated as being in the specified color space.

If the color profile or other identifying information is invalid, the image is treated as untagged images

For example, when a browser running on a system with a Display P3 monitor displays an JPEG image tagged as being in the ITU Rec BT.2020 [Rec.2020] color space, it must convert the colors from ITU Rec BT.2020 to Display P3 so that they display correctly. It must not treat the ITU Rec BT.2020 values as if they were Display P3 values, which would produce incorrect colors.

5.6. Color Spaces of Untagged Colors

Colors specified in HTML, and untagged images must be treated as being in the sRGB color space ([SRGB]) unless otherwise specified.

An untagged image is an image that is not explicitly assigned a color profile, as defined by the image format.

Note that this rule does not apply to untagged videos, since untagged video should be presumed to be in an ITU-defined color space.

• At below 720p, it is Recommendation ITU-R BT.601 [ITU-R-BT.601]

• At 720p, it is SMPTE ST 296 (same colorimetry as 709) [SMPTE296]

• At 1080p, it is Recommendation ITU-R BT.709 [ITU-R-BT.709]

• At 4k (UHDTV) and above, it is ITU-R BT.2020 [Rec.2020] for SDR video

5.7. Resolving <color> Values

Unless otherwise specified for a particular property, specified colors are resolved to computed colors and then further to used colors as described below.

The resolved value of a <color> is its used value.

5.7.1. Resolving sRGB values

This applies to:

• hex colors

• rgb() and rgba() values

• hsl() and hsla() values

• hwb() values

• named colors

  While the function names and named colors are ASCII case-insensitive, the specified value does not preserve any mixed casing and is treated as being all lowercase.

 HsL(39 100% 50%)
 hsl(39 100% 50%)

 pUrPlE
 purple

The computed and used value is the corresponding sRGB color, paired with the specified alpha channel and defaulting to opaque if unspecified).

 hsl(38.824 100% 50%)

 rgb(255, 165, 0)

5.7.2. Resolving Lab and LCH values

This applies to lab() and lch() values.

The computed and used value is the corresponding CIE Lab or LCH color paired with the specified alpha channel (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

 lch(52.2345% 72.2 56.2 / 1)

 lch(52.2345% 72.2 56.2)

5.7.3. Resolving OKLab and OKLCH values

This applies to oklab() and oklch() values.

The computed and used value is the corresponding OKLab or OKLCH color paired with the specified alpha channel (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

 oklch(42.1% 0.192 328.6 / 1)

 oklch(42.1% 0.192 328.6)

5.7.4. Resolving values of the color() function

The computed and used value is the color in the specified color space, paired with the specified alpha channel (as a <number>, not a <percentage>; and defaulting to opaque if unspecified).

 color(display-p3 0.823 0.6554 0.2537 /1)

 color(display-p3 0.823 0.6554 0.2537)

For colors specified in the xyz color space, which is an alias of the xyz-d65 color space, the computed and used value is in the xyz-d65 color space.

 color(xyz 0.472 0.372 0.131)

 color(xyz-d65 0.472 0.372 0.131)

5.7.5. Resolving other colors

This applies to system colors (including the <deprecated-color>s), transparent, and currentcolor.

Each <system-color> keyword computes to the corresponding color in its color space. However, such colors must not be altered by 'forced colors mode'.

The computed and used value of transparent is transparent black.

The currentcolor keyword computes to itself.

In the color property, the used value of currentcolor is the inherited value. In any other property, its used value is the used value of the color property on the same element.

Note: This means that if the currentcolor value is inherited, it’s inherited as a keyword, not as the value of the color property, so descendants will use their own color property to resolve it.

5.8. Serializing <color> Values

This section updates and replaces that part of CSS Object Model, section Serializing CSS Values, which relates to serializing <color> values.

In this section, the strings used in the specification and the corresponding characters are as follows.

The string "." shall be used as a decimal separator, regardless of locale, and there shall be no thousands separator.

For syntactic forms which support missing color components, the value none (equivalently NONE, nOnE, etc), shall be serialized in all-lower case as the string "none".

5.8.1. Serializing alpha values

This applies to any <color> value which can take an optional alpha value.

If the alpha is exactly 1, it is omitted from the serialization; an implicit value of 1 (fully opaque) is the default.

If the alpha is any other value than 1, it is explicitly included in the serialization, as a <number>, not a <percentage>. The value is expressed in base ten, with the "." character as decimal separator. The leading zero must not be omitted. Trailing zeroes must be omitted.

The precision with which alpha values are retained, and thus the number of decimal places in the serialized value, is not defined in this specification, but must at least be sufficient to round-trip integer percentage values. Thus, the serialized value must contain at least two decimal places (unless trailing zeroes have been removed). Values must be rounded towards +∞, not truncated.

5.8.2. Serializing sRGB values

The serialized form of the following sRGB values:

• hex colors

• rgb() and rgba() values

• hsl() and hsla() values

• hwb() values

• named colors

• system colors

• deprecated-colors

is derived from the computed value and thus, uses either the rgb() or rgba() form (depending on whether the alpha is exactly 1, or not), with lowercase letters for the function name.

During serialization, any missing values are converted to 0.

For compatibility, the sRGB component values are serialized in <number> form, not <percentage>). Also for compatibility, the component values are serialized in base 10, with a range of [0-255], regardless of the bit depth with which they are stored.

As noted earlier, unitary alpha values are not explicitly serialized. Also, for compatibility, if the alpha is exactly 1, the rgb() form is used, with an implicit alpha; otherwise, the rgba() form is used, with an explicit alpha value.

For compatibility, the legacy form with comma separators is used; exactly one ASCII space follows each comma. This includes the comma (not slash) used to separate the blue component of rgba() from the alpha value.

 rgb(29 164 192 / 95%)

Note: contrary to CSS Color 3, the parameters of the rgb() function are of type <number> not <integer>. Thus, any higher precision than eight bits is indicated with a fractional part.

Trailing fractional zeroes in any component values must be omitted; if the fractional part consists of all zeroes, the decimal point must also be omitted. This means that sRGB colors specified with integer component values will serialize with backwards-compatible integer values.

The precision with which sRGB component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but must at least be sufficient to round-trip eight bit values. Values must be rounded towards +∞, not truncated.

Note: authors of scripts which expect color values returned from getComputedStyle to have <integer> component values, are advised to update them to cope with <number>.

 rgb(146.064 107.457 131.223)

 rgb(57.28% 42.14% 51.46%)

 goldenrod

5.8.3. Serializing Lab and LCH values

The serialized form of lch() and lab() values is derived from the computed value and uses the lab() or lch() forms, with lowercase letters for the function name.

The component values are serialized in base 10; the Lightness, a and b component values are serialized as <number> with 0% Lightness mapping to 0 and 100% Lightness mapping to 100. A single ASCII space character " " must be used as the separator between the component values.

Trailing fractional zeroes in any component values must be omitted; if the fractional part consists of all zeroes, the decimal point must also be omitted.

 lab(56.200% 0.000 83.600)

 lch(37% 105.0 305.00)

The precision with which lab() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but due to the wide gamut must be sufficient to round-trip L values between 0 and 100, and a and b values between ±127, with at least sixteen bit precision; this will result in at least three decimal places unless trailing zeroes have been omitted. (half float or float, is recommended for internal storage). Values must be rounded towards +∞, not truncated.

Note: a and b values outside ±127 are possible with ultrawide gamut spaces. For example, all of the prophoto-rgb primaries and secondaries exceed this range, but are within ±200.

As noted earlier, unitary alpha values are not explicitly serialized. Non-unitary alpha values must be explicitly serialized, and the string " / " (an ASCII space, then forward slash, then another space) must be used to separate the b component value from the alpha value.

 lch(56.2% 83.6 357.4 /93%)

5.8.4. Serializing OKLab and OKLCH values

The serialized form of oklch() and oklab() values is derived from the computed value and uses the oklab() or oklch() forms, with lowercase letters for the function name.

The component values are serialized in base 10; the Lightness, a and b component values are serialized as <number> with 0% Lightness mapping to 0 and 100% Lightness mapping to 1. A single ASCII space character " " must be used as the separator between the component values.

Trailing fractional zeroes in any component values must be omitted; if the fractional part consists of all zeroes, the decimal point must also be omitted.

 oklab(54.0% -0.10 -0.02)

 oklch(56.43% 0.0900 123.40)

The precision with which oklab() component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but due to the wide gamut must be sufficient to round-trip L values between 0 and 1 (0% and 100%), and a and b values between ±0.5, with at least sixteen bit precision; this will result in at least five decimal places unless trailing zeroes have been omitted. (half float or float, is recommended for internal storage). Values must be rounded towards +∞, not truncated.

Note: a and b values outside ±0.5 are possible with ultrawide gamut spaces. For example, the prophoto-rgb green and blue primaries exceed this range, with chroma of 0.526 and 1.413 respectively.

As noted earlier, unitary alpha values are not explicitly serialized. Non-unitary alpha values must be explicitly serialized, and the string " / " (an ASCII space, then forward slash, then another space) must be used to separate the b component value from the alpha value.

 oklch(53.85% 0.1725 320.67 / 70%)

5.8.5. Serializing values of the color() function

The serialized form of color() values is derived from the computed value and uses the color() form, with lowercase letters for the function name and the color space name.

The component values are serialized in base 10, as <number>. A single ASCII space character " " must be used as the separator between the component values, and also between the color space name and the first color component.

Trailing fractional zeroes in any component values must be omitted; if the fractional part consists of all zeroes, the decimal point must also be omitted.

 color(dIsPlAy-P3  0.964  0.763  0.787)

If the color space is sRGB, the color space is still explicitly required in the serialized result.

For the predefined color spaces, the minimum precision for round-tripping is as follows:

(16bit, half-float, or float per component is recommended for internal storage). Values must be rounded towards +∞, not truncated.

Note: compared to the legacy forms such as rgb(), hsl() and so on, color(srgb) has a higher minimum precision requirement. Stylesheet authors who prefer higher precision are thus encouraged to use the color(srgb) form.

As noted earlier, unitary alpha values are not explicitly serialized. Non-unitary alpha values must be explicitly serialized, and the string " / " (an ASCII space, then forward slash, then another space) must be used to separate the final color component value from the alpha value.

 color(prophoto-rgb 0.2804 0.40283 0.42259/85%)

5.8.6. Serializing other colors

This applies to transparent and currentcolor.

The serialized form of these values is derived from the computed value and uses lowercase letters for the color name.

The serialized form of transparent is the string "rgba(0, 0, 0, 0)".

The serialized form of currentColor is the string "currentcolor".

6. sRGB Colors

CSS colors in the sRGB color space are represented by a triplet of values—red, green, and blue—identifying a point in the sRGB color space [SRGB]. This is an internationally-recognized, device-independent color space, and so is useful for specifying colors that will be displayed on a computer screen, but is also useful for specifying colors on other types of devices, like printers.

CSS also allows the use of non-sRGB color spaces, as described in § 11 Predefined Color Spaces.

CSS provides several methods of directly specifying an sRGB color: hex colors, rgb()/rgba() color-functions, hsl()/hsla() color-functions, hwb() color-function, named colors, and the transparent keyword.

6.1. The RGB functions: rgb() and rgba()

The rgb() function defines an sRGB color by specifying the red, green, and blue channels directly. Its syntax is:

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

The first three arguments specify the red, green, and blue channels of the color, respectively. 0% represents the minimum value for that color channel in the sRGB gamut, and 100% represents the maximum value. A <number> is equivalent to a <percentage>, but with a different range: 0 again represents the minimum value for the color channel, but 255 represents the maximum. These values come from the fact that many graphics engines store the color channels internally as a single byte, which can hold integers between 0 and 255. Implementations should honor the precision of the channel as authored or calculated wherever possible. If this is not possible, the channel should be rounded towards +∞.

The final argument, the <alpha-value>, specifies the alpha of the color. If given as a <number>, the useful range of the value is 0 (representing a fully transparent color) to 1 (representing a fully opaque color). If given as a <percentage>, 0% represents a fully transparent color, while 100% represents a fully opaque color. If omitted, it defaults to 100%.

Values outside these ranges are not invalid, but are clamped to the ranges defined here at computed-value time.

For legacy reasons, rgb() also supports a legacy color syntax that separates all of its arguments with commas:

rgb() = rgb( <percentage>#{3} , <alpha-value>? ) |
  rgb( <number>#{3} , <alpha-value>? )

Also, an rgba() legacy color syntax also exists, with an identical grammar and behavior to rgb().

6.2. The RGB Hexadecimal Notations: #RRGGBB

The CSS hex color notation allows an sRGB color to be specified by giving the channels as hexadecimal numbers, which is similar to how colors are often written directly in computer code. It’s also shorter than writing the same color out in rgb() notation.

The syntax of a <hex-color> is a <hash-token> token whose value consists of 3, 4, 6, or 8 hexadecimal digits. In other words, a hex color is written as a hash character, "#", followed by some number of digits 0-9 or letters a-f (the case of the letters doesn’t matter - #00ff00 is identical to #00FF00).

The number of hex digits given determines how to decode the hex notation into an RGB color:

6 digits

The first pair of digits, interpreted as a hexadecimal number, specifies the red channel of the color, where 00 represents the minimum value and ff (255 in decimal) represents the maximum. The next pair of digits, interpreted in the same way, specifies the green channel, and the last pair specifies the blue. The alpha channel of the color is fully opaque.

In other words, #00ff00 represents the same color as rgb(0 255 0) (a lime green).

8 digits

The first 6 digits are interpreted identically to the 6-digit notation. The last pair of digits, interpreted as a hexadecimal number, specifies the alpha channel of the color, where 00 represents a fully transparent color and ff represent a fully opaque color.

In other words, #0000ffcc represents the same color as rgb(0 0 100% / 80%) (a slightly-transparent blue).

3 digits

This is a shorter variant of the 6-digit notation. The first digit, interpreted as a hexadecimal number, specifies the red channel of the color, where 0 represents the minimum value and f represents the maximum. The next two digits represent the green and blue channels, respectively, in the same way. The alpha channel of the color is fully opaque.

This syntax is often explained by saying that it’s identical to a 6-digit notation obtained by "duplicating" all of the digits. For example, the notation #123 specifies the same color as the notation #112233. This method of specifying a color has lower "resolution" than the 6-digit notation; there are only 4096 possible colors expressible in the 3-digit hex syntax, as opposed to approximately 17 million in 6-digit hex syntax.

4 digits

This is a shorter variant of the 8-digit notation, "expanded" in the same way as the 3-digit notation is. The first digit, interpreted as a hexadecimal number, specifies the red channel of the color, where 0 represents the minimum value and f represents the maximum. The next three digits represent the green, blue, and alpha channels, respectively.

7. Color Keywords

In addition to the various numeric syntaxes for <color>s, CSS defines several sets of color keywords that can be used instead—each with their own advantages or use cases.

7.1. Named Colors

CSS defines a large set of named colors, so that common colors can be written and read more easily. A <named-color> is written as an <ident>, accepted anywhere a <color> is. As usual for CSS-defined <ident>s, all of these keywords are ASCII case-insensitive.

The names resolve to colors in sRGB.

16 of CSS’s named colors come from the VGA palette originally, and were then adopted into HTML: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. Most of the rest come from one version of the X11 color system, used in Unix-derived systems to specify colors for the console, and were then adopted into SVG.

Note: these color names are standardized here, not because they are good, but because their use and implementation has been widespread for decades and the standard needs to reflect reality. Indeed, it is often hard to imagine what each name will look like (hence the list below); the names are not evenly distributed throughout the sRGB color volume, the names are not even internally consistent ( darkgray is lighter than gray, while lightpink is darker than pink), and some names (such as indianred, which was originally named after a red pigment from India), have been found to be offensive. Thus, their use is not encouraged.

(Two special color values, transparent and currentcolor, are specially defined in their own sections.)

The following table defines all of the opaque named colors, by giving equivalent numeric specifications in the other color syntaxes.

Note: this list of colors and their definitions is a superset of the list of named colors defined by SVG 1.1.

Note: The history of the X11 color system is interesting, and was excellently summarized by Alex Sexton in his talk “Peachpuffs and Lemonchiffons”.

7.2. System Colors

In general, the <system-color> keywords reflect default color choices made by the user, the browser, or the OS. They are typically used in the browser default stylesheet, for this reason.

To maintain legibility, the <system-color> keywords also respond to light mode or dark mode changes.

However, in forced colors mode, most colors on the page are forced into a restricted, user-chosen palette. The <system-color> keywords expose these user-chosen colors so that the rest of the page can integrate with this restricted palette.

When the forced-colors media feature is active, authors should use the <system-color> keywords as color values in properties other than those listed in CSS Color Adjust § 3.1 Properties Affected by Forced Colors Mode, to ensure legibility and consistency across the page and avoid an uncoordinated mishmash of user-forced and page-chosen colors.

When the values of <system-color> keywords come from the browser, (as opposed to being OS defaults or user choices) the browser should ensure that matching foreground/background pairs have a minimum of WCAG AA contrast. However, user preferences (for higher or lower contrast), whether set as a browser preference, a user stylesheet, or by altering the OS defaults, must take precedence over this requirement.

Authors may also use these keywords at any time, but should be careful to use the colors in matching background-foreground pairs to ensure appropriate contrast, as any particular contrast relationship across non-matching pairs (e.g. Canvas and ButtonText) is not guaranteed.

The <system-color> keywords are defined as follows:

Canvas

 Background of application content or documents.

CanvasText

 Text in application content or documents.

LinkText

 Text in non-active, non-visited links. For light backgrounds, traditionally blue.

VisitedText

 Text in visited links. For light backgrounds, traditionally purple.

ActiveText

 Text in active links. For light backgrounds, traditionally red.

ButtonFace

 The face background color for push buttons.

ButtonText

 Text on push buttons.

ButtonBorder

 The base border color for push buttons.

Field

 Background of input fields.

FieldText

 Text in input fields.

Highlight

 Background of selected text, for example from ::selection.

HighlightText

 Text of selected text.

SelectedItem

 Background of selected items, for example a selected checkbox.

SelectedItemText

 Text of selected items.

Mark

 Background of text that has been specially marked (such as by the HTML mark element).

MarkText

 Text that has been specially marked (such as by the HTML mark element).

GrayText

 Disabled text. (Often, but not necessarily, gray.)

AccentColor

 Background of accented user interface controls.

AccentColorText

 Text of accented user interface controls.

Note: As with all other keywords, these names are ASCII case-insensitive. They are shown here with mixed capitalization for legibility.

For systems that do not have a particular system UI concept, the specified value should be mapped to the most closely related system color value that exists. The following system color pairings are expected to form legible background-foreground colors:

• Canvas background with CanvasText, LinkText, VisitedText, ActiveText foreground.

• Canvas background with a ButtonBorder border and adjacent color Canvas

• ButtonFace background with ButtonText foreground.

• Field background with FieldText foreground.

• Mark background with MarkText foreground

• ButtonFace or Field background with a ButtonBorder border and adjacent color Canvas'

• Highlight background with HighlightText foreground.

• SelectedItem background with SelectedItemText foreground.

• AccentColor background with AccentColorText foreground.

Additionally, GrayText is expected to be readable, though possibly at a lower contrast rating, over any of the backgrounds.

Earlier versions of CSS defined additional <system-color>s, which have since been deprecated. These are documented in Appendix A: Deprecated CSS System Colors.

Note: The <system-color>s incur some privacy and security risk, as detailed in § 19 Privacy Considerations and § 18 Security Considerations.

7.3. The transparent keyword

The keyword transparent specifies a transparent black. It is a type of <named-color>.

7.4. The currentcolor keyword

The keyword currentcolor represents value of the color property on the same element. Unlike <named-color>s, it is not restricted to sRGB; the value can be any <color>. Its used values is determined by resolving color values.

.foo {
  color:  red;
  background-color:  currentcolor;
}

.foo {
  color:  red;
  background-color:  red;
}

<p><em>Some <strong>really</strong> emphasized text.</em>
<style>
p { color: black; }
em { text-emphasis: dot; }
strong { color: red; }
</style>

Note: Multi-word keywords in CSS usually separate their component words with hyphens. currentcolor doesn’t, because (deep breath) it was originally introduced in SVG as a property value, "current-color" with the usual CSS spelling. It (along with all other properties and their values) then became presentation attributes and attribute values, as well as properties, to make generation with XSLT easier. Then all of the presentation attributes were changed from hyphenated to camelCase, because the DOM had an issue with hyphen meaning "minus". But then, they didn’t follow CSS conventions anymore so all the properties and property values that were already part of CSS were changed back to hyphenated! currentcolor was not a part of CSS at that time, so remained camelCased. Only later did CSS pick it up, at which point the capitalization stopped mattering, as CSS keywords are ASCII case-insensitive.

8. HSL Colors: hsl() and hsla() functions

The RGB system for specifying colors, while convenient for machines and graphic libraries, is often regarded as very difficult for humans to gain an intuitive grasp on. It’s not easy to tell, for example, how to alter an RGB color to produce a lighter variant of the same hue.

There are several other color schemes possible. One such is the HSL [HSL] color scheme, which is much more intuitive to use, but still maps easily back to RGB colors.

HSL colors are specified as a triplet of hue, saturation, and lightness. The syntax of the hsl() function is:

hsl() = hsl( [<hue> | none] [<percentage> | none] [<percentage> | none] [ / [<alpha-value> | none] ]? )

The first argument specifies the hue angle.

In HSL (and HWB) the angle 0deg represents sRGB primary red (as does 360deg, 720deg, etc.), and the rest of the hues are spread around the circle, so 120deg represents sRGB primary green, 240deg represents sRGB primary blue, etc.

The next two arguments are the saturation and lightness, respectively. For saturation, 100% is a fully-saturated, bright color, and 0% is a fully-unsaturated gray. For lightness, 50% represents the "normal" color, while 100% is white and 0% is black. If the saturation or lightness are less than 0% or greater than 100%, they are clamped to those values at computed value time, before being converted to an sRGB color.

The final argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

HSL colors resolve to sRGB.

If the saturation of an HSL color is 0%, then the hue component is powerless. If the lightness of an HSL color is 0% or 100%, both the saturation and hue components are powerless.

An advantage of HSL over RGB is that it is more intuitive: people can guess at the colors they want, and then tweak.

hsl(120deg 100% 50%) lime green
hsl(120deg 100% 25%) dark green
hsl(120deg 100% 75%) light green
hsl(120deg 75% 85%)  pastel green

An advantage of HSL over LCH is that, regardless of manipulation, the result always lies inside the sRGB gamut. A disadvantage of HSL over LCH is that hue manipulation changes the visual lightness, and that hues are not evenly spaced apart.

It is thus easier in HSL to create sets of matching colors (by keeping the hue the same and varying the saturation and lightness), compared to manipulating the sRGB component values; however, because the lightness is simply the mean of the gamma-corrected red, green and blue components it does not correspond to the visual perception of lightness across hues.

The hue angle in HSL is not perceptually uniform; colors appear bunched up in some areas and widely spaced in others.

For legacy reasons, hsl() also supports a legacy color syntax that separates all of its arguments with commas:

hsl() = hsl( <hue>, <percentage>, <percentage>, <alpha-value>? )

Also, an hsla() legacy color syntax also exists, with an identical grammar and behavior to hsl().

8.1. Converting HSL Colors to sRGB

Converting an HSL color to sRGB is straightforward mathematically. Here’s a sample implementation of the conversion algorithm in JavaScript. It returns an array of three numbers representing the red, green, and blue channels of the colors, normalized to the range [0, 1].

function hslToRgb (hue, sat, light) {
    hue = hue % 360;

    if (hue < 0) {
        hue += 360;
    }

    sat /= 100;
    light /= 100;

    function f(n) {
        let k = (n + hue/30) % 12;
        let a = sat * Math.min(light, 1 - light);
        return light - a * Math.max(-1, Math.min(k - 3, 9 - k, 1));
    }

    return [f(0), f(8), f(4)];
}

8.2. Converting sRGB Colors to HSL

Conversion in the reverse direction proceeds similarly.

function rgbToHsl (red, green, blue) {
    let max = Math.max(red, green, blue);
    let min = Math.min(red, green, blue);
    let [hue, sat, light] = [NaN, 0, (min + max)/2];
    let d = max - min;

    if (d !== 0) {
        sat = (light === 0 || light === 1)
            ? 0
            : (max - light) / Math.min(light, 1 - light);

        switch (max) {
            case red:   hue = (green - blue) / d + (green < blue ? 6 : 0); break;
            case green: hue = (blue - red) / d + 2; break;
            case blue:  hue = (red - green) / d + 4;
        }

        hue = hue * 60;
    }

    return [hue, sat * 100, light * 100];
}

8.3. Examples of HSL Colors

The tables below illustrate a wide range of possible HSL colors. Each table represents one hue, selected at 30° intervals, to illustrate the common "core" hues: red, yellow, green, cyan, blue, magenta, and the six intermediary colors between these.

In each table, the X axis represents the saturation while the Y axis represents the lightness.

9. HWB Colors: hwb() function

HWB (short for Hue-Whiteness-Blackness) [HWB] is another method of specifying sRGB colors, similar to HSL', but often even easier for humans to work with. It describes colors with a starting hue, then a degree of whiteness and blackness to mix into that base hue.

Many color-pickers are based on the HWB color system, due to its intuitiveness.

HWB colors resolve to sRGB.

The syntax of the hwb() function is:

hwb() = hwb( [<hue> | none] [<percentage> | none] [<percentage> | none] [ / [<alpha-value> | none] ]? )

The first argument specifies the hue, and is interpreted identically to hsl().

The second argument specifies the amount of white to mix in, as a percentage from 0% (no whiteness) to 100% (full whiteness). Similarly, the third argument specifies the amount of black to mix in, also from 0% (no blackness) to 100% (full blackness). Values outside of these ranges are not invalid, but are clamped to the ranges defined here at computed-value time. If the sum of these two arguments is greater than 100%, then at computed-value time they are further normalized to add up to 100%, with the same relative ratio.

The fourth argument specifies the alpha channel of the color. It’s interpreted identically to the fourth argument of the rgb() function. If omitted, it defaults to 100%.

The resulting color can be thought of conceptually as a mixture of paint in the chosen hue, white paint, and black paint, with the relative amounts of each determined by the percentages. If white+black is equal to 100% (after normalization), it defines an achromatic color, i.e. some shade of gray, without any hint of the chosen hue. In this case, the hue component is powerless.

There is no Web compatibility issue with hwb, which is new in this level of the specification, and so hwb() does not support a legacy color syntax that separates all of its arguments with commas. Using commas inside hwb() is an error.

9.1. Converting HWB Colors to sRGB

Converting an HWB color to sRGB is straightforward, and related to how one converts HSL to RGB. The following Javascript implementation of the algorithm first normalizes the white and black components, so their sum is no larger than 100%.

function hwbToRgb(hue, white, black) {
    white /= 100;
    black /= 100;
    if (white + black >= 1) {
        let gray = white / (white + black);
    return [gray, gray, gray];
    }
    let rgb = hslToRgb(hue, 100, 50);
    for (let i = 0; i < 3; i++) {
        rgb[i] *= (1 - white - black);
        rgb[i] += white;
    }
    return rgb;
}

9.2. Converting sRGB Colors to HWB

Conversion in the reverse direction proceeds similarly.

function rgbToHwb(red, green, blue) {
    var hsl = rgbToHsl(red, green, blue);
    var white = Math.min(red, green, blue);
    var black = 1 - Math.max(red, green, blue);
    return([hsl[0], white*100, black*100]);
}

9.3. Examples of HWB Colors

10. Device-independent Colors: CIE Lab and LCH, OKLab and OKLCH

10.1. CIE Lab and LCH

Physical measurements of a color are typically expressed in the CIE L*a*b* [CIELAB] color space, created in 1976 by the CIE and commonly referred to simply as Lab. Color conversions from one device to another may also use Lab as an intermediate step. Derived from human vision experiments, Lab represents the entire range of color that humans can see.

Lab is a rectangular coordinate system with a central Lightness axis. This value is usually written as a unitless number; for compatibility with the rest of CSS, it is written as a percentage. 100% means an L value of 100, not 1.0. L=0% is deep black (no light at all) while L=100% is a diffuse white

Values of L greater than 100 would correspond to specular highlights, but their precise color is undefined in this specification. Usefully, L=50% is mid gray, by design, and equal increments in L are evenly spaced visually: the Lab color space is intended to be perceptually uniform.

The a and b axes convey hue; positive values along the a axis are a purplish red while negative values are the complementary color, a green. Similarly, positive values along the b axis are yellow and negative are the complementary blue/violet. Desaturated colors have small values of a and b and are close to the L axis; saturated colors lie far from the L axis.

The illuminant is D50 white, a standardized daylight spectrum with a color temperature of 5000K, as reflected by a perfect diffuse reflector; it approximates the color of sunlight on a sunny day. D50 is also the whitepoint used for the profile connection space in ICC color interconversion, the whitepoint used in image editors which offer Lab editing, and the value used by physical measurement devices such as spectrophotometers and spectroradiometers, when they report measured colors in Lab.

Conversion from colors specified using other white points is called a chromatic adaptation transform, which models the changes in the human visual system as we adapt to a new lighting condition. The Bradford algorithm [Bradford-CAT] is the industry standard chromatic adaptation transform, and is easy to calculate as it is a simple matrix multiplication.

CIE LCH has the same L axis as Lab, but uses polar coordinates C (chroma) and H (hue), making it a polar, cylindrical coordinate system. C is the geometric distance from the L axis and H is the angle from the positive a axis, towards the positive b axis.

Note: The Lightness axis in Lab and LCH is not to be confused with the L axis in HSL. For example, in HSL, the sRGB colors blue (#00F) and yellow (#FF0) have the same value of L (50%) even though visually, blue is much darker. This is much clearer in Lab: sRGB blue is lab(29.567% 68.298 -112.0294) while sRGB yellow is lab(97.607% -15.753 93.388). In Lab and LCH, if two colors have the same measured L value, they have identical visual lightness. HSL and related polar RGB models were developed in an attempt to give similar usability benefits for RGB that LCH gave to Lab, but are significantly less accurate.

Although the use of CIE Lab and LCH is widespread, it is known to have some problems. In particular:

Hue linearity

In the blue region (LCH Hue between 270° and 330°), visual hue departs from what LCH predicts. Plotting a set of blues of the same hue and differing Chroma, which should lie on a straight line from the neutral axis, instead form a curve. Put another way, as a saturated blue has it’s Chroma progressively reduced, it becomes noticeably purple.

Hue uniformity

While hues in LCH are in general evenly spaced, (and far better than HSL or HWB), uniformity is not perfect.

Over-prediction of high Chroma differences

For high Chroma colors, changes in Chroma are less noticeable than for more neutral colors.

These deficiencies affect, for example, creation of evenly spaced gradients, gamut mapping from one color space to a smaller one, and computation of the visual difference between two colors.

To compensate for this, formulae to predict the visual difference betwen two colors (delta E) have been made more accurate over time (but also, much more complex to compute). The current industry standard formula, delta E 2000, works well to mitigate some of the Lab and LCH problems. A sample implementation is given in § 17.1 ΔE2000.

This does not help with hue curvature, however.

10.2. OKLab and OKLCH

Recently, OKLab, an improved Lab-like space has been developed [OKLab]. The corresponding polar form is called OKLCH. It was produced by numerical optimisation of a large dataset of visually similar colors, and has improved hue linearity, hue uniformity, and chroma uniformity compared to CIE LCH.

Like CIE Lab, there is a central lightness axis which is usually written as a unitless number in the range [0,1]; for compatibility with the rest of CSS, it is written as a percentage. 100% means an L value of 1.0. L=0% is deep black (no light at all) while L=100% is a diffuse white.

Note: Unlike CIE Lab, which assumes adaptation to the diffuse white, OKLab assumes adaptation to the color being defined, which is intended to make it scale invariant.

As with CIE Lab, the a and b axes convey hue; positive values along the a axis are a purplish red while negative values are the complementary color, a green. Similarly, positive values along the b axis are yellow and negative are the complementary blue/violet.

The illuminant is D65, the same white point as most RGB color spaces.

OKLCH has the same L axis as OKLab, but uses polar coordinates C (chroma) and H (hue).

Note: Unlike CIE LCH, where Chroma can reach values of 200 or more, OKLCH Chroma ranges to 0.5 or so. The hue angles between CIE LCH and OKLCH are broadly similar, but not identical.

Because OKLab is more perceptually uniform, the color difference is a straightforward distance in 3D space (root sum of squares). Although trivial, a sample implementation is give in § 17.2 ΔEOK.

10.3. Specifying Lab and LCH: the lab() and lch() functional notations

CSS allows colors to be directly expressed in Lab and LCH.

lab() = lab( [<percentage> | <number> | none]
      [ <percentage> | <number> | none]
      [ <percentage> | <number> | none]
      [ / [<alpha-value> | none] ]? )

The first argument specifies the CIE Lightness. This is typically a number between 0% (representing black) and 100% (representing white), However, CIE Lightness can exceed this range on some systems, with extra-bright whites using a lightness up to 400. Values less than 0% must be clamped to 0% at computed-value time; values greater than 100% are permitted (for forwards compatibility with High Dynamic Range (HDR), and must not be clamped.

The second and third arguments are the distances along the "a" and "b" axes in the Lab color space, as described in the previous section. These values are signed (allow both positive and negative values) and theoretically unbounded (but in practice do not exceed ±160).

There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().

If the lightness of a Lab color is 0%, both the a and b components are powerless.

Unsure about when/if a and b become powerless for Lab whites.

 lab(29.2345% 39.3825 20.0664);
 lab(52.2345% 40.1645 59.9971);
 lab(60.2345 -5.3654 58.956);
 lab(62.2345% -34.9638 47.7721);
 lab(67.5345% -8.6911 -41.6019);
 lab(29.69% 44.888% -29.04%)

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

The first argument specifies the CIE Lightness, interpreted identically to the Lightness argument of lab().

The second argument is the chroma (roughly representing the "amount of color"). Its minimum useful value is 0, while its maximum is theoretically unbounded (but in practice does not exceed 230). If the provided value is negative, it is clamped to 0 at computed-value time.

The third argument is the hue angle. It’s interpreted similarly to the <hue> argument of hsl(), but doesn’t map hues to angles in the same way because they are evenly spaced perceptually. Instead, 0deg points along the positive "a" axis (toward purplish red), (as does 360deg, 720deg, etc.); 90deg points along the positive "b" axis (toward mustard yellow), 180deg points along the negative "a" axis (toward greenish cyan), and 270deg points along the negative "b" axis (toward sky blue).

There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().

If the chroma of an LCH color is 0%, the hue component is powerless. If the lightness of an LCH color is 0%, both the hue and chroma components are powerless.

Unsure about when/if hue and chroma become powerless for LCH whites.

 lch(29.2345% 44.2 27);
 lch(52.2345% 72.2 56.2);
 lch(60.2345 59.2 95.2);
 lch(62.2345% 59.2 126.2);
 lch(67.5345% 42.5 258.2);
 lch(29.69% 45.553% 327.1)

There is no Web compatibility issue with lab or lch', which are new in this level of the specification, and so lab() and lch() do not support a legacy color syntax that separates all of their arguments with commas. Using commas inside these functions is an error.

10.4. Specifying OKLab and OKLCH: the oklab() and oklch() functional notations

CSS allows colors to be directly expressed in OKLab and OKLCH.

oklab() = oklab( [ <percentage> | <number> | none]
    [ <percentage> | <number> | none]
    [ <percentage> | <number> | none]
    [ / [<alpha-value> | none] ]? )

The first argument specifies the OKLab Lightness. This is typically a number between 0% (representing black) and 100% (representing white).

Values less than 0% must be clamped to 0% at computed-value time; values greater than 100% are permitted for forwards compatibility, and must not be clamped.

The second and third arguments are the distances along the "a" and "b" axes in the OKLab color space, as described in the previous section. These values are signed (allow both positive and negative values) and theoretically unbounded (but in practice do not exceed ±0.5).

There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().

If the lightness of an OKLab color is 0%, both the a and b components are powerless.

 oklab(40.101% 0.1147 0.0453);
 oklab(59.686% 0.1009 0.1192);
 oklab(0.65125 -0.0320 0.1274);
 oklab(66.016% -0.1084 0.1114);
 oklab(72.322% -0.0465 -0.1150);
 oklab(42.1% 41% -25%)

oklch() = oklch( [ <percentage> | <number> | none]
      [ <percentage> | <number> | none]
      [ <hue> | none]
      [ / [<alpha-value> | none] ]? )

The first argument specifies the OKLCH Lightness, interpreted identically to the Lightness argument of oklab().

The second argument is the chroma. Its minimum useful value is 0, while its maximum is theoretically unbounded (but in practice does not exceed 0.5). If the provided value is negative, it is clamped to 0 at computed-value time.

The third argument is the hue angle. It’s interpreted similarly to the <hue> arguments of hsl() and lch(), but doesn’t map hues to angles in the same way. 0deg points along the positive "a" axis (toward purplish red), (as does 360deg, 720deg, etc.); 90deg points along the positive "b" axis (toward mustard yellow), 180deg points along the negative "a" axis (toward greenish cyan), and 270deg points along the negative "b" axis (toward sky blue).

There is an optional fourth alpha value, separated by a slash, and interpreted identically to the <alpha-value> in rgb().

If the chroma of an OKLCH color is 0%, the hue component is powerless. If the lightness of an OKLCH color is 0%, both the hue and chroma components are powerless.

 oklch(40.101% 0.12332 21.555);
 oklch(59.686% 0.15619 49.7694);
 oklch(0.65125 0.13138 104.097);
 oklch(0.66016 0.15546 134.231);
 oklch(72.322% 0.12403 247.996);
 oklch(42.1% 48.25% 328.4)

There is no Web compatibility issue with oklab or oklch', which are new in this level of the specification, and so oklab() and oklch() do not support a legacy color syntax that separates all of their arguments with commas. Using commas inside these functions is an error.

10.5. Converting Lab or OKLab colors to LCH or OKLCH colors

Conversion to the polar form is trivial:

1. H = atan2(b, a)
2. C = sqrt(a^2 + b^2)
3. L is the same

For extremely small values of a and b (near-zero Chroma), although the visual color does not change from being on the neutral axis, small changes to the values can result in the reported hue angle swinging about wildly and being essentially random. In CSS, this means the hue is powerless, and treated as missing when converted into LCH or OKLCH; in non-CSS contexts this might be reflected as a missing value, such as NaN.

10.6. Converting LCH or OKLCH colors to Lab or OKLab colors

Conversion to the rectangular form is trivial:

1. If H is missing, a = b = 0
2. Otherwise,
   1. a = C cos(H)
   2. b = C sin(H)
3. L is the same

11. Predefined Color Spaces

CSS provides several predefined color spaces including display-p3 [Display-P3], which is a wide gamut space typical of current wide-gamut monitors, prophoto-rgb, widely used by photographers and rec2020 [Rec.2020], which is a broadcast industry standard, ultra-wide gamut space capable of representing almost all visible real-world colors.

11.1. Specifying Predefined Colors: the color() function

The color() function allows a color to be specified in a particular, specified color space (rather than the implicit sRGB color space that most of the other color functions operate in). Its syntax is:

color() = color( <colorspace-params> [ / [ <alpha-value> | none ] ]? )
<colorspace-params> = [ <predefined-rgb-params> | <xyz-params>]
<predefined-rgb-params> = <predefined-rgb> [ <number> | <percentage> | none ]{3}
<predefined-rgb> = srgb | srgb-linear | display-p3 | a98-rgb | prophoto-rgb | rec2020
<xyz-params> = <xyz-space> [ <number> | none ]{3}
<xyz-space> = xyz | xyz-d50 | xyz-d65

The color function takes parameters specifying a color, in an explicitly listed color space.

It represents either an invalid color, as described below, or a valid color.

Any color which is not an invalid color is a valid color.

A color may be a valid color but still be outside the range of colors that can be produced by an output device (a screen, projector, or printer). It is said to be out of gamut for that color space.

An out of gamut color has component values less than 0 or 0%, or greater than 1 or 100%. These are not invalid; instead, for display, they are css gamut mapped using a relative colorimetric intent which brings the values within the range 0/0% to 1/100% at computed-value time.

Each valid color is either in-gamut for the output device (screen, or printer), or it is out of gamut.

The parameters have the following form:

• An <ident> denoting one of the predefined color spaces (such as display-p3) Individual predefined color spaces may further restrict whether <number>s or <percentage>s or both, may be used.

  If the <ident> names a non-existent color space (a name that does not match one of the predefined color spaces), this argument represents an invalid color.

• One or more <number>s or <percentage>s providing the parameter values that the color space takes.

  Specified component values less than 0 or 0%, or greater than 1 or 100% are not invalid; these out of gamut colors are gamut mapped to the valid range at computed value time, with a relative colorimetric intent.

• An optional slash-separated <alpha-value>. This is interpreted the same way as the <alpha-value> in rgb(), and if omitted it defaults to 100%.

There is no Web compatibility issue with color(), which is new in this level of the specification, and so color() does not support a legacy color syntax that separates all of its arguments with commas. Using commas inside this function is an error.

A color which is either an invalid color or an out of gamut color can’t be displayed.

If the specified color can be displayed, (that is, it isn’t an invalid color and isn’t out of gamut) then this is the used value of the color() function.

If the specified color is a valid color but can’t be displayed], the used value is derived from the specified color, css gamut mapped for display.

If the color is an invalid color, the used value is opaque black.

color(rec2020 0.42053 0.979780 0.00579);

lch(86.6146% 160.0000 136.0088);

color(display-p3 -0.6112 1.0079 -0.2192);

color(profoto-rgb 0.4835 0.9167 0.2188)

11.2. The Predefined sRGB Color Space: the sRGB keyword

The sRGB predefined color space defined below is the same as is used for legacy sRGB colors, such as rgb().

srgb

The srgb [SRGB] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The whitepoint is D65.

[SRGB] specifies two viewing conditions, encoding and typical. The [ICC] recommends using the encoding conditions for color conversion and for optimal viewing, which are the values in the table below.

sRGB is the default color space for CSS, used for all the legacy color functions.

It has the following characteristics:

	x	y
Red chromaticity	0.640	0.330
Green chromaticity	0.300	0.600
Blue chromaticity	0.150	0.060
White chromaticity	D65
Transfer function	see below
White luminance	80.0 cd/m2
Black luminance	0.20 cd/m2
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

let sign = c < 0? -1 : 1;
let abs = Math.abs(c);

if (abs < 0.04045) {
  cl = c / 12.92;
}
else {
  cl = sign * (Math.pow((abs + 0.055) / 1.055, 2.4));
}

c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

Tests

• predefined-001.html (live test) (source)
• predefined-002.html (live test) (source)
• color-valid.html (live test) (source)

11.3. The Predefined Linear-light sRGB Color Space: the srgb-linear keyword

The sRGB-linear predefined color space is the same as srgb except that the transfer function is linear-light (there is no gamma-encoding).

srgb-linear

The srgb-linear [SRGB] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The whitepoint is D65.

It has the following characteristics:

	x	y
Red chromaticity	0.640	0.330
Green chromaticity	0.300	0.600
Blue chromaticity	0.150	0.060
White chromaticity	D65
Transfer function	unity, see below
White luminance	80.0 cd/m2
Black luminance	0.20 cd/m2
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

cl = c;

c is the red, green or blue component. cl is the corresponding linear-light component, which is identical.

Tests

• srgb-linear-001.html (live test) (source)
• srgb-linear-002.html (live test) (source)
• srgb-linear-003.html (live test) (source)
• srgb-linear-004.html (live test) (source)
• color-valid.html (live test) (source)

To avoid banding artifacts, a higher precision is required for srgb-linear than for srgb.

For example, these are the same color

 color(srgb 0.691 0.139 0.259)
 color(srgb-linear 0.435 0.017 0.055)

11.4. The Predefined Display P3 Color Space: the display-p3 keyword

display-p3

The display-p3 [Display-P3] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. It uses the same primary chromaticities as [DCI-P3], but with a D65 whitepoint, and the same transfer curve as sRGB.

Modern displays, TVs, laptop screens and phone screens are able to display all, or nearly all, of the display-p3 gamut.

It has the following characteristics:

	x	y
Red chromaticity	0.680	0.320
Green chromaticity	0.265	0.690
Blue chromaticity	0.150	0.060
White chromaticity	D65
Transfer function	same as srgb
White luminance	80.0 cd/m2
Black luminance	0.80 cd/m2
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

Tests

• color-function-parsing.html (live test) (source)
• predefined-005.html (live test) (source)
• predefined-006.html (live test) (source)
• display-p3-001.html (live test) (source)
• display-p3-002.html (live test) (source)
• display-p3-003.html (live test) (source)
• display-p3-004.html (live test) (source)
• display-p3-005.html (live test) (source)
• display-p3-006.html (live test) (source)

11.5. The Predefined A98 RGB Color Space: the a98-rgb keyword

a98-rgb

The a98-rgb color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The transfer curve is a gamma function, close to but not exactly 1/2.2.

It has the following characteristics:

	x	y
Red chromaticity	0.6400	0.3300
Green chromaticity	0.2100	0.7100
Blue chromaticity	0.1500	0.0600
White chromaticity	D65
Transfer function	256/563
White luminance	160.0 cd/m2
Black luminance	0.5557 cd/m2
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

Tests

• predefined-007.html (live test) (source)
• predefined-008.html (live test) (source)
• a98rgb-001.html (live test) (source)
• a98rgb-002.html (live test) (source)
• a98rgb-003.html (live test) (source)
• a98rgb-004.html (live test) (source)
• color-valid.html (live test) (source)

11.6. The Predefined ProPhoto RGB Color Space: the prophoto-rgb keyword

prophoto-rgb

The prophoto-rgb color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1]. The transfer curve is a gamma function with a value of 1/1.8, and a small linear portion near black. The white point is D50, the same as is used by CIE Lab. Thus, conversion to CIE Lab does not require the chromatic adaptation step.

The ProPhoto RGB space uses hyper-saturated, non physically realizable primaries. These were chosen to allow a wide color gamut and in particular, to minimize hue shifts under tonal manipulation. It is often used in digital photography as a wide gamut color space for the archival version of photographic images. The prophoto-rgb color space allows CSS to specify colors that will match colors in such images having the same RGB values.

The ProPhoto RGB space was originally developed by Kodak and is described in [Wolfe]. It was standardized by ISO as [ROMM],[ROMM-RGB].

The white luminance is given as a range, and the viewing flare (and thus, the black luminance) is 0.5% to 1.0% of this.

It has the following characteristics:

	x	y
Red chromaticity	0.734699	0.265301
Green chromaticity	0.159597	0.840403
Blue chromaticity	0.036598	0.000105
White chromaticity	D50
Transfer function	see below
White luminance	160.0 to 640.0 cd/m2
Black luminance	See text
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

const E = 16/512;
let sign = c < 0? -1 : 1;
let abs = Math.abs(c);

if (abs <= E) {
  cl =  c / 16;
}
else {
  cl = sign * Math.pow(c, 1.8);
}

c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

Tests

• predefined-009.html (live test) (source)
• predefined-010.html (live test) (source)
• prophoto-rgb-001.html (live test) (source)
• prophoto-rgb-002.html (live test) (source)
• prophoto-rgb-003.html (live test) (source)
• prophoto-rgb-004.html (live test) (source)
• prophoto-rgb-005.html (live test) (source)
• color-valid.html (live test) (source)

11.7. The Predefined ITU-R BT.2020-2 Color Space: the rec2020 keyword

rec2020

The rec2020 [Rec.2020] color space accepts three numeric parameters, representing the red, green, and blue channels of the color. In-gamut colors have all three components in the range [0, 1], ("full-range", in video terminology). ITU Reference 2020 is used for Ultra High Definition, 4k and 8k television.

The primaries are physically realizable, but with difficulty as they lie very close to the spectral locus.

Current displays are unable to reproduce the full gamut of rec2020. Coverage is expected to increase over time as displays improve.

It has the following characteristics:

	x	y
Red chromaticity	0.708	0.292
Green chromaticity	0.170	0.797
Blue chromaticity	0.131	0.046
White chromaticity	D65
Transfer function	see below, from [Rec.2020] table 4
Image state	display-referred
Percentages	Allowed for R, G and B
Percent reference range	for R,G,B: 0% = 0.0, 100% = 1.0

const α = 1.09929682680944 ;
const β = 0.018053968510807;

let sign = c < 0? -1 : 1;
let abs = Math.abs(c);

if (abs < β * 4.5 ) {
  cl = c / 4.5;
}
else {
  cl = sign * (Math.pow((abs + α -1 ) / α, 1/0.45));
}

c is the gamma-encoded red, green or blue component. cl is the corresponding linear-light component.

Tests

• predefined-011.html (live test) (source)
• predefined-012.html (live test) (source)
• rec2020-001.html (live test) (source)
• rec2020-002.html (live test) (source)
• rec2020-003.html (live test) (source)
• rec2020-004.html (live test) (source)
• rec2020-005.html (live test) (source)
• color-valid.html (live test) (source)