CSS Image Values and Replaced Content Module Level 3

W3C

CSS Image Values and Replaced Content Module Level 3

W3C Working Draft 12 January 2012

This Version:
http://www.w3.org/TR/2012/WD-css3-images-20120112/
Latest Version:
http://www.w3.org/TR/css3-images/
Editor's Draft:
http://dev.w3.org/csswg/css3-images/
Previous Version:
http://www.w3.org/TR/2011/WD-css3-images-20111206/
http://www.w3.org/TR/2011/WD-css3-images-20110908/
http://www.w3.org/TR/2011/WD-css3-images-20110712/
http://www.w3.org/TR/2011/WD-css3-images-20110217/
http://www.w3.org/TR/2009/WD-css3-images-20090723/
Issues List:
http://www.w3.org/Style/CSS/Tracker/products/27
Discussion:
www-style@w3.org with subject line “[css3-images] … message topic …
Editors:
Elika J. Etemad (Mozilla)
Tab Atkins Jr. (Google)

Abstract

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. This module contains the features of CSS level 3 relating to the <image> type and replaced elements. It includes and extends the functionality of CSS level 2 [CSS21], which builds on CSS level 1 [CSS1]. The main extensions compared to level 2 are the generalization of the <url> type to the <image> type, several additions to the ‘<image>’ type, a generic sizing algorithm for images and other replaced content in CSS, and several properties controlling the interaction of replaced elements and CSS's layout models.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The (archived) public mailing list www-style@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “css3-images” in the subject, preferably like this: “[css3-images] …summary of comment…

This document was produced by the CSS Working Group (part of the Style Activity).

This document was produced by a group operating under the 5 February 2004 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 specification is a Last Call Working Draft. All persons are encouraged to review this document and send comments to the www-style mailing list as described above. The deadline for comments is 7 February 2012.

The following features are at risk: …

  1. The image() function
  2. The element() function
  3. The "none" and "scale-down" values for ‘object-fit
  4. The ‘image-orientation’ property
  5. The "snap" keyword for ‘image-resolution

Table of contents

1. Introduction

This section is not normative.

In CSS Levels 1 and 2, image values, such as those used in the ‘background-image’ property, could only be given by a single URL value. This module introduces additional ways of representing 2D images, for example as a list of URIs denoting fallbacks, as a reference to an element, or as a gradient.

This module also defines several properties for manipulating raster images and for sizing or positioning replaced elements such as images within the box determined by the CSS layout algorithms. It also defines in a generic way CSS's sizing algorithm for images and other replaced elements.

1.1. Module Interactions

This module defines and extends the ‘<image>’ value type defined in [CSS3VAL]. Furthermore it replaces the ‘<url>’ type in the ‘background-image’ and ‘list-style-image’ definitions in CSS1 and CSS2 and adds ‘<image>’ as an alternative to ‘<url>’ in the ‘content’ property's value. It is presumed that CSS specifications beyond CSS2.1 will use the ‘<image>’ notation in place of ‘<url>’ where 2D images are expected. (See e.g. [CSS3BG].)

1.2. Values

This specification follows the CSS property definition conventions from [CSS21]. Value types not defined in this specification are defined in CSS Level 2 Revision 1 [CSS21]. Other CSS modules may expand the definitions of these value types: for example [CSS3COLOR], when combined with this module, expands the definition of the <color> value type as used in this specification.

In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the inherit keyword as their property value. For readability it has not been repeated explicitly.

2. Resolution Units: the <resolution> type

This specification defines the following units as part of the <resolution> value type:

dpi
dots per inch
dpcm
dots per centimeter
dppx
dots per ‘px’ unit

The <resolution> unit represents the size of a single "dot" in a graphical representation by indicating how many of these dots fit in a CSS ‘in’, ‘cm’, or ‘px’. For uses, see e.g. the ‘resolution’ media query in [MEDIAQ] or the ‘image-resolution’ property defined below.

Note that due to the 1:96 fixed ratio of CSS ‘in’ to CSS ‘px’, ‘1dppx’ is equivalent to ‘96dpi’. This corresponds to the default resolution of images displayed in CSS: see ‘image-reslution’.

3. Image Values: the <image> type

The <image> value type denotes a 2D image. It represents either a url reference, image notation, element reference, or gradient notation. Syntactically it is defined as

<image> = <url> | <image-list> | <element-reference>  | <gradient>

Image values can be used in many CSS properties, including the ‘background-image’, ‘list-style-image’, ‘cursor’ properties [CSS21].

3.1. Image References and Image Slices: the ‘url()’ notation

The simplest way to indicate an image is to reference an image file by URL. This is done with the url()’ notation, defined in [CSS21].

In the example below, a background image is specified with ‘url()’ syntax:

background-image: url(wavy.png);

A portion of an image may be referenced (clipped out and used as a standalone image) by use of media fragment identifiers. [MEDIA-FRAGS]

For example, given the following image* and CSS:

