# CSS Images Module Level 4

## Editor’s Draft, 1 January 1970

Specification Metadata

This version:
  https://drafts.csswg.org/css-images-4/
Latest published version:
  https://www.w3.org/TR/css4-images/
Previous Versions:
  https://www.w3.org/TR/2012/WD-css4-images-20120911/
Issue Tracking:
  Tracker
  GitHub Issues
Editors:
  Tab Atkins Jr. (Google)
  Elika J. Etemad / fantasai (Invited Expert)
  Lea Verou (Invited Expert)
Suggest an Edit for this Spec:
  GitHub Editor

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

## Abstract

This module contains the features of CSS level 4 relating to the <image> type and replaced elements. It includes and extends the functionality of CSS level 2 [CSS21] and in the previous level of this specification [css3-images]. The main extensions compared to "CSS Images Module Level 3" [css3-images] are several additions to the <image> type, such as the image() notation, the element() notation, and conic gradients.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, etc.

## Status of this document

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

GitHub Issues are preferred for discussion of this specification. When filing an issue, please put the text “css-images” in the title, preferably like this: “[css-images] …summary of comment…”. All issues and comments are archived, and there is also a historical archive.

This document was produced by the CSS Working Group.

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

This document is governed by the 1 March 2019 W3C Process Document.

## 1. Introduction

This section is not normative.

This module introduces additional ways of representing 2D images, for example as a URL with color fallback, as conic gradients, or as the rendering of another element in the document.

## 2. 2D Image Values: the <image> type

The <image> value type denotes a 2D image. It can be a url reference, image notation, or gradient notation. Its syntax is:

    <image> = <url> | <image()> | <image-set()> | <cross-fade()> | <gradient>

An <image> can be used in many CSS properties, including the background-image, list-style-image, cursor properties [CSS21] (where it replaces the <url> component in the property’s value).

In some cases an image is invalid, such as a <url> pointing to a resource that is not a valid image format or that has failed to load. An invalid image is rendered as a solid-color transparent image with no intrinsic dimensions. However, invalid images can trigger error-handling clauses in some contexts. For example, an invalid image in list-style-image is treated as none, allowing the list-style-type to render in its place. [CSS2]

While an image is loading, is is a loading image. Loading images are not invalid images, but have similar behavior: they are rendered as a solid-color transparent image with no intrinsic dimensions, and may trigger fallback rendering in contexts that offer it, but must not trigger loading of fallback resources. Alternately, if a loading image happens to be replacing an already-loaded image (for example due to changes in the document or style sheet) and the UA is tracking this information, it may continue to render the already-loaded image in place of the loading image.

Partially-loaded images (whose intrinsic dimensions are known, but whose image data is not fully loaded) may be either treated as loading images or as loaded images rendered with partial data. For example, a UA may render an interlaced GIF in place as soon as its first pass of pixel data has loaded or even as soon as the image header (which contains sizing data) has parsed and refresh the rendering as more data loads; or it may wait until the entire image has loaded before using it.

A computed <image> value is the specified value with any <url>s, <color>s, and <length>s computed.

### 2.1. Image File Formats

At minimum, the UA must support the following image file formats when referenced from an <image> value, for all the properties in which using <image> is valid:

- PNG, as specified in [PNG]
- SVG, as specified in [SVG11], using the secure static mode (See [SVG-INTEGRATION])
- If the UA supports animated <image>s, SVG, as specified in [SVG11], using the secure animated mode (See [SVG-INTEGRATION])

The UA may support other file formats as well.

### 2.2. Image References: the url() notation

Note: No change from [css3-images].

### 2.3. Resolution Negotiation: the image-set() notation

Delivering the most appropriate image resolution for a user’s device can be a difficult task. Ideally, images should be in the same resolution as the device they’re being viewed in, which can vary between users. However, other factors can factor into the decision of which image to send; for example, if the user is on a slow mobile connection, they may prefer to receive lower-res images rather than waiting for a large proper-res image to load. The image-set() function allows an author to ignore most of these issues, simply providing multiple resolutions of an image and letting the UA decide which is most appropriate in a given situation.

This solution assumes that resolution is a proxy for filesize, and therefore doesn’t appropriately handle multi-resolution sets of vector images, or mixing vector images with raster ones (e.g. for icons). For example, use a vector for high-res, pixel-optimized bitmap for low-res, and same vector again for low-bandwidth (because it’s much smaller, even though it’s higher resolution).

