# Additions to CSS Color 4

## Editor’s Draft, 1 January 1970

This version:
  none
Feedback:
  www-svg@w3.org with subject line “`[svg-color] … message topic …`” (archives)
Editor:
  Chris Lilley (W3C)

Copyright © 1970 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

## Abstract

This is a temporary place for additions to CSS Colors 4 and moved from SVG2.

## 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 http://www.w3.org/TR/.

This document is the 1 January 1970 Editor’s Draft of Additions to CSS Color 4.

Comments on this Editor’s Draft are welcome. Comments can be sent to www-svg@w3.org, the public email list for issues related to vector graphics on the Web. This list is archived and senders must agree to have their message publicly archived from their first posting. To subscribe send an email to www-svg-request@w3.org with the word `subscribe` in the subject line.

This document has been produced by the SVG Working Group as part of the Graphics Activity within the W3C Interaction Domain. The goals of the W3C SVG Working Group are discussed in the W3C SVG Charter. The W3C SVG Working Group maintains a public Web page, http://www.w3.org/Graphics/SVG/, that contains further background information. The authors of this document are the SVG Working Group participants.

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 each group; these pages 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.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time.

SVG 2 Requirement: | Support color management.
Resolution: | SVG 2 will depend on SVG color management subject to deciding the exact conformance classes required.
Purpose: | To align with mainstream graphcs use, allow fluorescent colors, more than 8 bit color, etc.
Owner: | Chris (ACTION-3160)
Note: | SVG color management will become a chapter in SVG 2, no longer an independent module.

SVG 2 Requirement: | Support CSS3 Color syntax.
Resolution: | SVG 2 will depend on CSS3 Color.
Purpose: | To align with CSS, given CSS3 Color is widely implemented.
Owner: | Chris (no action)

## 1. Introduction

This introduction is informative, not normative.

Several properties used in SVG take a color specification. Also, external media such as images or video contain colors.

All SVG colors used as property values include a fallback specified in the sRGB color space [SRGB].

Additionally, SVG content can specify an alternate color specification using an ICC profile [ICC42]. If ICC-based colors are provided, then the ICC-based color takes precedence over the sRGB color specification; otherwise, the sRGB fallback colors will be used. Note that, in this specification, by default color interpolation occurs in sRGB color space even if an ICC-based color specification is provided, but this can be changed (see color-interpolation).

## 2. Color-managed images

New in SVG 2.

Implementations of SVG 2 are required to color-manage all images. The embedded profile is used. If there is no embedded profile, sRGB is assumed, for RGB images.

Define processing for untagged greyscale and CMYK images. Could be a default profile, or an 'explicitly undefined' with a warning to avoid untagged non-RGB images when authoring.

References to "SVG 2 User Agent" might need to be replaced with one of the conformance classes listed in the Conformance appendix.

If a referenced image contains color profile information, a SVG 2 User Agent MUST use that profile to render the image. Otherwise, if a referenced image contains no color profile information, a SVG 2 User Agent MUST use the sRGB profile to render the image.

## 3. Color syntax

### 3.1. sRGB colors

<color>

Example (these all represent the same color):

    <circle fill="rgb(205,133,63)"/>
    <circle fill="peru"/>
    <circle fill="rgb(80.392%, 52.157%, 24.706%)"/>
    <circle fill="#CD853F"/>
    <circle fill="hsl(30, 59%, 53%)"/>

Includes all syntactic forms supported by SVG 1.1, adds hsl() from [CSS3COLOR].

See the CSS Color Module Level 3 specification for the definition of the color type. [CSS3COLOR]

Must add the hsla and hsl forms.

All the syntactic forms for an sRGB color, including the full set of color keywords, shall be supported by an SVG 2 User Agent.

The rendering requirements for sRGB colors are more strict than for SVG 1.1 User Agents, where color management is optional.

When an sRGB color is used - because it is the sole color specification, or in a permitted fallback situation - a conformant SVG 2 User Agent shall render it in conformance with the ICC profile for sRGB, to obtain the desired color appearance.

Define 'permitted fallback situation' and link to it.

### 3.2. sRGB colors with alpha

rgba(r, g, b, a)

Example

    <circle fill="rgba(205,133,63, 0.5)"/>

New in SVG 2, added from [CSS3COLOR].

When an sRGB color with alpha is used in a property value, an SVG 2 User Agent shall combine the alpha value with any separately specified alpha value that applies to that property, by multiplying the alpha values together.