[9 circles, with 0 to 8 eighths filled in]
background-image: url('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.

* SVG-in-<img> support required. Click the picture to view the SVG directly.

Note that a legacy UA that doesn't understand the media fragments notation will ignore the fragment and simply display the entirety of an image specified with ‘url’. However, since URLs with media fragment identifiers can also be used in the ‘image()’ notation defined below, authors can take advantage of CSS's forward-compatible parsing rules to provide a fallback when using an image fragment URL:

In the example below, the ‘image()’ notation is used together with the media fragment syntax, so that UAs that don't support media fragments fail to parse the second declaration and use the first.

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

3.2. Image Fallbacks and Annotations: the ‘image()’ notation

The ‘image()’ function allows an author to specify an image with fallback images to be used if the original image can't be decoded or is a type that the browser doesn't recognize. Additionally, the author can specify a color as an ultimate fallback to be used when none of the images can be.

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. [MEDIA-FRAGS]

The ‘image()’ notation is defined as:

<image-list> = image( [ <image-decl> , ]* [ <image-decl> | <color> ] )
<image-decl> = <string> [ ltr | rtl ]?

Each <string> must represent a URL.

Multiple arguments can be given separated by commas, in which case the function represents the first <string> representing an image that the browser can successfully load and display. The final argument can specify a <color> to serve as an ultimate fallback; this can be used, e.g. for ‘background-image’, to ensure adequate contrast if none of the preceding <image-decl>s can be used. If the final argument is a <color>, it represents a solid-color image of the given color with no intrinsic dimensions.

The rule below would tell the UA to load ‘wavy.svg’ if it can; failing that to load ‘wavy.png’; failing that to display ‘wavy.gif’. For example, the browser might not understand how to render SVG images, and the PNG may be temporarily 404 (returning an HTML 404 page, which the browser can't decode as an image) due to a server move, so the GIF is used until one of the previous problems corrects itself.

background-image: image("wavy.svg", 'wavy.png' , "wavy.gif");

The fallback color can be used to ensure that text is still readable even when the image fails to load. For example, the following 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.

At times, one may need a solid-color image for a property or function that does not accept the <color> type directly. The ‘image()’ function can be used for this: by specifying only a color without any URLs, the function immediately falls back to representing a solid-color image of the chosen color.

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

In the above, the background is the image "bg-image.png", overlaid with partially-transparent blue.

Along with each URL, the author may specify a directionality, similar to adding a dir attribute to an element in HTML. The image represented by the function takes on the directionality of the used URL. 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).

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("arrow.png" ltr);">
	<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.

3.3. 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. The syntax for ‘element()’ is:

<element-reference> = element( [<id-selector> | <identifier> ] )

where <id-selector> is an ID selector [SELECT], and <identifier> is an identifer [CSS3VAL].

If the argument to the ‘element()’ function is an ID selector, the function references the element matched by the selector. If it's an identifier, the function references the element whose CSS element reference identifier is the given identifier. (CSS does not define how an element acquires a CSS element reference identifier; that is determined by the host language.)

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 = ...;
	var prevSlide = currentSlide.previousElementSibling;
	var nextSlide = currentSlide.nextElementSibling;
	document.CSSElementMap['prev-slide'] = prevSlide;
	document.CSSElementMap['next-slide'] = nextSlide;
}
</script>
<style>
#prev-preview, #next-preview { 
	position: fixed;
	...
}
#prev-preview { background: element(prev-slide); }
#next-preview { background: element(next-slide); }
</style>
<div id='prev-preview'></div>
<div id='next-preview'></div>
<section class='slide'>...</section>
<section class='slide current-slide'>...</section>
...

In this example, the navigateSlides function updates HTML's CSSElementMap to always point to 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.

Note: A future version of this specification may allow more than just ID selectors to be passed to ‘element()’, allowing an example like this to be done with even less javascript - something like ‘background: element(.current-slide + .slide);’.

The image represented by the ‘element()’ function can vary based on a number of factors. The function must represent the image described by the first set of conditions, following, that are true:

The function doesn't reference an element
The function represents a solid-color transparent-black image with no intrinsic dimensions.
The function references an element that is not rendered, but which provides a paint source

The function represents an image with the dimensions and appearance of the paint source. The host language defines the dimensions 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 included in the page:

<!DOCTYPE html>
<script>
	var canvas = document.createElement('canvas');
	canvas.width = 20; canvas.height = 20;
	document.CSSElementMap.foo = canvas;
	drawAnimation(canvas);
</script>
<ul style="list-style-image: element(foo);">
	<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>
The function references an element that is not rendered
The function references an element that is a descendant of a replaced element

The function represents a solid-color transparent-black image with no intrinsic dimensions.

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

<!DOCTYPE html>
<script>
var p = document.createElement('p');
p.textContent = "one";
document.CSSElementMap.one = p;
</script>
<p id='two' style="display:none;">two</p>
<iframe src="http://example.com">
	<p id='three'>I'm fallback content!</p>
</iframe>
<ul>
	<li style="background: element(one);">
	  A P element doesn't provide a paint source,
	  and it's not rendered unless it's in a document.
	</li>
	<li style="background: element(#two);">
	  Similarly, a display:none element isn't rendered, and 
	  P still doesn't provide a paint source.
	</li>
	<li style="background: element(#three);">
	  The descendants of a replaced element like an IFRAME
	  can't be used in element() either.
	</li>
</ul>
Otherwise