The syntax for image-set() is:

    image-set() = image-set( <image-set-option># )
    <image-set-option> = [ <image> | <string> ] <resolution>

We should add "w" and "h" dimensions as a possibility, and a "format()" function, to match the functionality of HTML’s picture.

The image-set() function can not be nested inside of itself, either directly or indirectly (as an argument to another <image> type).

Is this restriction needed?

Each <string> inside image-set() represents a <url>.

Every <image-set-option> in a given image-set() must have a different <resolution>, or else the function is invalid.

UAs must make a UA-specific choice of which <image-set-option> to load, based on whatever criteria they find relevant (such as the resolution of the display, connection speed, etc). The image-set() then represents the image associated with the URL of that choice. The image’s intrinsic resolution is the resolution associated with that choice. UAs may change which <image-set-option> they wish to use for a given image-set() over the lifetime of the page, if the criteria used to determine which option to choose change significantly enough to make it worthwhile in the UA’s estimation.

This example shows how to use image-set() to provide an image in three versions: a "normal" version, a "high-res" version, and an extra-high resolution version for use in high-quality printing (as printers can have extremely high resolution):

    background-image: image-set( "foo.png" 1x,
                                 "foo-2x.png" 2x,
                                 "foo-print.png" 600dpi );

### 2.4. Image Fallbacks and Annotations: the image() notation

The image() function allows an author to:

- use media fragments to clip out a portion of an image

- use a solid color as an image

- fallback to a solid-color image, when the image at the specified url can’t be downloaded or decoded

- automatically respect the image orientation specified in the image’s metadata

The image() notation is defined as:

    image() = image( <image-tags>? [ <image-src>? , <color>? ]! )
    <image-tags> = [ ltr | rtl ]
    <image-src> = [ <url> | <string> ]

A <string> used in image() represents a <url>. As usual for URLs in CSS, relative URLs are resolved to an absolute URL (as described in Values & Units [css-values-3]) when a specified image() value is computed.

If the image has an orientation specified in its metadata, such as EXIF, the UA must rotate or flip the image to correctly orient it as the metadata specifies.

#### 2.4.1. Image Fallbacks

If both a URL and a <color> are specified in image(), then whenever the URL represents an invalid image or loading image, the image() function renders as if the URL were not specified at all; it generates a solid-color image as specified in § 2.4.3 Solid-color Images.

If just a URL is specified (no <color>) and it represents an invalid image or loading image, the image() function represents the same.

The fallback color can be used to ensure that text is still readable even when the image fails to load. For example, the following legacy code works fine if the image is rectangular and has no transparency:

    body      { color: black; background: white; }
    p.special { color: white; background: url("dark.png") black; }

When the image doesn’t load, the background color is still there to ensure that the white text is readable. However, if the image has some transparency, the black will be visible behind it, which is probably not desired. The image() function addresses this:

    body      { color: black; background: white; }
    p.special { color: white; background: image("dark.png", black); }

Now, the black won’t show at all if the image loads, but if for whatever reason the image fails, it’ll pop in and prevent the white text from being set against a white background.

#### 2.4.2. Image Fragments

When a URL specified in image() represents a portion of a resource (e.g. by the use of media fragment identifiers) that portion is clipped out of its context and used as a standalone image.

For example, given the following image and CSS:

    background-image: image('sprites.svg#xywh=40,0,20,20')

...the background of the element will be the portion of the image that starts at (40px,0px) and is 20px wide and tall, which is just the circle with a quarter filled in.

So that authors can take advantage of CSS’s forwards-compatible parsing rules to provide a fallback for image slices, implementations that support the image() notation must support the `xywh=#,#,#,#` form of media fragment identifiers for images specified via image(). [MEDIA-FRAGS]

Note that image fragments can also be used with the url() notation. However, a legacy UA that doesn’t understand the media fragments notation will ignore the fragment and simply display the entirety of the image.

Since the image() notation requires UAs to support media fragments, authors can take advantage of CSS’s forward-compatible parsing rules to provide a fallback when using an image fragment URL:

    background-image: url('swirl.png'); /* old UAs */
    background-image: image('sprites.png#xywh=10,30,60,20'); /* new UAs */

If a URL uses a fragment identifier syntax that the implementation does not understand, or does not consider valid for that type of image, the URL must be treated as representing an invalid image.

Note: This error-handling is limited to image(), and not in the definition of URL, for legacy compat reasons.

#### 2.4.3. Solid-color Images

If the image() function is specified with only a <color> argument (no URL), it represents a solid-color image of the specified color with no intrinsic dimensions.

For example, one can use this as a simple way to "tint" a background image, by overlaying a partially-transparent color over the top of the other image:

    background-image: image(rgba(0,0,255,.5)), url("bg-image.png");

background-color does not work for this, as the solid color it generates always lies beneath all the background images.

#### 2.4.4. Bidi-sensitive Images

Before listing any `<image-src>s`, the author may specify a directionality for the image, similar to adding a `dir` attribute to an element in HTML. If a directional image is used on or in an element with opposite direction, the image must be flipped in the inline direction (as if it was transformed by, e.g., `scaleX(-1)`, if the inline direction is the X axis).

Note: Absent this declaration, images default to no directionality at all, and thus don’t care about the directionality of the surrounding element.

A list may use an arrow for a bullet that points into the content. If the list can contain both LTR and RTL text, though, the bullet may be on the left or the right, and an image designed to point into the text on one side will point out of the text on the other side. This can be fixed with code like:

    <ul style="list-style-image: image(ltr 'arrow.png');">
      <li dir='ltr'>My bullet is on the left!</li>
      <li dir='rtl'>MY BULLET IS ON THE RIGHT!</li>
    </ul>

This should render something like:

    ⇒ My bullet is on the left!
      !THGIR EHT NO SI TELLUB YM ⇐

In LTR list items, the image will be used as-is. In the RTL list items, however, it will be flipped in the inline direction, so it still points into the content.

### 2.5. Combining images: the cross-fade() notation

When transitioning between images, CSS requires a way to explicitly refer to the intermediate image that is a combination of the start and end images. This is accomplished with the cross-fade() function, which indicates the two images to be combined and how far along in the transition the combination is.

Note: Authors can also use the cross-fade() function for many simple image manipulations, such as tinting an image with a solid color or highlighting a particular area of the page by combining an image with a radial gradient.

The syntax for cross-fade() is defined as:

    cross-fade() = cross-fade( <cf-image># )
    <cf-image> = <percentage>? && [ <image> | <color> ]

The function represents an image generated by combining two or more images.

The <percentage> represents how much of each image is retained when it is blended with the other images. The <percentage> must be between 0% and 100% inclusive; any other value is invalid.

If any percentages are omitted, all the specified percentages are summed together and subtracted from 100%, the result is floored at 0%, then divided equally between all images with omitted percentages at computed-value time.

While this is not reflected in the computed value, when all the arguments’ percentages sum to greater than 100%, the sizing/painting details effectively rescale them so that they sum to exactly 100%.

On the other hand, when the sum is less than 100%, the sizing/painting details effectively act like there’s an additional transparent argument, with its percentage set to the remaining value necessary to make the sum equal 100%.

If a <color> is provided, it represents a solid-color image with “automatic” dimensions (it doesn’t participate in the sizing of the result image at all; see details in the sizing details below).

#### 2.5.1. cross-fade() Sizing

The dimensions of the image represented by a cross-fade() are a weighted average of dimensions of the <image> arguments to the function; the <color> arguments have no effect. They are calculated as follows:

To determine the intrinsic dimensions of a cross-fade():

1. Let images be an empty list.

2. For each argument of the cross-fade() function with an <image> value:

   1. Let item be a tuple consisting of a width, a height, and a percentage.

   2. Run the object size negotiation algorithm for the <image>, as appropriate for the context in which the cross-fade() appears, and set item’s width and height to the width and height of the resulting concrete object size.

   3. Set item’s percentage to the argument’s percentage.

3. If images is empty, return no intrinsic dimensions.

4. Let percentage sum be the sum of all the percentages of the items in images.

5. For each item in images, divide item’s percentage by percentage sum, and set item’s percentage to the result.

   Assert: The percentages in images now sum to 100%.

6. Let final width and final height be 0px.

7. For each item in images, multiply item’s width by item’s percentage and add the result to final width, and multiply item’s height by item’s percentage and add the result to final height.

8. Return an intrinsic width of final width and an intrinsic height of final height.

#### 2.5.2. cross-fade() Painting

The image represented by a cross-fade() is a weighted average of the input arguments to the function, calculated as follows:

To determine the appearance of a cross-fade():

1. Let images be an empty list.

2. Let size be a tuple of width and height, initialized to the result of finding the concrete object size of the cross-fade() function (using the intrinsic dimensions of a cross-fade()).

3. For each argument of the cross-fade() function:

   1. Let item be a tuple consisting of an image and a percentage.

   2. If argument has an <image>, rescale it to size’s width and height and set item’s image to the result. Otherwise, argument has a <color>; set item’s image to a solid-color image of the <color>, with size’s dimensions.

   3. Set item’s percentage to the argument’s percentage.

4. Let percentage sum be the sum of all the percentages of the items in images.

5. If percentage sum is less than 100%, append a tuple to images consisting of a solid-color transparent-black image with size’s dimensions, and a percentage equal to 100% minus percentage sum.

   Otherwise, if percentage sum is greater than 100%, then for each item in images, divide item’s percentage by percentage sum, and set item’s percentage to the result.

6. Let final image be an image with size’s dimensions, and every pixel being the weighted linear average of the corresponding pixels of each item’s image in images, weighted according to the item’s percentage. (Average both the color channels and the alpha channel of the pixels.) For the purpose of this calculation, each pixel’s color must be in pre-multiplied sRGB.

   Details on the above operation

   This is applying an N-way Porter-Duff `dissolve` operation to the source images. Wikipedia defines `dissolve` as a stochastic operation, with the result pixels independently randomly chosen from the source images’ corresponding pixels according to their source images’ weights, but as pixels shrink to infinitely small, this converges to doing color-averaging in pre-multiplied color space.

   In particular, this means that `cross-fade(white 50%, transparent 50%)` will produce a partially-transparent solid white image. (Rather than a partially-transparent gray, which is what you’d get if you averaged the opaque white and transparent black pixels in non-premultiplied space.)

   As converting to pre-multiplied does entail some loss of precision, and graphics libraries may or may not support this operation natively, as per usual any method can be used so long as it achieves the specified effect.

   For example, one can instead rebalance the percentages according to the alphas of each pixel, then do the color-channel averages in non-premultiplied space. E.g., to render cross-fade(rgb(255 0 0 / 1) 40%, rgb(0 255 0 / .5) 20%, rgb(0 0 255 / 0) 40%), rebalancing the percentages according to the 1 / .5 / 0 alphas would produce 40% / 10% / 0% (which renormalizes to 80% / 20% / 0%), at which point you can average the raw color channel values and end up with an rgb(204 51 0 / .5) image. (Note that the alpha channel is still averaged using the original percentages, not the rebalanced ones.)

7. Return final image.

#### 2.5.3. Simplifying Complex cross-fade()

Per WG resolution, define a notion of "equality" for images, and combine "same" images at computed-value time, summing their percentages.

Per WG resolution, simplify directly-nested cross-fade() at computed-value time by just distributing the percentage and flattening; cross-fade(A 10%, cross-fade(B 30%, C 70%) 90%) becomes cross-fade(A 10%, B 27%, C 63%).

### 2.6. Using Elements as Images: the element() notation

The element() function allows an author to use an element in the document as an image. As the referenced element changes appearance, the image changes as well. This can be used, for example, to create live previews of the next/previous slide in a slideshow, or to reference a canvas element for a fancy generated gradient or even an animated background.

Note: The element() function only reproduces the appearance of the referenced element, not the actual content and its structure. Authors should only use this for decorative purposes, and must not use element() to reproduce an element with significant content across the page. Instead, just insert multiple copies of the element into the document.

The syntax for element() is:

    element() = element( <id-selector> )

where <id-selector> is an ID selector [SELECT].

Do we need to be able to refer to elements in external documents (such as SVG paint servers)? Or is it enough to just use url() for this?

This name conflicts with a somewhat similar function in GCPM. This needs to be resolved somehow.

Want the ability to do "reflections" of an element, either as a background-image on the element or in a pseudo-element. This needs to be specially-handled to avoid triggering the cycle-detection.

When we have overflow:paged, how can we address a single page in the view?

The element() function references the element matched by its argument. The ID is first looked up in the elementSources map, as described in that section. If it’s not found, it’s then matched against the document. If multiple elements are matched, the function references the first such element.

The image represented by the element() function can vary based on whether the element is visible in the document:

an element that is rendered, is not a descendant of a replaced element, and generates a stacking context
  The function represents an image with its intrinsic size equal to the decorated bounding box of the referenced element:
  - for an element rendered using a CSS rendering model, the decorated bounding box is the smallest axis-aligned rectangle that contains the border image areas of all the fragments of the principal box
  - for an element rendered using the SVG rendering model, the decorated bounding box is defined by SVG

  Note: Because images clip anything outside their bounds by default, this means that decorations that extend outside the decorated bounding box, like box shadows, may be clipped.

  The image is constructed by rendering the referenced element and its descendants (at the same size that they would be in the document) over an infinite transparent canvas, positioned so that the edges of the decorated bounding box are flush with the edges of the image.

  Requiring some degree of stacking context on the element appears to be required for an efficient implementation. Do we need a full stacking context, or just a pseudo-stacking context? Should it need to be a stacking context normally, or can we just render it as a stacking context when rendering it to element()?

  If the referenced element has a transform applied to it or an ancestor, the transform must be ignored when rendering the element as an image. [CSS3-TRANSFORMS]

  If the referenced element is broken across pages, the element is displayed as if the page content areas were joined flush in the pagination direction, with pages' edges corresponding to the initial containing block’s start edge aligned. Elements broken across lines or columns are just rendered with their decorated bounding box.

  Implementations may either re-use existing bitmap data generated for the referenced element or regenerate the display of the element to maximize quality at the image’s size (for example, if the implementation detects that the referenced element is an SVG fragment); in the latter case, the layout of the referenced element in the image must not be changed by the regeneration process. That is, the image must look identical to the referenced element, modulo rasterization quality.

  As a somewhat silly example, a `p` element can be reused as a background elsewhere in the document:

      <style>
      #src { color: white; background: lime; width: 300px; height: 40px; position: relative; }
      #dst { color: black; background: element(#src); padding: 20px; margin: 20px 0; }
      </style>
      <p id='src'>I’m an ordinary element!</p>
      <p id='dst'>I’m using the previous element as my background!</p>

an element that is not rendered, but which provides a paint source
  The function represents an image with the intrinsic size and appearance of the paint source. The host language defines the size and appearance of paint sources.
  For example, the element() function can reference an SVG `<pattern>` element in an HTML document:

      <!DOCTYPE html>
      <svg>
        <defs>
          <pattern id='pattern1'>
            <path d='...'>
          </pattern>
        </defs>
      </svg>
      <p style="background: element(#pattern1)">
        I’m using the pattern as a background!
        If the pattern is changed or animated,
        my background will be updated too!
      </p>

  HTML also defines that a handful of elements, such as `canvas`, `img`, and `video`, provide a paint source. This means that CSS can, for example, reference a canvas that’s being drawn into, but not displayed in the page:

      <!DOCTYPE html>
      <script>
        var canvas = document.querySelector('#animated-bullet');
        canvas.width = 20; canvas.height = 20;
        drawAnimation(canvas);
      </script>
      <canvas id='animated-bullet' style='display:none'></canvas>
      <ul style="list-style-image: element(#animated-bullet);">
        <li>I’m using the canvas as a bullet!</li>
        <li>So am I!</li>
        <li>As the canvas is changed over time with Javascript,
            we’ll all update our bullet image with it!</li>
      </ul>

anything else

  The function represents an invalid image.

  For example, all of the following element() uses will result in a transparent background:

      <!DOCTYPE html>
      <p id='one' style="display:none; position: relative;">one</p>
      <iframe src="http://example.com">
        <p id='two' style="position: relative;">I’m fallback content!</p>
      </iframe>
      <ul>
        <li style="background: element(#one);">
          A display:none element isn’t rendered, and a P element
          doesn’t provide a paint source.
        </li>
        <li style="background: element(#two);">
          The descendants of a replaced element like an IFRAME
          can’t be used in element() either.
        </li>
        <li style="background: element(#three);">
          There’s no element with an id of "three", so this also
          gets rendered as a transparent image.
        </li>
      </ul>

An element is not rendered if it does not have an associated box. This can happen, for example, if the element or an ancestor is display:none. Host languages may define additional ways in which an element can be considered not rendered; for example, in SVG, any descendant of a `<defs>` element is considered to be not rendered.

The element() function can be put to many uses. For example, it can be used to show a preview of the previous or next slide in a slideshow:

    <!DOCTYPE html>
    <script>
    function navigateSlides() {
      var currentSlide = ...;
      document.querySelector('#prev-slide').id = '';
      document.querySelector('#next-slide').id = '';
      currentSlide.previousElementSibling.id = 'prev-slide';
      currentSlide.nextElementSibling.id = 'next-slide';
    }
    </script>
    <style>
    .slide {
      /* Need to be a stacking context to be element()-able. */
      position: relative;
    }
    #prev-preview, #next-preview {
      position: fixed;
      ...
    }
    #prev-preview { background: element(#prev-slide); }
    #next-preview { background: element(#next-slide); }
    </style>
    <a id='prev-preview'>Previous Slide</a>
    <a id='next-preview'>Next Slide</a>
    <section class='slide'>...</section>
    <section class='slide current-slide'>...</section>
    ...

In this example, the `navigateSlides` function updates the ids of the next and previous slides, which are then displayed in small floating boxes alongside the slides. Since you can’t interact with the slides through the element() function (it’s just an image), you could even use `click` handlers on the preview boxes to help navigate through the page.

#### 2.6.1. Paint Sources

Host languages may define that some elements provide a paint source. Paint sources have an intrinsic appearance and can obtain a concrete object size without having to do layout or rendering, and so may be used as images even when they’re not rendered.

In HTML, the `img`, `video`, and `canvas` elements provide paint sources.

In SVG, any element that provides a paint server provides a paint source. Note: In SVG1.1, the `<linearGradient>`, `<radialGradient>`, and `<pattern>` elements provide paint sources. They are drawn as described in the spec, with the coordinate systems defined as follows:

objectBoundingBox
  The coordinate system has its origin at the top left corner of the rectangle defined by the concrete object size that it’s being drawn into, and the same width and height as the concrete object size. A single user coordinate is the width and height of the concrete object size.
userSpaceOnUse
  The coordinate system has its origin at the top left corner of the rectangle defined by the concrete object size that it’s being drawn into, and the same width and height as the concrete object size. User coordinates are sized equivalently to the CSS px unit.

Note: It is expected that a future version of this module will define ways to refer to paint sources in external documents, or ones that are created solely by script and never inserted into a document at all.

#### 2.6.2. Using Out-Of-Document Sources: the `ElementSources` interface

The element() function normally selects elements within a document, but elements that provide a paint source don’t necessarily need to be in-document. For example, an HTML `canvas` element can be created, maintained, and drawn into entirely in script, with no need for it to be inserted into the document directly.

All that’s needed is a way to refer to the element, as an ID selector cannot select elements outside of the document. The elementSources Map object provides this.

    partial namespace CSS {
      [SameObject] readonly attribute any elementSources;
    };

Any entries in the elementSources map with a string key and a value that is an object providing a paint source are made available to the element() function.

Whenever element() uses an <id-selector>, the ID’s value (without the leading `#` character) is first looked up in the elementSources map:

- If it’s found, and the object associated with it provides a paint source, the element() function represents that paint source.
- If it’s found, but the object associated with it doesn’t provide a paint source, the element() function represent an invalid image.
- If the ID isn’t found in the map at all, it’s then looked for in the document as normal.

This reuse of the ID selector matches Moz behavior. I’m trying to avoid slapping a <custom-ident> right in the beginning of the grammar, as that eats too much syntax-space. Another possibility, though, is to start the value with a language-defined keyword followed by a <custom-ident>, like element(external fancy) or something. Naming suggestions welcome.

For example, fancy animating backgrounds can be done with an external canvas:

    <script>
    var bg = document.createElement('canvas');
    bg.height = 200;
    bg.width = 1000;
    drawFancyBackground(bg);
    CSS.elementSources.set('fancy', bg);
    </script>
    <style>
    h1 {
      background-image: element(#fancy);
    }
    </style>

As the "fancy" canvas is drawn into and animated, the backgrounds of all the H1 elements will automatically update in tandem.

Note that the elementSources map is consulted before the document to match the ID selector, so even if there’s an element in the document that would match #fancy, the backgrounds will still predictably come from the elementSources value instead.

#### 2.6.3. Cycle Detection

The element() function can produce nonsensical circular relationships, such as an element using itself as its own background. These relationships can be easily and reliably detected and resolved, however, by keeping track of a dependency graph and using common cycle-detection algorithms.

The dependency graph consists of edges such that:

- every element depends on its children
- for any element A with a property using the element() function pointing to an element B, A depends on B
- if a host language defines a way for elements to refer to the rendering of other elements, the referencing element depends on the referenced element. For example, in SVG, a `<use>` element depends on the element it referenced.

If the graph contains a cycle, any element() functions participating in the cycle are invalid images.

## 3. Gradients

A gradient is an image that smoothly fades from one color to another. These are commonly used for subtle shading in background images, buttons, and many other things. The gradient functions described in this section allow an author to specify such an image in a terse syntax, so that the UA can generate the image automatically when rendering the page. The syntax of a <gradient> is:

    <gradient> = [
      <linear-gradient()> | <repeating-linear-gradient()> |
      <radial-gradient()> | <repeating-radial-gradient()> |
      <conic-gradient()>  | <repeating-conic-gradient()> ]

As with the other <image> types defined in this specification, gradients can be used in any property that accepts images. For example:

- `background: linear-gradient(white, gray);`
- `list-style-image: radial-gradient(circle, #006, #00a 90%, #0000af 100%, white 100%)`

A gradient is drawn into a box with the dimensions of the concrete object size, referred to as the gradient box. However, the gradient itself has no intrinsic dimensions.

For example, if you use a gradient as a background, by default the gradient will draw into a gradient box the size of the element’s padding box. If background-size is explicitly set to a value such as 100px 200px, then the gradient box will be 100px wide and 200px tall. Similarly, for a gradient used as a list-style-image, the box would be a 1em square, which is the default object size for that property.

Gradients are specified by defining the starting point and ending point of a gradient line (which, depending on the type of gradient, may be technically a line, or a ray, or a spiral), and then specifying colors at points along this line. The colors are smoothly blended to fill in the rest of the line, and then each type of gradient defines how to use the color of the gradient line to produce the actual gradient.

### 3.1. Linear Gradients: the linear-gradient() notation

Note: No change from [css3-images].

### 3.2. Radial Gradients: the radial-gradient() notation

Note: No change from [css3-images].

### 3.3. Conic Gradients: the conic-gradient() notation

A conic gradient starts by specifying the center of a circle, similar to radial gradients, except that conic gradient color-stops are placed around the circumference of the circle, rather than on a line emerging from the center, causing the color to smoothly transition as you spin around the center, rather than as you progress outward from the center.

A conic gradient is specified by indicating a rotation angle, the center of the gradient, and then specifying a list of color-stops. Unlike linear and radial gradients, whose color-stops are placed by specifying a <length>, the color-stops of a conic gradient are specified with an <angle>. Rays are then drawn emerging from the center and pointing in all directions, with the color of each ray equal to the color of the gradient-line where they intersect it.

Note: These gradients are called "conic" or "conical" because, if the color stops are chosen to be significantly lighter on one side than the other, it produces a pattern that looks like a cone observed from above. They are also known as "angle" gradients in some contexts, since they are produced by varying the rotation angle of a ray.

This example visually illustrates how conic-gradient(at 25% 30%, white, black 60%) would be drawn. Note that since color stop positions always resolve to angles, the only effect of the at 25% 30% is a 2D translation of the gradient, i.e. it does not affect how the gradient is drawn.

#### 3.3.1. conic-gradient() Syntax

The syntax for a conic gradient is:

    conic-gradient() = conic-gradient(
      [ from <angle> ]? [ at <position> ]?,
      <angular-color-stop-list>
    )

The arguments are defined as follows:

<angle>
  The entire gradient is rotated by this angle. If omitted, defaults to 0deg. The unit identifier may be omitted if the <angle> is zero.
<position>
  Determines the gradient center of the gradient. The <position> value type (which is also used for background-position) is defined in [css-values-3], and is resolved using the center-point as the object area and the gradient box as the positioning area. If this argument is omitted, it defaults to center.

Usually in conic gradients the sharp transition at 0deg is undesirable, which is typically avoided by making sure the first and last color stops are the same color. Perhaps it would be useful to have a keyword for automatically achieving this.

Would a radius (inner & outer) for clipping the gradient be useful? If so, we could also support lengths in color stop positions, since we now have a specific radius.

Are elliptical conic gradients useful? Do graphics libraries support them?

#### 3.3.2. Placing Color Stops

Color stops are placed on a gradient line that curves around the gradient center in a circle, with both the 0% and 100% locations at 0deg. Just like linear gradients, 0deg points to the top of the page, and increasing angles correspond to clockwise movement around the circle.

Note: It may be more helpful to think of the gradient line as forming a spiral, where only the segment from 0deg to 360deg is rendered. This avoids any confusion about "overlap" when you have angles outside of the rendered region.

A color-stop can be placed at a location before 0% or after 100%; though these regions are never directly consulted for rendering, color stops placed there can affect the color of color-stops within the rendered region through interpolation or repetition (see repeating gradients). For example, conic-gradient(red -50%, yellow 150%) produces a conic gradient that starts with a reddish-orange color at 0deg (specifically, #f50), and transitions to an orangish-yellow color at 360deg (specifically, #fa0).

The color of the gradient at any point is determined by first finding the unique ray anchored at the center of the gradient that passes through the given point. The point’s color is then the color of the gradient line at the location where this ray intersects it.

#### 3.3.3. Conic Gradient Examples

All of the following conic-gradient() examples are presumed to be applied to a box that is 300px wide and 200px tall, unless otherwise specified.

Below are various ways of specifying the same basic conic gradient:

    background: conic-gradient(#f06, gold);
    background: conic-gradient(at 50% 50%, #f06, gold);
    background: conic-gradient(from 0deg, #f06, gold);
    background: conic-gradient(from 0deg at center, #f06, gold);
    background: conic-gradient(#f06 0%, gold 100%);
    background: conic-gradient(#f06 0deg, gold 1turn);

Below are various ways of specifying the same basic conic gradient. This demonstrates how even though color stops with angles outside [0deg, 360deg) are not directly painted, they can still affect the color of the painted part of the gradient.

    background: conic-gradient(white -50%, black 150%);
    background: conic-gradient(white -180deg, black 540deg);
    background: conic-gradient(hsl(0,0%,75%), hsl(0,0%,25%));

Below are two different ways of specifying the same rotated conic gradient, one with a rotation angle and one without:

    background: conic-gradient(from 45deg, white, black, white);
    background: conic-gradient(hsl(0,0%,75%), white 45deg, black 225deg, hsl(0,0%,75%));

Note that offsetting every color stop by the rotation angle instead would not work and produces an entirely different gradient:

    background: conic-gradient(white 45deg, black 225deg, white 405deg);

A conic gradient with a radial gradient overlaid on it, to draw a hue & saturation wheel:

    background: radial-gradient(gray, transparent),
                conic-gradient(red, magenta, blue, aqua, lime, yellow, red);
    border-radius: 50%;
    width: 200px; height: 200px;

A conic gradient used to draw a simple pie chart. The 0deg color stop positions will be fixed up to be equal to the position of the color stop before them. This will produce infinitesimal (invisible) transitions between the color stops with different colors, effectively producing solid color segments.

    background: conic-gradient(yellowgreen 40%, gold 0deg 75%, #f06 0deg);
    border-radius: 50%;
    width: 200px; height: 200px;

### 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations

In addition to linear-gradient(), radial-gradient(), and conic-gradient(), this specification defines repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() values. These notations take the same values and are interpreted the same as their respective non-repeating siblings defined previously.

Basic repeating conic gradient:

    background: repeating-conic-gradient(gold, #f06 20deg);

Repeating color stops with abrupt transitions creates a starburst-type background:

    background: repeating-conic-gradient(
                    hsla(0,0%,100%,.2) 0deg 15deg,
                    hsla(0,0%,100%,0) 0deg 30deg
                ) #0ac;

Here repeating color stops with abrupt transitions are used to create a checkerboard:

    background: repeating-conic-gradient(black 0deg 25%, white 0deg 50%);
    background-size: 60px 60px;

The same checkerboard can be created via non-repeating conic gradients:

    background: conic-gradient(black 25%, white 0deg 50%, black 0deg 75%, white 0deg);
    background-size: 60px 60px;

### 3.5. Defining Gradient Color

The colors in gradients are specified using color stops (a <color> and a corresponding position on the gradient line) and color transition hints (a position between two color stops representing the halfway point in the color transition) which are placed on the gradient line, defining the color at every point of the line. (Each gradient function defines the shape and length of the gradient line, along with its starting point and ending point; see above.)

#### 3.5.1. Color Stop Lists

Color stops and transition hints are specified in a color stop list, which is a list of two or more color stops interleaved with optional transition hints:

    <color-stop-list> =
      <linear-color-stop> , [ <linear-color-hint>? , <linear-color-stop> ]#
    <linear-color-stop> = <color> && <color-stop-length>?
    <linear-color-hint> = <length-percentage>
    <color-stop-length> = <length-percentage>{1,2}

    <angular-color-stop-list> =
      <angular-color-stop> , [ <angular-color-hint>? , <angular-color-stop> ]#
    <angular-color-stop> = <color> && <color-stop-angle>?
    <angular-color-hint> = <angle-percentage>
    <color-stop-angle> = <angle-percentage>{1,2}

    <color-stop> = <color-stop-length> | <color-stop-angle>

Note that <color-stop-list> and <angular-color-stop-list> are exactly identical in structure, they just differ on whether they accept <length>s or <angle>s for specifying the position of the stops and hints.

Visualized with a railroad diagram, both of them follow this pattern:

A color stop with two positions is equivalent to specifying two color stops with the same color, one for each position. Specifying two locations makes it easier to create solid-color "stripes" in a gradient, without having to repeat the color twice.

Percentages are resolved against the length of the gradient line between the starting point and ending point, with 0% being at the starting point and 100% being at the ending point. Lengths are measured along the gradient line from the starting point in the direction of the ending point.

Color stop and transition hint positions are usually placed between the starting point and ending point, but that’s not required: the gradient line extends infinitely in both directions, and positions can be specified anywhere on the gradient line.

When the position of a color stop is omitted, it is automatically assigned a position. The first or last color stop in the color stop list is assigned the gradient line’s starting point or ending point (respectively). Otherwise, it’s assigned the position halfway between the two surrounding stops. If multiple stops in a row lack a position, they space themselves out equally between the surrounding positioned stops. See § 3.5.3 Color Stop “Fixup” for details.

#### 3.5.2. Coloring the Gradient Line

At each color stop position, the gradient line is the color of the color stop. Before the first color stop, the gradient line is the color of the first color stop, and after the last color stop, the gradient line is the color of the last color stop. Between two color stops, the gradient line’s color is interpolated between the colors of the two color stops, with the interpolation taking place in premultiplied RGBA space.

By default, this interpolation is linear—at 25%, 50%, or 75% of the distance between two color stops, the color is a 25%, 50%, or 75% blend of the colors of the two stops.

However, if a transition hint was provided between two color stops, the interpolation is non-linear, and controlled by the hint:

1. Determine the location of the transition hint as a percentage of the distance between the two color stops, denoted as a number between 0 and 1, where 0 indicates the hint is placed right on the first color stop, and 1 indicates the hint is placed right on the second color stop. Let this percentage be H.
2. For any given point between the two color stops, determine the point’s location as a percentage of the distance between the two color stops, in the same way as the previous step. Let this percentage be P.
3. Let C, the color weighting at that point, be equal to `PlogH(.5)`.
4. The color at that point is then a linear blend between the colors of the two color stops, blending `(1 - C)` of the first stop and C of the second stop.

Note: The transition hint specifies where the “halfway color”—the 50% blend between the colors of the two surrounding color stops—should be placed. When the hint is exactly halfway between the two surrounding color stops, the above interpolation algorithm happens to produce the ordinary linear interpolation. If the hint is placed anywhere else, it produces a smooth exponential curve between the surrounding color stops, with the “halfway color” occurring exactly where the hint specifies.

Add a visual example of a color hint being used.

If multiple color stops have the same position, they produce an infinitesimal transition from the one specified first in the list to the one specified last. In effect, the color suddenly changes at that position rather than smoothly transitioning.

What does “pre-multiplied” mean?

A “pre-multiplied” color is written in a form where the alpha channel is multiplied into the color channels, rather than being processed independently. For example, a partially-transparent blue may be given as `rgba(0, 0, 255, .5)`, which would then be expressed as `[0, 0, 127.5, .5]` in its premultiplied representation.

Interpolating colors using the premultiplied representations rather than the plain rgba representations tends to produce more attractive transitions, particularly when transitioning from a fully opaque color to fully transparent.

Note that transitions where either the transparency or the color are held constant (for example, transitioning between `rgba(255, 0, 0, 100%)` (opaque red) and `rgba(0,0,255,100%)` (opaque blue), or `rgba(255,0,0,100%)` (opaque red) and `rgba(255,0,0,0%)` (transparent red)) have identical results whether the color interpolation is done in premultiplied or non-premultiplied color-space. Differences only arise when both the color and transparency differ between the two endpoints.

The following example illustrates the difference between a gradient transitioning in pre-multiplied sRGBA and one transitioning (incorrectly) in non-premultiplied. In both of these example, the gradient is drawn over a white background. Both gradients could be written with the following value:

    linear-gradient(90deg, red, transparent, blue)

With premultiplied colors, transitions to or from "transparent" always look nice:

On the other hand, if a gradient were to incorrectly transition in non-premultiplied space, the center of the gradient would be a noticeably grayish color, because "transparent" is actually a shorthand for rgba(0,0,0,0), or transparent black, meaning that the red transitions to a black as it loses opacity, and similarly with the blue’s transition:

#### 3.5.3. Color Stop “Fixup”

When resolving the used positions of each color stop, the following steps must be applied in order:

1. If the first color stop does not have a position, set its position to 0%. If the last color stop does not have a position, set its position to 100%.
2. If a color stop or transition hint has a position that is less than the specified position of any color stop or transition hint before it in the list, set its position to be equal to the largest specified position of any color stop or transition hint before it.
3. If any color stop still does not have a position, then, for each run of adjacent color stops without positions, set their positions so that they are evenly spaced between the preceding and following color stops with positions.

After applying these rules, all color stops and transition hints will have a definite position and color and they will be in ascending order.

Note: It is recommended that authors exercise caution when mixing different types of units, such as px, em, or %, as this can cause a color stop to unintentionally try to move before an earlier one. For example, the rule background-image: linear-gradient(yellow 100px, blue 50%) wouldn’t trigger any fix-up while the background area is at least 200px tall. If it was 150px tall, however, the blue color stop’s position would be equivalent to 75px, which precedes the yellow color stop, and would be corrected to a position of 100px. Additionally, since the relative ordering of such color stops cannot be determined without performing layout, they will not interpolate smoothly in animations or transitions.

Below are several pairs of gradients. The latter of each pair is a manually “fixed-up” version of the former, obtained by applying the above rules. For each pair, both gradients will render identically. The numbers in each arrow specify which fixup steps are invoked in the transformation.

    1. linear-gradient(red, white 20%, blue)
       =1=>
       linear-gradient(red 0%, white 20%, blue 100%)

    2. linear-gradient(red 40%, white, black, blue)
       =1,3=>
       linear-gradient(red 40%, white 60%, black 80%, blue 100%)

    3. linear-gradient(red -50%, white, blue)
       =1,3=>
       linear-gradient(red -50%, white 25%, blue 100%)

    4. linear-gradient(red -50px, white, blue)
       =1,3=>
       linear-gradient(red -50px, white calc(-25px + 50%), blue 100%)

    5. linear-gradient(red 20px, white 0px, blue 40px)
       =2=>
       linear-gradient(red 20px, white 20px, blue 40px)

    6. linear-gradient(red, white -50%, black 150%, blue)
       =1,2=>
       linear-gradient(red 0%, white 0%, black 150%, blue 150%)

    7. linear-gradient(red 80px, white 0px, black, blue 100px)
       =2,3=>
       linear-gradient(red 80px, white 80px, black 90px, blue 100px)

## 4. 1D Image Values: the stripes() notation

Per WG resolution, define the stripes() function which creates a 1D image for use in borders/outlines.

## 5. Sizing Images and Objects in CSS

### 5.1. Sizing Objects: the object-fit property

Name: | object-fit
Value: | fill | none | [contain | cover] || scale-down
Initial: | fill
Applies to: | replaced elements
Inherited: | no
Percentages: | n/a
Computed value: | specified keyword(s)
Canonical order: | per grammar
Animation type: | discrete

The object-fit property specifies how the contents of a replaced element should be fitted to the box established by its used height and width.

fill
  The replaced content is sized to fill the element’s content box: the object’s concrete object size is the element’s used width and height.
none
  The replaced content is not resized to fit inside the element’s content box: determine the object’s concrete object size using the default sizing algorithm with no specified size, and a default object size equal to the replaced element’s used width and height.
contain
  The replaced content is sized to maintain its aspect ratio while fitting within the element’s content box: its concrete object size is resolved as a contain constraint against the element’s used width and height.

  If the scale-down flag is used, size the content as if none or contain were specified, whichever would result in a smaller concrete object size.

  Note: Both none and contain respect the content’s intrinsic aspect ratio, so the concept of "smaller" is well-defined.

cover
  The replaced content is sized to maintain its aspect ratio while filling the element’s entire content box: its concrete object size is resolved as a cover constraint against the element’s used width and height.

  If the scale-down flag is used, size the content as if none or cover were specified, whichever would result in a smaller concrete object size.

  Note: Both none and cover respect the content’s intrinsic aspect ratio, so the concept of "smaller" is well-defined.

scale-down
  Equivalent to contain scale-down.

If the content does not completely fill the replaced element’s content box, the unfilled space shows the replaced element’s background. Since replaced elements always clip their contents to the content box, the content will never overflow. See the object-position property for positioning the object with respect to the content box.

An example showing how four of the values of object-fit cause the replaced element (blue figure) to be scaled to fit its height/width box (shown with a green background), using the initial value for object-position. In this case, scale-down and scale-down contain would look identical to contain, and scale-down cover would look identical to none.

Note: The object-fit property has similar semantics to the `fit` attribute in [SMIL10] and the <meetOrSlice> parameter on the `preserveAspectRatio` attribute in [SVG11].

Note: Per the object size negotiation algorithm, the concrete object size (or, in this case, the size of the content) does not directly scale the object itself - it is merely passed to the object as information about the size of the visible canvas. How to then draw into that size is up to the image format. In particular, raster images always scale to the given size, while SVG uses the given size as the size of the "SVG Viewport" (a term defined by SVG) and then uses the values of several attributes on the root `<svg>` element to determine how to draw itself.

## 6. Image Processing

### 6.1. Overriding Image Resolutions: the image-resolution property

The image resolution is defined as the number of image pixels per unit length, e.g., pixels per inch. Some image formats can record information about the resolution of images. This information can be helpful when determining the actual size of the image in the formatting process. However, the information can also be wrong, in which case it should be ignored. By default, CSS assumes a resolution of one image pixel per CSS px unit; however, the image-resolution property allows using some other resolution.

Name: | image-resolution
Value: | [ from-image || <resolution> ] && snap?
Initial: | 1dppx
Applies to: | all elements
Inherited: | yes
Percentages: | n/a
Computed value: | specified keyword(s) and/or <resolution> (possibly adjusted for snap, see below)
Canonical order: | per grammar
Animation type: | discrete

The image-set() notation can alter the intrinsic resolution of an image, which ideally would be automatically honored without having to set this property. How should we best address this? Change the initial value to auto, meaning "1dppx, unless CSS says otherwise"? Say that image-resolution has no effect on images whose resolution was set by something else in CSS? Or somehow wordsmithing image-set() in some way such that it always produces 1dppx images somehow?

The image-resolution property specifies the intrinsic resolution of all raster images used in or on the element. It affects both content images (e.g. replaced elements and generated content) and decorative images (such as background-image). The intrinsic resolution of an image is used to determine the image’s intrinsic dimensions. Values have the following meanings:

<resolution>
  Specifies the intrinsic resolution explicitly. A "dot" in this case corresponds to a single image pixel.
from-image
  The image’s intrinsic resolution is taken as that specified by the image format. If the image does not specify its own resolution, the explicitly specified resolution is used (if given), else it defaults to 1dppx.
snap
  If the "snap" keyword is provided, the computed <resolution> (if any) is the specified resolution rounded to the nearest value that would map one image pixel to an integer number of device pixels. If the resolution is taken from the image, then the used intrinsic resolution is the image’s native resolution similarly adjusted.

As vector formats such as SVG do not have an intrinsic resolution, this property has no effect on vector images.

Printers tend to have substantially higher resolution than computer monitors; due to this, an image that looks fine on the screen may look pixellated when printed out. The image-resolution property can be used to embed a high-resolution image into the document and maintain an appropriate size, ensuring attractive display both on screen and on paper:

    img.high-res {
      image-resolution: 300dpi;
    }

With this set, an image meant to be 5 inches wide at 300dpi will actually display as 5in wide; without this set, the image would display as approximately 15.6in wide since the image is 15000 image pixels across, and by default CSS displays 96 image pixels per inch.

Some image formats can encode the image resolution into the image data. This rule specifies that the UA should use the image resolution found in the image itself, falling back to 1 image pixel per CSS px unit.

    img { image-resolution: from-image }

These rules both specify that the UA should use the image resolution found in the image itself, but if the image has no resolution, the resolution is set to 300dpi instead of the default 1dppx.

    img { image-resolution: from-image 300dpi }
    img { image-resolution: 300dpi from-image }

Using this rule, the image resolution is set to 300dpi. (The resolution in the image, if any, is ignored.)

    img { image-resolution: 300dpi }

This rule, on the other hand, if used when the screen’s resolution is 96dpi, would instead render the image at 288dpi (so that 3 image pixels map to 1 device pixel):

    img { image-resolution: 300dpi snap; }

The snap keyword can also be used when the resolution is taken from the image:

    img { image-resolution: snap from-image; }

An image declaring itself as 300dpi will, in the situation above, display at 288dpi (3 image pixels per device pixel) whereas an image declaring 72dpi will render at 96dpi (1 image pixel per device pixel).

## 7. Interpolation

This section describes how to interpolate between new value types defined in this specification, for use with modules such as CSS Transitions and CSS Animations.

If an algorithm below simply states that two values should be "interpolated" or "transitioned" without further details, then the value should be interpolated as described by the Transitions spec. Otherwise, the algorithm may reference a variable t in its detailed description of the interpolation. This is a number which starts at 0% and goes to 100%, and is set to a value that represents the progress through the transition, based on the duration of the transition, the elapsed time, and the timing function in use. For example, with a linear timing function and a 1s duration, after .3s t is equal to 30%.

### 7.1. Interpolating <image>

All images can be interpolated, though some special types of images (like some gradients) have their own special interpolation rules. In general terms, images are interpolated by scaling them to the size of the start image and cross-fading the two while they transition to the size of the end image.

In specific terms, at each point in the interpolation the image is equal to `cross-fade( (100% - t) start image, end image)`.

Special-case interpolating to/from no image, like "background-image: url(foo);" to "background-image: none;".

### 7.2. Interpolating cross-fade()

The three components of cross-fade() are interpolated independently. Note this may result in nested cross-fade() notations.

### 7.3. Interpolating <gradient>

This section needs review and improvement. In particular, I believe the handling of linear-gradient() is incomplete - I think we want to specifically interpolate the "length" of the gradient line (the distance between 0% and 100%) between the starting and ending positions explicitly, so it doesn’t grow and then shrink over a single animation.

Gradient images can be interpolated directly in CSS transitions and animations, smoothly animating from one gradient to another. There are only a few restrictions on what gradients are allowed to be interpolated:

1. Both the starting and ending gradient must be expressed with the same function. (For example, you can transition from a linear-gradient() to a linear-gradient(), but not from a linear-gradient() to a radial-gradient() or a repeating-linear-gradient().)

2. Both the starting and ending gradient must have the same number of <color-stop>s. For this purpose, all repeating gradients are considered to have infinite color stops, and thus all repeating gradients match in this respect.

3. Neither gradient uses a combination of <length> and <percentage> color stops.

If the two gradients satisfy all of those constraints, they must be interpolated as described below. If they fail the third one only, they must be abruptly transitioned at 50% (unless otherwise specified by a future specification). If they fail either of the first two constraints, they must be interpolated using cross-fade() as for generic images.

Note: The abrupt transition at 50% is so that content will not rely on cross-fading, and smarter interpolation rules can be added for this case in the future.

1. Convert both the start and end gradients to their explicit forms:

   For linear gradients:

     - If the direction is specified as an <angle>, it is already in its explicit form.

     - Otherwise, change its direction to an <angle> in [0deg,360deg) that would produce an equivalent rendering.

       If both the start and end gradients had their direction specified with keywords, and the absolute difference between the angles their directions mapped to is greater than 180deg, add 360deg to the direction of the gradient with the smaller angle. This ensures that a transition from, for example, "to left" (270deg) to "to top" (0deg) rotates the gradient a quarter-turn clockwise, as expected, rather than rotating three-quarters of a turn counter-clockwise.

   For radial gradients:

     - If the size is specified as two <length>s or <percentage>s, it is already in its explicit form.

     - Otherwise, the size must be changed to a pair of <length>s that would produce an equivalent ending-shape. If the <ending-shape> was specified as circle, change it to ellipse.

2. Interpolate each component and color-stop of the gradients independently. For linear gradients, the only component is the angle. For radial gradients, the components are the horizontal and vertical position of the center and the horizontal and vertical axis lengths.

3. To interpolate a color-stop, first match each color-stop in the start gradient to the corresponding color-stop at the same index in the end gradient. For repeating gradients, the first specified color-stop in the start and end gradients are considered to be at the same index, and all other color-stops following and preceding are indexed appropriately, repeating and shifting each gradient’s list of color-stops as needed. Then, for each pair of color-stops, interpolate the position and color independently.

## 8. Serialization

This section describes the serialization of all new properties and value types introduced in this specification, for the purpose of interfacing with the CSS Object Model [CSSOM].

To serialize any function defined in this module, serialize it per its individual grammar, in the order its grammar is written in, omitting components when possible without changing the meaning, joining space-separated tokens with a single space, and following each serialized comma with a single space.

For cross-fade(), always serialize the <percentage>.

For example, a gradient specified as:

    Linear-Gradient( to bottom, red 0%,yellow,black 100px)

must serialize as:

    linear-gradient(red, yellow, black 100px)

## 9. Privacy and Security Considerations

Note: No change from [css3-images].

## 10. Changes

### Changes Since the 11 September 2012 Working Draft

- Added color interpolation hints

- Added the two location syntax for gradient color stops

- Added start angles to conic gradients

- The position(s) of a color stop can now come before the color

- Text that is identical to [css3-images] has been replaced with a reference to [css3-images].

### Changes Since Level 3

- Added the image() notation (deferred from Level 3)

- Added the image-resolution property (deferred from Level 3)

- Added the element() notation (deferred from Level 3)

- Added conic gradients

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

### Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.

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

#### Implementations of CR-level Features

Once a specification reaches the Candidate Recommendation stage, implementers should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec, and should avoid exposing a prefixed variant of that feature.

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.

Support: Android BrowserNoneBaidu BrowserNoneBlackberry BrowserNoneChromeNoneChrome for AndroidNoneEdgeNoneFirefoxNoneFirefox for AndroidNoneIENoneIE MobileNoneKaiOS BrowserNoneOperaNoneOpera MiniNoneOpera MobileNoneQQ BrowserNoneSafari10+Samsung InternetNoneUC Browser for AndroidNoneiOS Safari10.0+

Source: caniuse.com as of 2019-06-04

Support: Android BrowserNoneBaidu BrowserNoneBlackberry BrowserNoneChromeNoneChrome for AndroidNoneEdgeNoneFirefoxNoneFirefox for AndroidNoneIENoneIE MobileNoneKaiOS BrowserNoneOperaNoneOpera MiniNoneOpera MobileNoneQQ BrowserNoneSafari10+Samsung InternetNoneUC Browser for AndroidNoneiOS Safari10.0+

Source: caniuse.com as of 2019-06-04

Support: Android BrowserNoneBaidu BrowserNoneBlackberry BrowserNoneChromeNoneChrome for AndroidNoneEdgeNoneFirefoxNoneFirefox for AndroidNoneIENoneIE MobileNoneKaiOS BrowserNoneOperaNoneOpera MiniNoneOpera MobileNoneQQ BrowserNoneSafariNoneSamsung InternetNoneUC Browser for AndroidNoneiOS SafariNone

Source: caniuse.com as of 2019-06-04

## Index

### Terms defined by this specification

- <angle>, in §3.3.1
- <angular-color-hint>, in §3.5.1
- <angular-color-stop>, in §3.5.1
- <angular-color-stop-list>, in §3.5.1
- appearance of a cross-fade(), in §2.5.2
- <cf-image>, in §2.5
- <color-stop>, in §3.5.1
- color stop, in §3.5
- <color-stop-angle>, in §3.5.1
- <color-stop-length>, in §3.5.1
- <color-stop-list>, in §3.5.1
- color stop list, in §3.5.1
- color transition hint, in §3.5
- computed <image>, in §2
- conic-gradient(), in §3.3.1
- contain, in §5.1
- cover, in §5.1
- cross-fade(), in §2.5
- decorated bounding box, in §2.6
- element(), in §2.6
- element-not-rendered, in §2.6
- elementSources, in §2.6.2
- ending point, in §3
- fill, in §5.1
- from-image, in §6.1
- <gradient>, in §3
- gradient box, in §3
- gradient center, in §3.3.1
- gradient function, in §3
- gradient line, in §3
- <image>, in §2
- image(), in §2.4
- image resolution, in §6.1
- image-resolution, in §6.1
- image-set(), in §2.3
- <image-set-option>, in §2.3
- <image-src>, in §2.4
- <image-tags>, in §2.4
- intrinsic dimensions of a cross-fade(), in §2.5.1
- intrinsic resolution, in §6.1
- invalid image, in §2
- <linear-color-hint>, in §3.5.1
- <linear-color-stop>, in §3.5.1
- loading image, in §2
- none, in §5.1
- object-fit, in §5.1
- paint source, in §2.6.1
- <position>, in §3.3.1
- repeating-conic-gradient(), in §3.4
- repeating-linear-gradient(), in §3.4
- repeating-radial-gradient(), in §3.4
- <resolution>, in §6.1
- scale-down, in §5.1
- snap, in §6.1
- starting point, in §3
- transition hint, in §3.5
- valid image, in §2

https://drafts.csswg.org/css-backgrounds-3/#propdef-background-color Referenced in:

- 2.4.3. Solid-color Images

https://drafts.csswg.org/css-backgrounds-3/#propdef-background-image Referenced in:

- 2. 2D Image Values: the <image> type
- 3.5.3. Color Stop “Fixup”
- 6.1. Overriding Image Resolutions: the image-resolution property

https://drafts.csswg.org/css-backgrounds-3/#propdef-background-position Referenced in:

- 3.3.1. conic-gradient() Syntax

https://drafts.csswg.org/css-backgrounds-3/#propdef-background-size Referenced in:

- 3. Gradients

https://drafts.csswg.org/css-backgrounds-3/#valdef-background-position-center Referenced in:

- 3.3.1. conic-gradient() Syntax

https://drafts.csswg.org/css-cascade-4/#computed-value Referenced in:

- 2. 2D Image Values: the <image> type

https://drafts.csswg.org/css-cascade-4/#specified-value Referenced in:

- 2. 2D Image Values: the <image> type

https://drafts.csswg.org/css-cascade-4/#used-value Referenced in:

- 3.5.3. Color Stop “Fixup”

https://drafts.csswg.org/css-color-3/#valuea-def-color Referenced in:

- 2. 2D Image Values: the <image> type
- 2.4. Image Fallbacks and Annotations: the image() notation
- 2.4.1. Image Fallbacks (2)
- 2.4.3. Solid-color Images
- 2.5. Combining images: the cross-fade() notation (2)
- 2.5.1. cross-fade() Sizing
- 2.5.2. cross-fade() Painting (2)
- 3.5. Defining Gradient Color
- 3.5.1. Color Stop Lists (2)

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

- 2. 2D Image Values: the <image> type (2)
- 2.5. Combining images: the cross-fade() notation
- 2.6. Using Elements as Images: the element() notation

https://drafts.csswg.org/css-lists-3/#propdef-list-style-image Referenced in:

- 2. 2D Image Values: the <image> type (2)
- 3. Gradients

https://drafts.csswg.org/css-lists-3/#propdef-list-style-type Referenced in:

- 2. 2D Image Values: the <image> type

https://drafts.csswg.org/css-lists-3/#valdef-list-style-type-none Referenced in:

- 2. 2D Image Values: the <image> type

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

- 2. 2D Image Values: the <image> type

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

- 3.3. Conic Gradients: the conic-gradient() notation
- 3.3.1. conic-gradient() Syntax (2) (3)
- 3.5.1. Color Stop Lists
- 7.3. Interpolating <gradient> (2)

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

- 2. 2D Image Values: the <image> type
- 3.3. Conic Gradients: the conic-gradient() notation
- 3.5.1. Color Stop Lists
- 7.3. Interpolating <gradient> (2) (3)

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

- 2.5. Combining images: the cross-fade() notation (2) (3)
- 7.3. Interpolating <gradient> (2)
- 8. Serialization

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

- 2.3. Resolution Negotiation: the image-set() notation (2)
- 6.1. Overriding Image Resolutions: the image-resolution property (2) (3) (4)

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

- 2.3. Resolution Negotiation: the image-set() notation (2)
- 2.4. Image Fallbacks and Annotations: the image() notation (2)

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

- 2. 2D Image Values: the <image> type (2) (3) (4)
- 2.3. Resolution Negotiation: the image-set() notation
- 2.4. Image Fallbacks and Annotations: the image() notation (2)

https://drafts.csswg.org/css-values-4/#mult-req Referenced in:

- 2.4. Image Fallbacks and Annotations: the image() notation

https://drafts.csswg.org/css-values-4/#mult-comma Referenced in:

- 2.3. Resolution Negotiation: the image-set() notation
- 2.5. Combining images: the cross-fade() notation
- 3.5.1. Color Stop Lists (2)

https://drafts.csswg.org/css-values-4/#comb-all Referenced in:

- 2.5. Combining images: the cross-fade() notation
- 3.5.1. Color Stop Lists (2)
- 6.1. Overriding Image Resolutions: the image-resolution property

https://drafts.csswg.org/css-values-4/#comb-comma Referenced in:

- 2.4. Image Fallbacks and Annotations: the image() notation
- 3.3.1. conic-gradient() Syntax
- 3.5.1. Color Stop Lists (2) (3) (4)

https://drafts.csswg.org/css-values-4/#typedef-angle-percentage Referenced in:

- 3.5.1. Color Stop Lists (2)

https://drafts.csswg.org/css-values-4/#identifier-value Referenced in:

- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface (2)

https://drafts.csswg.org/css-values-4/#typedef-length-percentage Referenced in:

- 3.5.1. Color Stop Lists (2)

https://drafts.csswg.org/css-values-4/#typedef-position Referenced in:

- 3.3.1. conic-gradient() Syntax (2) (3)

https://drafts.csswg.org/css-values-4/#mult-opt Referenced in:

- 2.4. Image Fallbacks and Annotations: the image() notation (2) (3)
- 2.5. Combining images: the cross-fade() notation
- 3.3.1. conic-gradient() Syntax (2)
- 3.5.1. Color Stop Lists (2) (3) (4)
- 6.1. Overriding Image Resolutions: the image-resolution property

https://drafts.csswg.org/css-values-4/#px Referenced in:

- 2.6.1. Paint Sources
- 6.1. Overriding Image Resolutions: the image-resolution property (2)

https://drafts.csswg.org/css-values-4/#funcdef-url Referenced in:

- 2.2. Image References: the url() notation
- 2.4.2. Image Fragments

https://drafts.csswg.org/css-values-4/#mult-num-range Referenced in:

- 3.5.1. Color Stop Lists (2)

https://drafts.csswg.org/css-values-4/#comb-one Referenced in:

- 2. 2D Image Values: the <image> type (2) (3) (4)
- 2.3. Resolution Negotiation: the image-set() notation
- 2.4. Image Fallbacks and Annotations: the image() notation (2)
- 2.5. Combining images: the cross-fade() notation
- 3. Gradients (2) (3) (4) (5)
- 3.5.1. Color Stop Lists
- 5.1. Sizing Objects: the object-fit property (2) (3)

https://drafts.csswg.org/css-values-4/#comb-any Referenced in:

- 5.1. Sizing Objects: the object-fit property
- 6.1. Overriding Image Resolutions: the image-resolution property

https://drafts.csswg.org/css2/visuren.html#x43 Referenced in:

- 2.6. Using Elements as Images: the element() notation

https://drafts.csswg.org/css-images-3/#valdef-ending-shape-circle Referenced in:

- 7.3. Interpolating <gradient>

https://drafts.csswg.org/css-images-3/#concrete-object-size Referenced in:

- 2.5.1. cross-fade() Sizing
- 2.5.2. cross-fade() Painting
- 2.6.1. Paint Sources (2) (3) (4) (5) (6)
- 3. Gradients
- 5.1. Sizing Objects: the object-fit property (2) (3) (4) (5) (6) (7)

https://drafts.csswg.org/css-images-3/#contain-constraint Referenced in:

- 5.1. Sizing Objects: the object-fit property

https://drafts.csswg.org/css-images-3/#cover-constraint Referenced in:

- 5.1. Sizing Objects: the object-fit property

https://drafts.csswg.org/css-images-3/#default-object-size Referenced in:

- 3. Gradients
- 5.1. Sizing Objects: the object-fit property

https://drafts.csswg.org/css-images-3/#default-sizing-algorithm Referenced in:

- 5.1. Sizing Objects: the object-fit property

https://drafts.csswg.org/css-images-3/#valdef-ending-shape-ellipse Referenced in:

- 7.3. Interpolating <gradient>

https://drafts.csswg.org/css-images-3/#intrinsic-dimensions Referenced in:

- 2. 2D Image Values: the <image> type
- 3. Gradients
- 6.1. Overriding Image Resolutions: the image-resolution property

https://drafts.csswg.org/css-images-3/#funcdef-linear-gradient Referenced in:

- 3. Gradients
- 3.1. Linear Gradients: the linear-gradient() notation
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations
- 7.3. Interpolating <gradient> (2) (3)

https://drafts.csswg.org/css-images-3/#object-size-negotiation Referenced in:

- 2.5.1. cross-fade() Sizing
- 5.1. Sizing Objects: the object-fit property

https://drafts.csswg.org/css-images-3/#propdef-object-position Referenced in:

- 5.1. Sizing Objects: the object-fit property (2)

https://drafts.csswg.org/css-images-3/#funcdef-radial-gradient Referenced in:

- 3. Gradients
- 3.2. Radial Gradients: the radial-gradient() notation
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations
- 7.3. Interpolating <gradient>

https://drafts.csswg.org/cssom-1/#namespacedef-css Referenced in:

- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface

https://html.spec.whatwg.org/multipage/canvas.html#canvas Referenced in:

- 2.6. Using Elements as Images: the element() notation
- 2.6.1. Paint Sources
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface

https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element Referenced in:

- 2.6. Using Elements as Images: the element() notation
- 2.6.1. Paint Sources

https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element Referenced in:

- 2.6. Using Elements as Images: the element() notation

https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element Referenced in:

- 2.3. Resolution Negotiation: the image-set() notation

https://html.spec.whatwg.org/multipage/media.html#video Referenced in:

- 2.6. Using Elements as Images: the element() notation
- 2.6.1. Paint Sources

https://infra.spec.whatwg.org/#list-iterate Referenced in:

- 2.5.1. cross-fade() Sizing (2)
- 2.5.2. cross-fade() Painting (2)

https://infra.spec.whatwg.org/#list-item Referenced in:

- 2.5.1. cross-fade() Sizing
- 2.5.2. cross-fade() Painting

https://infra.spec.whatwg.org/#tuple Referenced in:

- 2.5.1. cross-fade() Sizing
- 2.5.2. cross-fade() Painting (2) (3)

https://drafts.csswg.org/selectors-4/#typedef-id-selector Referenced in:

- 2.6. Using Elements as Images: the element() notation (2)
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface

https://heycam.github.io/webidl/#SameObject Referenced in:

- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface

### Terms defined by reference

- [css-backgrounds-3] defines the following terms:
  - background-color
  - background-image
  - background-position
  - background-size
  - center
- [css-cascade-4] defines the following terms:
  - computed value
  - specified value
  - used value
- [css-color-3] defines the following terms:
  - <color>
- [css-color-4] defines the following terms:
  - transparent
- [css-lists-3] defines the following terms:
  - list-style-image
  - list-style-type
  - none
- [css-ui-4] defines the following terms:
  - cursor
- [css-values-3] defines the following terms:
  - <angle>
  - <length>
  - <percentage>
  - <resolution>
  - <string>
  - <url>
- [css-values-4] defines the following terms:
  - !
  - #
  - &&
  - ,
  - <angle-percentage>
  - <custom-ident>
  - <length-percentage>
  - <position>
  - ?
  - px
  - url()
  - {a,b}
  - |
  - ||
- [CSS21] defines the following terms:
  - stacking context
- [css3-images] defines the following terms:
  - circle
  - concrete object size
  - contain constraint
  - cover constraint
  - default object size
  - default sizing algorithm
  - ellipse
  - intrinsic dimensions
  - linear-gradient()
  - object size negotiation
  - object-position
  - radial-gradient()
- [CSSOM] defines the following terms:
  - CSS
- [HTML] defines the following terms:
  - canvas
  - img
  - p
  - picture
  - video
- [INFRA] defines the following terms:
  - for each
  - item
  - tuple
- [selectors-4] defines the following terms:
  - <id-selector>
- [WebIDL] defines the following terms:
  - SameObject

## References

### Normative References

[CSS-BACKGROUNDS-3]
  Bert Bos; Elika Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 17 October 2017. CR. URL: https://www.w3.org/TR/css-backgrounds-3/
[CSS-CASCADE-4]
  Elika Etemad; Tab Atkins Jr.. CSS Cascading and Inheritance Level 4. 28 August 2018. CR. URL: https://www.w3.org/TR/css-cascade-4/
[CSS-COLOR-3]
  Tantek Çelik; Chris Lilley; David Baron. CSS Color Module Level 3. 19 June 2018. REC. URL: https://www.w3.org/TR/css-color-3/
[CSS-COLOR-4]
  Tab Atkins Jr.; Chris Lilley. CSS Color Module Level 4. 5 March 2019. WD. URL: https://www.w3.org/TR/css-color-4/
[CSS-LISTS-3]
  Elika Etemad; Tab Atkins Jr.. CSS Lists Module Level 3. 25 April 2019. WD. URL: https://www.w3.org/TR/css-lists-3/
[CSS-UI-4]
  Florian Rivoal. CSS Basic User Interface Module Level 4. 22 December 2017. WD. URL: https://www.w3.org/TR/css-ui-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/
[CSS-VALUES-4]
  Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. 31 January 2019. WD. URL: https://www.w3.org/TR/css-values-4/
[CSS21]
  Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. REC. URL: https://www.w3.org/TR/CSS2/
[CSS3-IMAGES]
  Elika Etemad; Tab Atkins Jr.. CSS Image Values and Replaced Content Module Level 3. 17 April 2012. CR. URL: https://www.w3.org/TR/css3-images/
[CSS3-TRANSFORMS]
  Simon Fraser; et al. CSS Transforms Module Level 1. 14 February 2019. CR. URL: https://www.w3.org/TR/css-transforms-1/
[CSSOM]
  Simon Pieters; Glenn Adams. CSS Object Model (CSSOM). 17 March 2016. WD. URL: https://www.w3.org/TR/cssom-1/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
  Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[MEDIA-FRAGS]
  Raphaël Troncy; et al. Media Fragments URI 1.0 (basic). 25 September 2012. REC. URL: https://www.w3.org/TR/media-frags/
[PNG]
  Tom Lane. Portable Network Graphics (PNG) Specification (Second Edition). 10 November 2003. REC. URL: https://www.w3.org/TR/PNG/
[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
[SELECT]
  Tantek Çelik; et al. Selectors Level 3. 6 November 2018. REC. URL: https://www.w3.org/TR/selectors-3/
[SELECTORS-4]
  Elika Etemad; Tab Atkins Jr.. Selectors Level 4. 21 November 2018. WD. URL: https://www.w3.org/TR/selectors-4/
[SVG-INTEGRATION]
  Cameron McCormack; Doug Schepers; Dirk Schulze. SVG Integration. 17 April 2014. WD. URL: https://www.w3.org/TR/svg-integration/
[SVG11]
  Erik Dahlström; et al. Scalable Vector Graphics (SVG) 1.1 (Second Edition). 16 August 2011. REC. URL: https://www.w3.org/TR/SVG11/
[WebIDL]
  Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/

### Informative References

[SMIL10]
  Philipp Hoschka. Synchronized Multimedia Integration Language (SMIL) 1.0 Specification. 15 June 1998. REC. URL: https://www.w3.org/TR/1998/REC-smil-19980615/

## Property Index

Name | Value | Initial | Applies to | Inh. | %ages | Animation type | Canonical order | Computed value
--- | --- | --- | --- | --- | --- | --- | --- | ---
image-resolution | [ from-image || <resolution> ] && snap? | 1dppx | all elements | yes | n/a | discrete | per grammar | specified keyword(s) and/or <resolution> (possibly adjusted for snap, see below)
object-fit | fill | none | [contain | cover] || scale-down | fill | replaced elements | no | n/a | discrete | per grammar | specified keyword(s)

## IDL Index

    partial namespace CSS {
      [SameObject] readonly attribute any elementSources;
    };

## Issues Index

This solution assumes that resolution is a proxy for filesize, and therefore doesn’t appropriately handle multi-resolution sets of vector images, or mixing vector images with raster ones (e.g. for icons). For example, use a vector for high-res, pixel-optimized bitmap for low-res, and same vector again for low-bandwidth (because it’s much smaller, even though it’s higher resolution). ↵
We should add "w" and "h" dimensions as a possibility, and a "format()" function, to match the functionality of HTML’s picture. ↵
Is this restriction needed? ↵
Per WG resolution, define a notion of "equality" for images, and combine "same" images at computed-value time, summing their percentages. ↵
Per WG resolution, simplify directly-nested cross-fade() at computed-value time by just distributing the percentage and flattening; cross-fade(A 10%, cross-fade(B 30%, C 70%) 90%) becomes cross-fade(A 10%, B 27%, C 63%). ↵
Do we need to be able to refer to elements in external documents (such as SVG paint servers)? Or is it enough to just use url() for this? ↵
This name conflicts with a somewhat similar function in GCPM. This needs to be resolved somehow. ↵
Want the ability to do "reflections" of an element, either as a background-image on the element or in a pseudo-element. This needs to be specially-handled to avoid triggering the cycle-detection. ↵
When we have overflow:paged, how can we address a single page in the view? ↵
Requiring some degree of stacking context on the element appears to be required for an efficient implementation. Do we need a full stacking context, or just a pseudo-stacking context? Should it need to be a stacking context normally, or can we just render it as a stacking context when rendering it to element()? ↵
This reuse of the ID selector matches Moz behavior. I’m trying to avoid slapping a <custom-ident> right in the beginning of the grammar, as that eats too much syntax-space. Another possibility, though, is to start the value with a language-defined keyword followed by a <custom-ident>, like element(external fancy) or something. Naming suggestions welcome. ↵
Usually in conic gradients the sharp transition at 0deg is undesirable, which is typically avoided by making sure the first and last color stops are the same color. Perhaps it would be useful to have a keyword for automatically achieving this. ↵
Would a radius (inner & outer) for clipping the gradient be useful? If so, we could also support lengths in color stop positions, since we now have a specific radius. ↵
Are elliptical conic gradients useful? Do graphics libraries support them? ↵
Add a visual example of a color hint being used. ↵
Per WG resolution, define the stripes() function which creates a 1D image for use in borders/outlines. ↵
The image-set() notation can alter the intrinsic resolution of an image, which ideally would be automatically honored without having to set this property. How should we best address this? Change the initial value to auto, meaning "1dppx, unless CSS says otherwise"? Say that image-resolution has no effect on images whose resolution was set by something else in CSS? Or somehow wordsmithing image-set() in some way such that it always produces 1dppx images somehow? ↵
Special-case interpolating to/from no image, like "background-image: url(foo);" to "background-image: none;". ↵
This section needs review and improvement. In particular, I believe the handling of linear-gradient() is incomplete - I think we want to specifically interpolate the "length" of the gradient line (the distance between 0% and 100%) between the starting and ending positions explicitly, so it doesn’t grow and then shrink over a single animation. ↵
#typedef-image Referenced in:

- 2. 2D Image Values: the <image> type (2) (3) (4)
- 2.1. Image File Formats (2) (3)
- 2.3. Resolution Negotiation: the image-set() notation (2)
- 2.5. Combining images: the cross-fade() notation
- 2.5.1. cross-fade() Sizing (2) (3)
- 2.5.2. cross-fade() Painting
- 3. Gradients
- 7.1. Interpolating <image>

#invalid-image Referenced in:

- 2. 2D Image Values: the <image> type (2) (3)
- 2.4.1. Image Fallbacks (2)
- 2.4.2. Image Fragments
- 2.6. Using Elements as Images: the element() notation
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface
- 2.6.3. Cycle Detection

#loading-image Referenced in:

- 2. 2D Image Values: the <image> type (2) (3) (4)
- 2.4.1. Image Fallbacks (2)

#funcdef-image-set Referenced in:

- 2. 2D Image Values: the <image> type
- 2.3. Resolution Negotiation: the image-set() notation (2) (3) (4) (5) (6) (7) (8) (9)
- 6.1. Overriding Image Resolutions: the image-resolution property (2)

#typedef-image-set-option Referenced in:

- 2.3. Resolution Negotiation: the image-set() notation (2) (3) (4)

#funcdef-image Referenced in:

- 2. 2D Image Values: the <image> type
- 2.4. Image Fallbacks and Annotations: the image() notation (2) (3) (4) (5)
- 2.4.1. Image Fallbacks (2) (3) (4)
- 2.4.2. Image Fragments (2) (3) (4) (5)
- 2.4.3. Solid-color Images
- Changes Since Level 3

#typedef-image-tags Referenced in:

- 2.4. Image Fallbacks and Annotations: the image() notation

#typedef-image-src Referenced in:

- 2.4. Image Fallbacks and Annotations: the image() notation

#funcdef-cross-fade Referenced in:

- 2. 2D Image Values: the <image> type
- 2.5. Combining images: the cross-fade() notation (2) (3) (4)
- 2.5.1. cross-fade() Sizing (2) (3) (4)
- 2.5.2. cross-fade() Painting (2) (3) (4)
- 2.5.3. Simplifying Complex cross-fade() (2)
- 7.2. Interpolating cross-fade() (2)
- 7.3. Interpolating <gradient>
- 8. Serialization

#typedef-cf-image Referenced in:

- 2.5. Combining images: the cross-fade() notation

#intrinsic-dimensions-of-a-cross-fade Referenced in:

- 2.5.2. cross-fade() Painting

#funcdef-element Referenced in:

- 2.6. Using Elements as Images: the element() notation (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface (2) (3) (4) (5)
- 2.6.3. Cycle Detection (2) (3)
- Changes Since Level 3

#decorated-bounding-box Referenced in:

- 2.6. Using Elements as Images: the element() notation (2) (3) (4)

#element-not-rendered Referenced in:

- 2.6. Using Elements as Images: the element() notation (2)
- 2.6.1. Paint Sources

#paint-source Referenced in:

- 2.6. Using Elements as Images: the element() notation (2)
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface (2) (3) (4)

#dom-css-elementsources Referenced in:

- 2.6. Using Elements as Images: the element() notation
- 2.6.2. Using Out-Of-Document Sources: the ElementSources interface (2) (3) (4) (5)

#gradient-function Referenced in:

- 3.5. Defining Gradient Color

#typedef-gradient Referenced in:

- 2. 2D Image Values: the <image> type
- 3. Gradients
- 7.3. Interpolating <gradient>

#gradient-box Referenced in:

- 3. Gradients (2)
- 3.3.1. conic-gradient() Syntax

#starting-point Referenced in:

- 3.5. Defining Gradient Color
- 3.5.1. Color Stop Lists (2) (3) (4)

#ending-point Referenced in:

- 3.5. Defining Gradient Color
- 3.5.1. Color Stop Lists (2) (3) (4)

#gradient-line Referenced in:

- 3. Gradients
- 3.3.2. Placing Color Stops (2)
- 3.5. Defining Gradient Color (2) (3)
- 3.5.1. Color Stop Lists (2) (3) (4)
- 3.5.2. Coloring the Gradient Line (2) (3) (4)

#funcdef-conic-gradient Referenced in:

- 3. Gradients
- 3.3. Conic Gradients: the conic-gradient() notation
- 3.3.1. conic-gradient() Syntax
- 3.3.3. Conic Gradient Examples
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations

#conic-gradient-gradient-center Referenced in:

- 3.3.2. Placing Color Stops

#funcdef-repeating-linear-gradient Referenced in:

- 3. Gradients
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations
- 7.3. Interpolating <gradient>

#funcdef-repeating-radial-gradient Referenced in:

- 3. Gradients
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations

#funcdef-repeating-conic-gradient Referenced in:

- 3. Gradients
- 3.4. Repeating Gradients: the repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient() notations

#color-stop Referenced in:

- 3.5. Defining Gradient Color
- 3.5.1. Color Stop Lists (2) (3) (4) (5) (6) (7)
- 3.5.2. Coloring the Gradient Line (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16)
- 3.5.3. Color Stop “Fixup” (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

#color-transition-hint Referenced in:

- 3.5.1. Color Stop Lists (2) (3)
- 3.5.2. Coloring the Gradient Line (2) (3)
- 3.5.3. Color Stop “Fixup” (2) (3) (4)

#color-stop-list Referenced in:

- 3.5.1. Color Stop Lists

#typedef-color-stop-list Referenced in:

- 3.5.1. Color Stop Lists

#typedef-linear-color-stop Referenced in:

- 3.5.1. Color Stop Lists (2)

#typedef-linear-color-hint Referenced in:

- 3.5.1. Color Stop Lists

#typedef-color-stop-length Referenced in:

- 3.5.1. Color Stop Lists (2)

#typedef-angular-color-stop-list Referenced in:

- 3.3.1. conic-gradient() Syntax
- 3.5.1. Color Stop Lists

#typedef-angular-color-stop Referenced in:

- 3.5.1. Color Stop Lists (2)

#typedef-angular-color-hint Referenced in:

- 3.5.1. Color Stop Lists

#typedef-color-stop-angle Referenced in:

- 3.5.1. Color Stop Lists (2)

#typedef-color-stop Referenced in:

- 7.3. Interpolating <gradient>

#propdef-object-fit Referenced in:

- 5.1. Sizing Objects: the object-fit property (2) (3) (4)

#valdef-object-fit-none Referenced in:

- 5.1. Sizing Objects: the object-fit property (2) (3) (4) (5)

#valdef-object-fit-contain Referenced in:

- 5.1. Sizing Objects: the object-fit property (2) (3)

#valdef-object-fit-cover Referenced in:

- 5.1. Sizing Objects: the object-fit property (2)

#valdef-object-fit-scale-down Referenced in:

- 5.1. Sizing Objects: the object-fit property (2) (3)

#propdef-image-resolution Referenced in:

- 6.1. Overriding Image Resolutions: the image-resolution property (2) (3) (4)
- Changes Since Level 3

#intrinsic-resolution Referenced in:

- 6.1. Overriding Image Resolutions: the image-resolution property

#valdef-image-resolution-snap Referenced in:

- 6.1. Overriding Image Resolutions: the image-resolution property (2)