Example (these render as the same color)

    <circle fill="rgba(205,133,63, 0.25)"/>
    <circle fill="rgba(205,133,63, 1.0)" fill-opacity="0.25"/>
    <circle fill="rgba(205,133,63, 0.5)" fill-opacity="0.5"/>

When an sRGB color with alpha is used - because it is the sole color specification, or in a permitted fallback situation - a conformant SVG 2 User Agent shall render it in conformance with the ICC profile for sRGB, to obtain the desired color appearance.

### 3.3. ICC colors

<fallback> icc-color(<name> [,<icccolorvalue>]*)

This grammar doesn’t match the grammar below. Also the ones below should be translated from EBNF to CSS Value syntax.

Example:

    <style>
    @color-profile {
      name: acmecmyk;
      src: url(http://printers.example.com/acmecorp/model1234);
    }
    </style>
    <circle fill="#CD853F icc-color(acmecmyk, 0.11, 0.48, 0.83, 0.00)"/>

Same syntax as SVG 1.1, increased conformance requirement.

SVG 2 uses the extended ICC color specification from SVG 1.1. In SVG 1.1, parsing the syntax was required but implementing the ICC colour itself was optional, as indicated by phrases such as "If ICC-based colors are provided and the SVG user agent supports ICC color, then...". An SVG 1.1 user agent which also conforms to this specification "supports ICC color" for the purposes of conforming to SVG 1.1.

As with SVG Full 1.1, SVG 2 content may specify color using an ICC profile (see [ICC42]); an sRGB fallback must still be provided.

An SVG 2 User Agent searches the color profile description database for a color profile description entry whose name descriptor matches <name> and uses the last matching entry that is found; painting shall be done using the given ICC color, where the comma-separated list (with optional white space) of <icccolorvalue>’s is a set of ICC-profile-specific color values, expressed as <number>s (see ICC colors). If no match is found, then the fallback sRGB color is used.

If ICC-based colors are provided, an SVG 2 User Agent MUST use the ICC-based color in preference to the sRGB fallback color, unless the ICC color profile cannot be used (is unavailable, malformed, or uses an unsupported profile connection space).

When rendering, if both ICC and sRGB fallback colors are provided and the referenced ICC profile can be used, a SVG 2 User Agent MUST render using the ICC color values, using the specified ICC profile as the input profile.

### 3.4. LAB color

New in SVG 2.

<fallback> cielab(<Lightness>, <a> <b>) |
<fallback> cielchab(<Lightness> <Chroma>, <Hue> )

    <circle fill="#CD853F cielab(62.253188, 23.950124, 48.410653)"/>
    <circle fill="#CD853F cielch(62.253188, 54.011108, 63.677091)"/>

An SVG 2 User Agent directly uses the CIE LAB or CIE LCHab values, where the comma-separated list (with optional white space) of <icccolorvalue>’s is a set of Lightness, a and b or Lightness, Hue and Chroma values, expressed as <number>s. A color profile is not referenced in the SVG, although profile-based implementations may choose to implement this by providing and using an LAB profile.

The white point is D50, which is the whitepoint defined by the CIE for CIELab profile connection space and the whitepoint used for image editors that provide LAB functionality. LAB measurements relative to a different whitepoint should be adapted to D50 to be used in SVG 2; the linear Bradford chromatic adaptation transform [BRADFORD] is suggested for this.

If LAB-based colors are provided, an SVG 2 User Agent MUST use the LAB-based color in preference to the sRGB fallback color.

When rendering, if both LAB and sRGB fallback colors are provided, a SVG 2 User Agent MUST render using the ICC color values, using the specified ICC profile as the input profile.

A fallback sRGB color must still be provided, for non-color-managed user agents.

### 3.5. ICC named color

New in SVG 2.

<fallback> icc-named-color(<name>, <namedColor>)

Example:

    <style>
    @color-profile {
      name: FooColors;
      src: url(http://swatches.example.com/Foo);
    }
    </style>
    <circle fill="#CD853F icc-color(FooColors, Sandy23C)"/>

SVG 2 introduces the ability to specify a color using a 'Named Color Profile'.

An SVG 2 User Agent searches the color profile description database for a color profile description entry whose name descriptor matches <name> and uses the last matching entry that is found; painting shall be done using the given ICC color, where namedColor is a <string> indicating the named color to use.

This might need to be an <ident> rather than a <string>.

ICC named color profiles provide a platform- and implementation-neutral way to share a swatch of colors, or to use user-created names for colors.

If ICC-based named colors are provided, a conformant SVG 2 User Agent MUST use the ICC-based named color in preference to the sRGB fallback color, unless the ICC named color profile is unavailable, malformed, or uses a profile connection space other than CIE XYZ or CIE LAB.

When an ICC named color is used, a conformant SVG 2 User Agent shall render it in conformance with the specified ICC profile to obtain the desired color appearance.

## 4. Unmanaged colors

### 4.1. Uncalibrated device color

New in SVG 2.

<fallback> device-gray(<gray>) |
<fallback> device-rgb(<red> <green> <blue>) |
<fallback> device-cmyk(<cyan> <magenta> <yellow> <black>) |
<fallback> device-nchannel(<number>+) |

    <circle fill="#CD853F device-cmyk(0.11, 0.48, 0.83, 0.00)"/>

SVG 2 introduces a method of specifying uncalibrated device colors. This is sometimes useful in print workflows, for example to produce patches of known ink density used for quality control purposes.

An SVG 2 User Agent which supports the indicated class of output device will pass the values through without color management. If the class of output device (for example, cmyk) is not supported, then the fallback sRGB color is used.

As these are uncalibrated, any interpolation or compositing occurs using the fallback sRGB color value.

## 5. The effect of the color property

See the CSS Color Module Level 3 specification for the definition of color. [CSS3COLOR]

The color property is used to provide a potential indirect value, currentColor, for the fill, stroke, solid-color, stop-color, flood-color and lighting-color properties. The property has no other effect on SVG elements.

The following example shows how the inherited value of the color property from an HTML document can be used to set the color of SVG text in an inline SVG fragment.

    <!DOCTYPE html>
    <style>
    body { color: #468; font: 16px sans-serif }
    svg { border: 1px solid #888; background-color: #eee }
    </style>
    <p>Please see the diagram below:</p>
    <svg width="200" height="100">
      <g fill="currentColor">
        <text x="70" y="55" text-anchor="end">START</text>
        <text x="130" y="55">STOP</text>
        <path d="M 85,45 h 25 v -5 l 10,10 -10,10 v -5 h -25 z"/>
      </g>
    </svg>

Please see the diagram below:

The text and arrow in the SVG fragment are filled with the same color as the inherited color property.

## 6. Color profile descriptions

### 6.1. Overview of color profile descriptions

The International Color Consortium has established a standard, the ICC Profile [ICC32], for documenting the color characteristics of input and output devices. Using these profiles, it is possible to build a transform and correct visual data for viewing on different devices.

A color profile description provides the bridge between an ICC profile and references to that ICC profile within SVG content. The color profile description is added to the user agent’s list of known color profiles and then used to select the relevant profile. The color profile description contains descriptors for the location of the color profile on the Web, a name to reference the profile and information about rendering intent.

### 6.2. The CSS @color-profile rule

When the document is styled using CSS, the CSS @color-profile rule can be used to specify a color profile description. The general form is:

    @color-profile { <color-profile-description> }

where the <color-profile-description> has the form:

    descriptor: value;
    [...]
    descriptor: value;

Each @color-profile rule specifies a value for every color profile descriptor, either implicitly or explicitly. Those not given explicit values in the rule take the initial value listed with each descriptor in this specification. These descriptors apply solely within the context of the @color-profile rule in which they are defined, and do not apply to document language elements. Thus, there is no notion of which elements the descriptors apply to, or whether the values are inherited by child elements.

The following are the descriptors for a <color-profile-description>:

src

  Values: | sRGB | <local-profile> | <url> | (<local-profile> <url>)
  Initial: | sRGB
  Media: | visual

sRGB
  The source profile is the sRGB color space. For consistency with CSS lexical scanning and parsing rules ([CSS21], section G.2), the keyword "sRGB" is case-insensitive; however, it is recommended that the mixed capitalization "sRGB" be used for consistency with common industry practice.
<local-profile>

  The source profile is a locally-stored profile. The syntax for <local-profile> is:

      "local(" + <string> + ")"

  where <string> is the profile’s unique ID as specified by International Color Consortium. (Note: Profile description fields do not represent a profile’s unique ID. With current ICC proposals, the profile’s unique ID is an MD5-encoded value within the profile header.)

<url>
  The source profile is an URL reference to a color profile.
(<local-profile> <url>)
  Two profiles are specified. If <local-profile> cannot be found on the local system, then the <url> is used.

name

  Values: | <identifier>
  Initial: | undefined
  Media: | visual

<identifier>
  The name which is used as the first parameter for icc-color specifications within fill, stroke, stop-color, flood-color and lighting-color property values to identify the color profile to use for the ICC color specification. Note that if name is not provided, it will be impossible to reference the given @color-profile definition.

rendering-intent

  Values: | auto | perceptual | relative-colorimetric | saturation | absolute-colorimetric
  Initial: | auto
  Media: | visual
  Animatable: | no

The ‘rendering-intent’ descriptor permits the specification of a color profile rendering intent other than the default. ‘rendering-intent’ is applicable primarily to color profiles corresponding to CMYK color spaces. The different options cause different methods to be used for translating colors to the color gamut of the target rendering device:

auto
  This is the default behavior. The user agent determines the best intent based on the content type.
  For image content containing an embedded profile, the User Agent MUST use the intent specified within the profile. Otherwise, the user agent MUST use the current profile and force the intent, overriding any intent that might be stored in the profile itself.
perceptual

  This method is often the preferred choice for images, especially when there are substantial differences between the source and destination (such as a CRT display image reproduced on a reflection print). It takes the colors of the source image and re-optimizes the appearance for the destination medium using proprietary methods. This re-optimization may result in colors within both the source and destination gamuts being changed, although perceptual transforms are supposed to maintain the basic artistic intent of the original in the reproduction. They will not attempt to correct errors in the source image.

  With v2 ICC profiles there is no specified perceptual reference medium, which can cause interoperability problems. When v2 ICC profiles are used it may be safer to use the media-relative colorimetric rendering intent with black point compensation, instead of the perceptual rendering intent, unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.

  This method SHOULD maintain relative color values among the pixels as they are mapped to the target device gamut. This method MAY change pixel values that were originally within the target device gamut, in order to avoid hue shifts and discontinuities and to preserve as much as possible the overall appearance of the scene.
saturation

  This option was created to preserve the relative saturation (chroma) of the original, and to keep solid colors pure. However, it experienced interoperability problems like the perceptual intent, and as solid color preservation is not amenable to a reference medium solution using v4 profiles does not solve the problem. Use of this rendering intent is not recommended unless the specific source and destination profiles to be used have been checked to ensure the combination produces the desired result.

  This option SHOULD preserve the relative saturation (chroma) values of the original pixels. Out of gamut colors SHOULD be converted to colors that have the same saturation but fall just inside the gamut.
relative-colorimetric

  Media-relative colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the respective media white points. Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods.

  Note: the media-relative colorimetric rendering intent is often used with black point compensation, where the source medium black point is mapped to the destination medium black point as well.

  This method MUST map the source white point to the desination white point. If black point compensation is in use, the source black point MUST also be mapped to the destination black point. Adaptation algorithms SHOULD be used to adjust for the change in white point. Relative relationships of colors inside both source and destination gamuts SHOULD be preserved. Relative relationships of colors outside the destination gamut MAY be changed.
absolute-colorimetric

  ICC-absolute colorimetric is required to leave source colors that fall inside the destination medium gamut unchanged relative to the adopted white (a perfect reflecting diffuser). Source colors that are out of the destination medium gamut are mapped to colors on the gamut boundary using a variety of different methods. This method produces the most accurate color matching of in-gamut colors, but will result in highlight clipping if the destination medium white point is lower than the source medium white point. For this reason it is recommended for use only in applications that need exact color matching and where highlight clipping is not a concern.

  This method MUST disable white point matching and black point matching when converting colors.
  In general, this option is not recommended.

Fallback behaviour needs to be specified, for when the requested rendering intent does not have a corresponding table in the profile; or when all rendering-intents are provided using the same table.

## 7. Color syntax

The EBNF grammar syntax is as described in Syntax.

    icccolor ::=
      ~"icc-color(" name (comma-wsp number)+ ")"

    iccnamedcolor ::=
      ~"icc-named-color(" name comma-wsp namedColor ")"

    cielabcolor ::=
      ~"cielab(" lightness comma-wsp a-value comma-wsp b-value ")"

    cielchabcolor ::=
      ~"cielchab(" lightness comma-wsp chroma comma-wsp hue ")"

    devicecolor ::=
      device-gray | devicergb | devicecmyk | devicenchannel

    devicegray ::=
      ~"device-gray(" gray ")"

    devicergb ::=
      ~"device-rgb(" red green blue ")"

    devicecmyk ::=
      ~"device-cmyk(" cyan magenta yellow black ")"

    devicenchannel ::=
      ~"device-nchannel(" number+ ")"

    name ::=
      namestartchar (namechar)*

    lightness ::=
      number

    a-value ::=
      number

    b-value ::=
      number

    chroma ::=
      number

    hue ::=
      number

    gray ::=
      number

    red ::=
      number

    green ::=
      number

    blue ::=
      number

    cyan ::=
      number

    magenta ::=
      number

    yellow ::=
      number

    black ::=
      number

    namedColor ::=
      name

    fallback ::=
      color

    color  ::=
      "#" hexdigit hexdigit hexdigit (hexdigit hexdigit hexdigit)?
      | ~"rgb(" wsp* integer comma integer comma integer wsp* ")"
      | ~"rgb(" wsp* integer "%" comma integer "%" comma integer "%" wsp* ")"
      | ~"hsl(" wsp* integer comma integer comma integer wsp* ")"
      | ~"hsla(" wsp* integer comma integer comma integer comma integer wsp* ")"
      | color-keyword

    hexdigit ::=
      [0-9A-Fa-f]

    number ::=
      sign? digit-sequence? "." digit-sequence

    sign::=
      "+" | "-"

    integer ::=
      digit-sequence

    digit-sequence ::=
      [0-9]+

    namestartchar ::=
      ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [
      #xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] |
      [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] |
      [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]

    namechar ::=
      namestartchar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] |
      [#x203F-#x2040]

    comma ::=
      ","

    color-keyword ::=
      ~"aliceblue" | ~"antiquewhite" | ~"aqua" | ~"aquamarine" | ~"azure" | ~"beige" |
      ~"bisque" | ~"black" | ~"blanchedalmond" | ~"blue" | ~"blueviolet" | ~"brown" |
      ~"burlywood" |~"cadetblue" | ~"chartreuse" | ~"chocolate" | ~"coral" | ~"cornflowerblue" |
      ~"cornsilk" | ~"crimson" | ~"cyan" | ~"darkblue" | ~"darkcyan" | ~"darkgoldenrod" |
      ~"darkgray" | ~"darkgreen" | ~"darkgrey" | ~"darkkhaki" | ~"darkmagenta" | ~"darkolivegreen" |
      ~"darkorange" | ~"darkorchid" | ~"darkred" | ~"darksalmon" | ~"darkseagreen" | ~"darkslateblue" |
      ~"darkslategray" | ~"darkslategrey" | ~"darkturquoise" | ~"darkviolet" | ~"deeppink" | ~"deepskyblue" |
      ~"dimgray" | ~"dimgrey" | ~"dodgerblue" | ~"firebrick" | ~"floralwhite" | ~"forestgreen" |
      ~"fuchsia" | ~"gainsboro" | ~"ghostwhite" | ~"gold" | ~"goldenrod" | ~"gray" |
      ~"grey" | ~"green" | ~"greenyellow" | ~"honeydew" | ~"hotpink" | ~"indianred" |
      ~"indigo" | ~"ivory" | ~"khaki" | ~"lavender" | ~"lavenderblush" | ~"lawngreen" |
      ~"lemonchiffon" | ~"lightblue" | ~"lightcoral" | ~"lightcyan" | ~"lightgoldenrodyellow" | ~"lightgray" |
      ~"lightgreen" | ~"lightgrey" | ~"lightpink" | ~"lightsalmon" | ~"lightseagreen" | ~"lightskyblue" |
      ~"lightslategray" | ~"lightslategrey" | ~"lightsteelblue" | ~"lightyellow" | ~"lime" |
      ~"limegreen" | ~"linen" | ~"magenta" | ~"maroon" | ~"mediumaquamarine" | ~"mediumblue" |
      ~"mediumorchid" | ~"mediumpurple" | ~"mediumseagreen" | ~"mediumslateblue" | ~"mediumspringgreen" |
      ~"mediumturquoise" | ~"mediumvioletred" | ~"midnightblue" | ~"mintcream" | ~"mistyrose" |
      ~"moccasin" | ~"navajowhite" | ~"navy" | ~"oldlace" | ~"olive" | ~"olivedrab" | ~"orange" | ~"orangered" |
      ~"orchid" | ~"palegoldenrod" | ~"palegreen" | ~"paleturquoise" | ~"palevioletred" | ~"papayawhip" |
      ~"peachpuff" | ~"peru" | ~"pink" | ~"plum" | ~"powderblue" | ~"purple" |
      ~"red" | ~"rosybrown" | ~"royalblue" | ~"saddlebrown" | ~"salmon" | ~"sandybrown" |
      ~"seagreen" | ~"seashell" | ~"sienna" | ~"silver" | ~"skyblue" | ~"slateblue" |
      ~"slategray" | ~"slategrey" | ~"snow" | ~"springgreen" | ~"steelblue" | ~"tan" |
      ~"teal" | ~"thistle" | ~"tomato" | ~"turquoise" | ~"violet" | ~"wheat" |
      ~"white" | ~"whitesmoke" | ~"yellow" | ~"yellowgreen"

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

## Index

https://drafts.csswg.org/css-color-4/#propdef-color Referenced in:

- 5. The effect of the color property (2) (3) (4) (5)

https://drafts.csswg.org/css-color-4/#descdef-color-profile-rendering-intent Referenced in:

- 6.2. The CSS @color-profile rule

https://drafts.csswg.org/css-color-4/#descdef-color-profile-src Referenced in:

- 6.2. The CSS @color-profile rule

https://drafts.csswg.org/css-values-3/#number-value Referenced in:

- 3.3. ICC colors
- 3.4. LAB color

https://drafts.csswg.org/css-values-3/#url-value Referenced in:

- 6.2. The CSS @color-profile rule (2) (3) (4) (5)

https://fetch.spec.whatwg.org/#concept-headers-fill Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://drafts.fxtf.org/fill-stroke-3/#propdef-fill Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://drafts.fxtf.org/fill-stroke-3/#propdef-stroke Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://drafts.fxtf.org/filter-effects-1/#propdef-flood-color Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://drafts.fxtf.org/filter-effects-1/#propdef-lighting-color Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://svgwg.org/svg2-draft/painting.html#ColorInterpolationProperty Referenced in:

- 1. Introduction

https://svgwg.org/svg2-draft/pservers.html#StopColorProperty Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://svgwg.org/svg2-draft/painting.html#TermStroke Referenced in:

- 5. The effect of the color property
- 6.2. The CSS @color-profile rule

https://svgwg.org/svg2-draft/linking.html#TermURLReference Referenced in:

- 6.2. The CSS @color-profile rule

### Terms defined by reference

- [css-color-4] defines the following terms:
  - color
  - rendering-intent
  - src
- [css-values-3] defines the following terms:
  - <number>
  - <url>
- [FETCH] defines the following terms:
  - fill
- [fill-stroke-3] defines the following terms:
  - fill
  - stroke
- [filter-effects-1] defines the following terms:
  - flood-color
  - lighting-color
- [SVG2] defines the following terms:
  - color-interpolation
  - stop-color
  - stroke
  - url reference

## References

### Normative References

[CSS-COLOR-4]
  Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 5 March 2019. WD. URL: https://www.w3.org/TR/css-color-4/
[CSS-VALUES-3]
  Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3. 31 January 2019. CR. URL: https://www.w3.org/TR/css-values-3/
[FETCH]
  Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[FILL-STROKE-3]
  Elika Etemad; Tab Atkins Jr.. CSS Fill and Stroke Module Level 3. 13 April 2017. WD. URL: https://www.w3.org/TR/fill-stroke-3/
[FILTER-EFFECTS-1]
  Dirk Schulze; Dean Jackson. Filter Effects Module Level 1. 18 December 2018. WD. URL: https://www.w3.org/TR/filter-effects-1/
[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/

## Issues Index

Define processing for untagged greyscale and CMYK images. Could be a default profile, or an 'explicitly undefined' with a warning to avoid untagged non-RGB images when authoring. ↵
References to "SVG 2 User Agent" might need to be replaced with one of the conformance classes listed in the Conformance appendix. ↵
Define 'permitted fallback situation' and link to it. ↵
This grammar doesn’t match the grammar below. Also the ones below should be translated from EBNF to CSS Value syntax. ↵
This might need to be an <ident> rather than a <string>. ↵
Fallback behaviour needs to be specified, for when the requested rendering intent does not have a corresponding table in the profile; or when all rendering-intents are provided using the same table. ↵