The function represents an image with width and height equal to the bounding box of the referenced element. The image must be constructed by rendering the referenced element and its descendants at the same size that the element would be in its document, over an infinite transparent-black canvas, positioned so that the edges of the referenced element's bounding box is flush with the edges of the image. Note: Because images clip anything outside their bounds by default, this means that decorations that extend outside the bounding box, like box-shadows or some border-images, may be clipped.

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. If the referenced element is broken across pages, the element must be displayed as if the page content areas were joined flush in the pagination direction (elements broken across lines or columns just render with their bounding box, as normal, which may have unintended visual effects).

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; }
#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>

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.

Host languages may define that some elements provide a paint source. Paint sources have an intrinsic width, height, and appearance, separate from the process of rendering, and so may be used as images even when they're not being rendered. Examples of elements that provide paint sources are the <linearGradient>, <radialGradient>, and <pattern> elements in SVG, or the <img>, <video>, and <canvas> elements in HTML.

Detecting and Resolving Circular Relationships Introduced by ‘element()

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.

Populate the dependency graph initially by having every element depend on each of its children. Then, whenever a property on an element A uses the ‘element()’ function to refer to an element B, add an edge to the graph by having A depend on B. If a dependency cycle is detected, any ‘element()’ functions that produced a dependency in the cycle must represent a fully transparent image with no intrinsic dimensions.

Someone else needs to review this and make sure that I'm not missing any cycles.

4. 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 two 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> | <radial-gradient> | <repeating-linear-gradient> | <repeating-radial-gradient> ]

where <linear-gradient>, <radial-gradient>, <repeating-linear-gradient>, and <repeating-radial-gradient> are defined in their applicable sections below.

Gradients are a type of image, and can be used anywhere an image can, such as in the ‘background-image’ or ‘list-style-image’ properties.

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

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.

4.1. Linear Gradients: the ‘linear-gradient()’ notation

A linear gradient is created by specifying a gradient-line and then several colors placed along that line. The image is constructed by creating an infinite canvas and painting it with lines perpendicular to the gradient-line, with the color of the painted line being the color of the gradient-line where the two intersect. This produces a smooth fade from each color to the next, progressing in the specified direction.

4.1.1. linear-gradient() syntax


<linear-gradient> = linear-gradient(
	[ [ <angle> | to <side-or-corner> ] ,]? 
	<color-stop>[, <color-stop>]+
)

<side-or-corner> = [left | right] || [top | bottom]

The first argument to the function specifies the gradient-line, which gives the gradient a direction and determines how color-stops are positioned. It may be omitted; if so, it defaults to "to bottom".

The gradient-line may be specified in two different ways. The first is by specifying the angle the gradient-line should assume; for the purposes of this argument, 0deg points upwards, 90deg points toward the right, and positive angles go clockwise. The starting-point and ending-point of the gradient-line are determined by extending a line in both directions from the center of the gradient box at the angle specified. In the direction of the angle, the ending-point is the point on the gradient-line where a line drawn perpendicular to the gradient-line would intersect the corner of the gradient box in that direction. The starting-point is determined identically, except in the opposite direction of the angle.

Alternately, the direction may be specified with keywords that denote the direction. If the argument is ‘to top’, ‘to right’, ‘to bottom’, or ‘to left’, the gradient must be rendered identically to ‘0deg’, ‘90deg’, ‘180deg’, or ‘270deg’, respectively. If the argument specifies a corner to angle towards, the gradient must be rendered identically to an angle-based gradient with an angle chosen such that the endpoint of the gradient is in the same quadrant as the indicated corner, and a line drawn perpendicular to the gradient-line through the center of the gradient box intersects the two neighboring corners.

It is expected that the next level of this module will provide the ability to define the gradient's direction relative to the current text direction and writing-mode.

[An image showing a box with a background shading gradually from white in the bottom-left corner to black in the top-right corner.  There is a line, illustrating the gradient-line, angled at 45 degrees and passing through the center of the box.  The starting-point and ending-point of the gradient-line are indicated by the intersection of the gradient-line with two additional lines that pass through the bottom-left and top-right corners of the box.]

This example illustrates visually how to calculate the gradient-line from the rules above. This shows the starting and ending-point of the gradient-line, along with the actual gradient, produced by an element with ‘background: linear-gradient(45deg, white, black);’.

Notice how, though the starting-point and ending-point are outside of the box, they're positioned precisely right so that the gradient is pure white exactly at the corner, and pure black exactly at the opposite corner. That's intentional, and will always be true for linear gradients.

The gradient's color stops are typically placed between the starting-point and ending-point on the gradient-line, but this isn't required - the gradient-line extends infinitely in both directions. The starting-point and ending-point are merely arbitrary location markers - the starting-point defines where 0%, 0px, etc are located when specifying color-stops, and the ending-point defines where 100% is located. Color-stops are allowed to have positions before 0% or after 100%.

4.1.2. Linear Gradient Examples

All of the following ‘linear-gradient()’ examples are presumed to be backgrounds applied to a box that is 200px wide and 100px tall.

Below are various ways of specifying a basic vertical gradient:

linear-gradient(yellow, blue);
linear-gradient(to bottom, yellow, blue);
linear-gradient(180deg, yellow, blue);
linear-gradient(to top, blue, yellow);
linear-gradient(to bottom, yellow 0%, blue 100%);

This demonstrates the use of an angle in the gradient. Note that, though the angle is not exactly the same as the angle between the corners, the gradient-line is still sized so as to make the gradient yellow exactly at the upper-left corner, and blue exactly at the lower-right corner.

linear-gradient(135deg, yellow, blue);
linear-gradient(-45deg, blue, yellow);

This demonstrates a 3-color gradient, and how to specify the location of a stop explicitly:

linear-gradient(yellow, blue 20%, #0f0);

This demonstrates* a corner-to-corner gradient specified with keywords. Note how the gradient is red and blue exactly in the bottom-left and top-right corners, respectively, exactly like the second example. Additionally, the angle of the gradient is automatically computed so that the color at 50% (in this case, white) stretches across the top-left and bottom-right corners.

linear-gradient(to top right, red, white, blue)

(Image requires SVG)

* SVG-in-HTML support required to view the image.

4.2. Radial Gradients: the ‘radial-gradient()’ notation

In a radial gradient, rather than colors smoothly fading from one side of the gradient box to the other as with linear gradients, they instead emerge from a single point and smoothly spread outward in a circular or elliptical shape.

A radial gradient is specified by indicating the center of the gradient (where the 0% ellipse will be) and the size and shape of the ending shape (the 100% ellipse). Color stops are given as a list, just as for ‘linear-gradient()’. Starting from the center and progressing towards (and potentially beyond) the ending shape concentric ellipses are drawn and colored according to the specified color stops.

4.2.1. radial-gradient() Syntax

The radial gradient syntax is defined as follows:

<radial-gradient> = radial-gradient(
  [ [ <shape> || <size> ] [ at <position> ]? , |
    at <position>, 
  ]?
  <color-stop> [ , <color-stop> ]+
)

Here is an example of a circular radial gradient 5em wide and positioned with its center in the top left corner:

radial-gradient(5em circle at top left, yellow, blue)

The arguments are defined as follows:

<position>
Determines the center of the gradient. The <position> value type (which is also used for ‘background-position’) is defined in [CSS3VAL], 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’.
<shape>
Can be either ‘circle’ or ‘ellipse’; determines whether the gradient's ending shape is a circle or an ellipse, respectively. If <shape> is omitted, the ending shape defaults to a circle if the <size> is a single <length>, and to an ellipse otherwise.
<size>

Determines the size of the gradient's ending shape. If omitted it defaults to ‘farthest-corner’. It can be given explicitly or by keyword. For the purpose of the keyword definitions, consider the gradient box edges as extending infinitely in both directions, rather than being finite line segments.

Both ‘circle’ and ‘ellipse’ gradients accept the following keywords as their <size>:

closest-side
The ending shape is sized so that that it exactly meets the side of the gradient box closest to the gradient's center. If the shape is an ellipse, it exactly meets the closest side in each dimension.
farthest-side
Same as ‘closest-side’, except the ending shape is sized based on the farthest side(s).
closest-corner
The ending shape is sized so that that it passes through the corner of the gradient box closest to the gradient's center. If the shape is an ellipse, the ending shape is given the same aspect-ratio it would have if ‘closest-side’ were specified.
farthest-corner
Same as ‘closest-corner’, except the ending shape is sized based on the farthest corner. If the shape is an ellipse, the ending shape is given the same aspect ratio it would have if ‘farthest-side’ were specified.

If <shape> is specified as ‘circle’ or is omitted, the <size> may be given explicitly as:

<length>

Gives the radius of the circle explicitly. Negative values are invalid.

Note that percentages are not allowed here; they can only be used to specify the size of an elliptical gradient, not a circular one. This restriction exists because there is are multiple reasonable answers as to which dimension the percentage should be relative to. A future level of this module may provide the ability to size circles with percentages, perhaps with more explicit controls over which dimension is used.

If <shape> is specified as ‘ellipse’ or is omitted, <extent> may instead be given explicitly as:

[<length> | <percentage>]{2}
Gives the size of the ellipse explicitly. The first value represents the horizontal radius, the second the vertical radius. Percentages values are relative to the corresponding dimension of the gradient box. Negative values are invalid.

Expanded with the above definitions, the grammar becomes:

<radial-gradient> = radial-gradient(
  [ [ circle               || <length> ]                          [ at <position> ]? , | 
    [ ellipse              || [ <length> | <percentage> ]{2} ]    [ at <position> ]? , |
    [ [ circle | ellipse ] || <extent-keyword> ]                  [ at <position> ]? , |
    at <position> ,
  ]?
  <color-stop> [ , <color-stop> ]+
)
<extent-keyword> = closest-corner | closest-side | farthest-corner | farthest-side

4.2.2. Placing Color Stops

Color-stops are placed on a gradient-ray, similar to the gradient-line of linear gradients. The gradient-ray is anchored at the center of the gradient and extends toward the right. The 0% location is at the start of the gradient-ray, and the 100% location is on the point where the gradient-ray intersects the ending shape. Negative locations can be specified; though negative locations are never directly consulted for rendering, they can affect the color of non-negative locations on the gradient-ray through interpolation. For example, ‘radial-gradient(red -50px, yellow 100px)’ produces an elliptical gradient that starts with a reddish-orange color in the center (specifically, #f50) and transitions to yellow. Locations greater than 100% simply specify a location a correspondingly greater distance from the center of the gradient.

When drawing the concentric ellipses of the gradient, the color of each ellipse is the color of the gradient-ray at the point where the ellipse intersects the ray.

4.2.3. Degenerate Radial Gradients

Some combinations of position, size, and shape will produce a circle or ellipse with a radius of 0. This will occur, for example, if the center is on a gradient box edge and ‘closest-side’ or ‘closest-corner’ is specified or if the size and shape are given explicitly and either of the radiuses is zero. In these degenerate cases, the gradient must be be rendered as follows:

If the ending shape is a circle with zero width or height:
Render as if the ending shape was a circle whose radius was an arbitrary very small number greater than zero. This will make the gradient continue to look like a circle.
If the ending shape has zero width (regardless of the height):
Render as if the ending shape was an ellipse whose height was an arbitrary very large number and whose width was an arbitrary very small number greater than zero. This will make the gradient look similar to a horizontal linear gradient that is mirrored across the center of the ellipse. It also means that all color-stop positions specified with a percentage resolve to ‘0px’.
Otherwise, if the ending shape has zero height:
Render as if the ending shape was an ellipse whose width was an arbitrary very large number and whose height was an arbitrary very small number greater than zero. This will make the gradient look like a solid-color image equal to the color of the last color-stop, or equal to the average color of the gradient if it's repeating.

4.2.4. Radial Gradient Examples

All of the following examples are applied to a box that is 200px wide and 100px tall.

These examples demonstrate different ways to write the basic syntax for radial gradients:

radial-gradient(yellow, green);
radial-gradient(ellipse at center, yellow 0%, green 100%);
radial-gradient(farthest-corner at 50% 50%, yellow, green);

radial-gradient(circle, yellow, green);

radial-gradient(red, yellow, green);

This image shows a gradient originating from somewhere other than the center of the box:

radial-gradient(farthest-side at left bottom, red, yellow 50px, green);

Here we illustrate a ‘closest-side’ gradient.

radial-gradient(closest-side at 20px 30px, red, yellow, green);
radial-gradient(20px 30px at 20px 30px, red, yellow, green);

radial-gradient(closest-side circle at 20px 30px, red, yellow, green);
radial-gradient(20px 20px at 20px 30px, red, yellow, green);

4.3. Repeating Gradients: the ‘repeating-linear-gradient()’ and ‘repeating-radial-gradient()’ notations

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

When rendered, however, the color-stops are repeated infinitely in both directions, with their positions shifted by multiples of the difference between the last specified color-stop's position and the first specified color-stop's position. For example, ‘repeating-linear-gradient(red 10px, blue 50px)’ is equivalent to ‘linear-gradient(..., red -30px, blue 10px, red 10px, blue 50px, red 50px, blue 90px, ...)’. Note that the last color-stop and first color-stop will always coincide at the boundaries of each group, which will produce sharp transitions if the gradient does not start and end with the same color.

Repeating gradient syntax is basically identical to that of non-repeating gradients:

repeating-linear-gradient(red, blue 20px, red 40px)

repeating-radial-gradient(red, blue 20px, red 40px)

repeating-radial-gradient(circle closest-side at 20px 30px, red, yellow, green 100%, yellow 150%, red 200%)

If the distance between the first and last color-stops is non-zero, but is small enough that the implementation knows that the physical resolution of the output device is insufficient to faithfully render the gradient, the implementation must find the average color of the gradient and render the gradient as a solid-color image equal to the average color.

If the distance between the first and last color-stops is zero (or rounds to zero due to implementation limitations), the implementation must find the average color of a gradient with the same number and color of color-stops, but with the first and last color-stop an arbitrary non-zero distance apart, and the remaining color-stops equally spaced between them. Then it must render the gradient as a solid-color image equal to that average color.

If the height of a repeating radial gradient is zero, or is close enough to zero that the implementation knows that the physical resolution of the output device is insufficient to faithfully render the gradient, the implementation must find the average color of the gradient and render the gradient as a solid-color image equal to the average color.

To find the average color of a gradient, run these steps:

  1. Define list as an initially-empty list of premultiplied RGBA colors, and total-length as the distance between first and last color stops.
  2. For each adjacent pair of color-stops, define weight as half the distance between the two color-stops, divided by total-length. Add two entries to list, the first obtained by representing the color of the first color-stop in premultiplied sRGBA and scaling all of the components by weight, and the second obtained in the same way with the second color-stop.
  3. Sum the entries of list component-wise to produce the average color, and return it.

As usual, implementations may use whatever algorithm they wish, so long as it produces the same result as the above.

For example, the following gradient is rendered as a solid light-purple image (equal to rgb(75%,50%,75%)):

repeating-linear-gradient(red 0px, white 0px, blue 0px);

The following gradient would render the same as the previous under normal circumstances (because desktop monitors can't faithfully render color-stops 1/10th of a pixel apart), but would render as a normal repeating gradient if, for example, the author applied "zoom:100;" to the element on which the gradient appears:

repeating-linear-gradient(red 0px, white .1px, blue .2px);

4.4. Gradient Color-Stops

<color-stop> = <color> [ <percentage> | <length> ]?

Color-stops are points placed along the line defined by the gradient-line at the beginning of the rule. Color-stops must be specified in order. Percentages refer to the length of the gradient-line, with 0% being at the starting point and 100% being at the ending point. Lengths are measured from the starting-point in the direction of the ending-point. Color-stops are usually placed between the starting-point and ending-point, but that's not required; the gradient-line extends infinitely in both directions, and a color-stop can be placed at any position on the line.

At each color-stop, the line is the color of the color-stop. Between two color-stops, the line's color is linearly interpolated between the colors of the two color-stops, with the interpolation taking place in premultiplied RGBA space. Before the first color-stop, the line is the color of the first color-stop. After the last color-stop, the line is the color of the last color-stop.

The following steps must be applied in order to process the list of color-stops. After applying these rules, all color-stops will have a definite position and they will be in ascending 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 has a position that is less than the specified position of any color-stop before it in the list, set its position to be equal to the largest specified position of any color-stop 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.

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

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)
   =13=>
   linear-gradient(red 40%, white 60%, black 80%, blue 100%)

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

4. linear-gradient(red -50px, white, blue)
   =13=>
   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)
   =12=>
   linear-gradient(red 0%, white 0%, black 150%, blue 150%)

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

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)

In premultiplied space, transitions to or from "transparent" always look nice:

(Image requires SVG)

On the other hand, if a gradient were to incorrectly transition in non-premultiplied space, the colors near "transparent" would noticeably darken to a grayish color, because "transparent" is actually a shorthand for ‘rgba(0,0,0,0)’, or transparent black:

(Image requires SVG)

* SVG-in-HTML support required to view the images.

Note: It is recommended that authors not mix different types of units, such as px, em, or %, in a single rule, 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 require any fix-up as long as 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.

Note: The definition and implications of "premultiplied" color spaces are given elsewhere in the technical literature, but a quick primer is given here to illuminate the process. Given a color expressed as an rgba() 4-tuple, one can convert this to a premultiplied representation by multiplying the red, green, and blue components by the alpha component. 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%) and rgba(0,0,255,100%) or rgba(255,0,0,100%) and rgba(255,0,0,0%)) 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.

5. Sizing Images and Objects in CSS

Images used in CSS may come from a number of sources, from binary image formats (such as gif, jpeg, etc), dedicated markup formats (such as SVG), and CSS-specific formats (such as the linear-gradient() value type defined in this specification). As well, a document may contain many other types of objects, such as video, plugins, or nested documents. These images and objects (just objects hereafter) may offer many types of sizing information to CSS, or none at all. This section defines generically the size negotiation model between the object and the CSS layout algorithms.

5.1. Object-Sizing Terminology

In order to define this handling, we define a few terms, to make it easier to refer to various concepts:

intrinsic dimensions

An object's intrinsic dimensions are its preferred, natural width, height, and aspect ratio, if they exist. There can be an intrinsic height and intrinsic width, defining a definite rectangle and an intrinsic aspect ratio. (Most bitmap images fall into this category.) There can be only an intrinsic aspect ratio defining the relation of the width to the height, but no definite size. (SVG images designed to scale may fall into this category.) There can be just an intrinsic height or width. Or there can be no intrinsic dimensions at all, implying that the object has no preferred size or aspect ratio. (Embedded documents are often assumed to have no intrinsic size, as are CSS gradients, defined in this specification.)

If an object (such as an icon) has multiple sizes, then the largest size is taken as its intrinsic size. If it has multiple aspect ratios at that size, or has multiple aspect ratios and no size, then the aspect ratio closest to the aspect ratio of the default object size is used.

specified size
The specified size of an object is given by CSS, such as through the ‘width’ and ‘height’ or ‘background-size’ properties. The specified size can be a definite width and height, a set of constraints, or a combination thereof.
concrete object size
The concrete object size is the result of transforming the intrinsic dimensions into a concrete size, based on the specified size and the default object size. A concrete object size always has a definite height and width.
default object size

The default object size is a rectangle with a definite height and width used to determine the concrete object size when both the intrinsic dimensions and specified size are missing dimensions. It varies based on the context in which that the image is being laid out.

The following list defines the default object size of properties and contexts that appear in CSS 2.1, plus ‘border-image’ from CSS 3 Backgrounds & Borders. Newer modules that accept an ‘<image>’ component value in a new context must define the default object size in that context.

background-image
The default object size is the size of the element's background positioning area. [CSS3BG]
list-style-image
The default object size is a 1em square. [CSS21]
border-image
The default object size is the size of the element's border image area. [CSS3BG]
cursor
The default object size is a UA-defined size that should be based on the size of a typical cursor on the UA's operating system. [CSS21]
replaced elements
The default object size is a rectangle 300px wide and 150px tall. [CSS21]

5.2. CSS⇋Object Negotiation

Objects in CSS are sized and rendered as follows:

  1. When an image or object is specified in a document, such as through a ‘url()’ value in a ‘background-image’ property or an src attribute on an <img> element, CSS queries the object for its intrinsic dimensions.
  2. Using the intrinsic dimensions, the specified size, and the default object size for the context the image or object is used in, CSS then computes a concrete object size. (See the following section.) This defines the size and position of the region the object will render in.
  3. CSS asks the object to render itself at the concrete object size. CSS does not define how objects render when the concrete object size is different from the object's intrinsic dimensions. The object may adjust itself to match the concrete object size in some way, or even render itself larger or smaller than the concrete object size to satisfy sizing constraints of its own.
  4. Unless otherwise specified by CSS, the object is then clipped to the concrete object size.

5.3. Default Concrete Object Size Resolution

In the absence of more specific rules, an object's intrinsic dimensions are resolved to a concrete object size as follows:

If the specified size has additional constraints, the concrete object size must be sized to satisfy those constraints. For example, the ‘min-width’, ‘min-height’, ‘max-width’, and ‘max-height’ properties specify slightly more complex handling for sizing replaced elements, and ‘background-repeat: round’ can further adjust the size calculated by ‘background-size’ so that the image fits a whole number of times into the background positioning area.

5.4. Sizing Objects: the ‘object-fit’ property

Name: object-fit
Value: fill | contain | cover | none | scale-down
Initial: fill
Applies to: replaced elements
Inherited: no
Percentages: N/A
Media: visual
Computed value: specified value

The ‘object-fit’ property specifies how the contents of a replaced element should be scaled relative to the box established by its used height and width. It also enables scaling a replaced element up to a specified maximum size or down to a specified minimum size while preserving its aspect ratio.

Not all replaced elements can be scaled, but images typically can.

If the replaced element's content does not have an intrinsic aspect ratio, all of the values for ‘object-fit’ are treated as ‘fill’. Otherwise, the object is scaled as follows:

fill

Set the object's size to the concrete object size obtained by running the object sizing algorithm with a specified size and a default object size equal to the replaced element's used width and height.

This will make the contents exactly fill the replaced element's content box.

contain

Determine the used ‘height’ and ‘width’ of the element as usual, except: If both ‘height’ and ‘width’ are ‘auto’, and the used value of at least one of ‘max-width’ and ‘max-height’ is not ‘none’, then compute the element's used width and used height as though the intrinsic dimensions of the contents were infinitely large numbers whose ratio is the actual intrinsic ratio of the contents. This will proportionally scale the used width and height up to the given maximum constraints.

Set the concrete object size to the largest width and height that has the same aspect ratio as the object's intrinsic aspect ratio, and additionally has neither width nor height larger than the replaced element's used width and height, respectively.

cover

Determine the used ‘height’ and ‘width’ of the element as usual, except: If both ‘height’ and ‘width’ are ‘auto’, and the used value of at least one of ‘min-width’ and ‘min-height’ is not ‘none’, then compute the element's used width and used height as though the intrinsic dimensions of the contents were infinitely small numbers whose ratio is the actual intrinsic ratio of the contents. This will proportionally scale the used width and height down to the given minimum constraints.

Set the concrete object size to the smallest width and height that has the same aspect ratio as the object's intrinsic aspect ratio, and additionally has neither width nor height smaller than the replaced element's used width and height, respectively.

none

Set the content's size to the concrete object size obtained by running the object sizing algorithm with no specified size, and a default object size equal to the replaced element's used width and height.

scale-down

Size the content as if ‘none’ or ‘contain’ were specified, whichever would result in a smaller concrete object size.

Note that both ‘none’ and ‘contain’ respect the content's intrinsic aspect ratio, so the concept of "smaller" is well-defined.

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 (shownwith a green background), using the initial value for ‘object-position’. The fifth value, ‘scale-down, in this case looks identical to contain.

Find some good use-cases and make examples out of them.

Note: the ‘object-fit’ property has similar semantics to the fit attribute in [SMIL10].

Note: Per the CSS⇋Object 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.

User agents MAY accept ‘image-fit’ as an alias for ‘object-fit’, as a previous version of this specification used that name. Authors must not use ‘image-fit’ in their stylesheets.

5.5. Positioning Objects: the ‘object-position’ property

Name: object-position
Value: <position>
Initial: 50% 50%
Applies to: replaced elements
Inherited: no
Percentages: refer to width and height of box itself
Media: visual
Computed value: specified value

The ‘object-position’ property determines the alignment of the replaced element inside its box. The <position> value type (which is also used for ‘background-position’) is defined in [CSS3VAL], and is resolved using the concrete object size as the object area and the content box as the positioning area.

Note that areas of the box not covered by the replaced element will show the element's background.

Find some good use-cases and make examples out of them.

User agents MAY accept ‘image-position’ as an alias for ‘object-position’, as a previous version of this specification used that name. Authors must not use ‘image-position’ in their stylesheets.

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
Media: visual
Computed value: as specified, except with <resolution> possibly altered by computing for ‘snap’ (see below)

The ‘image-resolution’ property specifies the intrinsic resolution of all raster images used in or on the element. (As vector formats such as SVG do not have an intrinsic resolution, this property has no effect on vector images.) The intrinsic resolution of an image is used to determine the image's intrinsic size. Affected images include images in the element's content (e.g. replaced elements and/or generated content), background images, list markers, etc. Values have the following meanings:

<resolution>
Specifies the intrinsic resolution explicitly.
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 ‘1ddpx’.
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.

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. In this rule:

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

6.2. Orienting an Image on the Page: the ‘image-orientation’ property

Sometimes images from camera phones, digital cameras or scanners are encoded sideways. For example, the first row of image data can represent the leftmost or rightmost column of image pixels. Furthermore, often such devices have limited resources, and do not have the capability to rotate the image into an upright orientation. However, this type of device may have internal knowledge or can accept input from its user as to the rotational correction to perform. The ‘image-orientation’ property provides a way to apply an ”out-of-band“ rotation to image source data to correctly orient an image.

Note this facility is not intended to specify layout transformations such as arbitrary rotation or flipping the image in the horizontal or vertical direction. (See [CSS3-2D-TRANSFORMS] for a feature designed to do that.) It is also not needed to correctly orient an image when printing in landscape versus portrait orientation, as that rotation is done as part of layout. (See [CSS3PAGE].) It should only be used to correct incorrectly-oriented images.

Name: image-orientation
Value: <angle>
Initial: 0deg
Applies to: images
Inherited: no
Media: visual
Computed value: specified value, rounded and normalized (see text)

This property specifies an orthogonal rotation to be applied to an image before it is laid out. CSS layout processing applies to the image after rotation. This implies, for example:

Positive values cause the image to be rotated to the right (in a clockwise direction), while negative values cause a rotation to the left. The computed value of the property is calculated by rounding the specified angle to the nearest quarter-turn (90deg, 100grad, .25turn, etc.), rounding away from 0 (that is, 45deg is rounded to 90deg, while -45deg is rounded to -90deg), then moduloing the value by 1 turn (360deg, 400grad, etc.).

If the image itself is transformed in some way (for example, if the content of an element is provided by the ‘image()’ function with a directionality opposite the element's directionality), the image's transformation must be applied before ‘image-orientation’ is. As well, ‘image-orientation’ must be applied before any further transformation of the element, such as through CSS Transforms.

Note that in CSS, orientation data encoded in the image (e.g. EXIF data) is ignored. Is this an issue? What do printers do?

The following example rotates the image 90 degrees clockwise:

img.ninety     { image-orientation: 90deg }
...
<img class="ninety" src=... />
		

The same effect could be achieved with, for example, an angle of -270deg or 450deg.

7. Conformance

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

7.2. Conformance Classes

Conformance to CSS Image Values and Replaced Content Module Level 3 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 CSS Image Values and Replaced Content Module Level 3 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 CSS Image Values and Replaced Content Module Level 3 if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by CSS Image Values and Replaced Content Module Level 3 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 CSS Image Values and Replaced Content Module Level 3 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.

7.3. Partial Implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

7.4. Experimental Implementations

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

7.5. Non-Experimental Implementations

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

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

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

7.6. CR Exit Criteria

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

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

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

Acknowledgments

Thanks to the Webkit team, Brad Kemper, Brian Manthos, and Alan Gresley for their contributions to the definition of gradients; to Melinda Grant for her work on ‘object-fit’, ‘object-position’, and ‘image-orientation’; to Robert O'Callahan for the definition of ‘element()’; and to Michael Day, Håkon Lie, and Shinyu Murakami for ‘image-resolution’.

References

Normative references

[CSS21]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-CSS2-20110607
[CSS3VAL]
Håkon Wium Lie; Tab Atkins; Elika J. Etemad. CSS Values and Units Module Level 3. 6 September 2011. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2011/WD-css3-values-20110906/
[MEDIA-FRAGS]
Raphaël Troncy; et al. Media Fragments URI 1.0. 1 December 2011. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2011/CR-media-frags-20111201/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[SELECT]
Tantek Çelik; et al. Selectors Level 3. 29 September 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-css3-selectors-20110929/

Other references

[CSS1]
Håkon Wium Lie; Bert Bos. Cascading Style Sheets (CSS1) Level 1 Specification. 11 April 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-CSS1-20080411
[CSS3-2D-TRANSFORMS]
Dean Jackson; David Hyatt; Chris Marrin. CSS 2D Transforms Module Level 3. 1 December 2009. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2009/WD-css3-2d-transforms-20091201
[CSS3BG]
Bert Bos; Elika J. Etemad; Brad Kemper. CSS Backgrounds and Borders Module Level 3. 15 February 2011. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2011/CR-css3-background-20110215
[CSS3COLOR]
Tantek Çelik; Chris Lilley; L. David Baron. CSS Color Module Level 3. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-css3-color-20110607
[CSS3PAGE]
Håkon Wium Lie; Melinda Grant. CSS3 Module: Paged Media. 10 October 2006. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2006/WD-css3-page-20061010
[MEDIAQ]
Håkon Wium Lie; et al. Media Queries. 27 July 2010. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2010/CR-css3-mediaqueries-20100727/
[SMIL10]
Philipp Hoschka. Synchronized Multimedia Integration Language (SMIL) 1.0 Specification. 15 June 1998. W3C Recommendation. URL: http://www.w3.org/TR/1998/REC-smil-19980615

Index

Property index

Property Values Initial Applies to Inh. Percentages Media
Name: Value: Initial: Applies to: Inherited: Media: Computed value:
Name: Value: Initial: Applies to: Inherited: Media: Computed value:
Name: Value: Initial: Applies to: Inherited: Percentages: Media:
Name: Value: Initial: Applies to: Inherited: Percentages: Media: