Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 4 relating to the <image> type and replaced elements. It includes and extends the functionality of CSS Images Level 3. The main extensions from level 3 are ...
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.
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 “css4-images” in the subject, preferably like this: “[css4-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 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.
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].)
Of the properties defined in this module, ‘ only
’image-resolution'applies to ::first-line and
::first-letter.
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
CSS-wide
keywords (such as ‘inherit’)
as their property value. For readability it has not been repeated
explicitly.
This specification defines the following units as part of the <resolution> value type:
dpi’
dpcm’
dppx’
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-resolution’.
The following @media rule uses Media Queries [MEDIAQ] to assign some special
style rules to devices that use two or more device pixels per CSS
‘px’ unit. For example, it might use
borders with half-pixel widths for "hairline" borders.
@media (min-resolution: 2dppx) { ... }
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-list> | <element-reference> | <gradient>
An ‘<image>’ can be used in many CSS properties,
including the ‘background-image’,
‘list-style-image’, and
‘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. An invalid image is
rendered as a solid-color ‘transparent’
image with no intrinsic dimensions. However, invalid images have special behavior in
some contexts, such as the ‘image()’
notation.
<url>’ type and
‘url()’ notation The simplest way to indicate an image is to reference an image file by
URL. This can be done with the ‘url()’ notation, defined in [CSS3VAL].
In the example below, a background image is specified with
‘url()’syntax:
background-image: url(wavy.png);
If the UA cannot download, parse, or otherwise successfully display the contents at the URL as an image, it must be treated as an invalid image.
image()’ notationThe ‘image()’ function allows an
author to:
The ‘image()’ notation is defined
as:
<image-list> = image( [ <image-decl> , ]* [ <image-decl> | <color> ] ) <image-decl> = [ <url> | <string> | <element-reference> ]
Each ‘<string>’ or ‘<url>’ inside ‘image()’ represents an image, just as if the ‘url()’
notation had been used. As usual for URLs in CSS, relative URLs are
resolved to an absolute URL (as described in Values & Units [CSS3VAL]) when a
specified ‘image()’ value is computed.
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:
![[9 circles, with 0 to 8 eighths filled in]](sprites.svg){kind=icon}
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.
* SVG-in-<img> support required. Click the picture to view the SVG directly.
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 */
Multiple ‘<image-decl>s’ can be given separated by
commas, in which case the function represents the first image that's not
an invalid image. 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. If all of
the provided ‘<image-decl>s’ are invalid images and a fallback color was
not provided as the last argument, the entire ‘image()’ function must be treated as an invalid image.
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 due to a server move (returning an HTML 404 page, which
the browser can't decode as an image), 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.
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. This error-handling is limited to image(), and not in the definition of URL, for legacy compat reasons.
For example, if a future specification defined a way to refer to a specific frame of an animated GIF with a fragment identifier, an author could write the following to get newer browsers to use the GIF's frame, and older browsers to instead download the fallback image:
background-image: image('cat_meme.gif#frame=5', 'lolcat.png');
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 ‘<image-decl>’, the author may specify a
directionality, similar to adding a dir attribute to an
element in HTML. The ‘image()’ function
takes on the directionality of the used ‘<image-decl>’,
if any. 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.
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 that 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-reference> = element( <id-selector> )
where ‘<id-selector>’ is an ID
selector [SELECT].
The ‘element()’ function references
the element matched by its argument. 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:
The function represents an image with its intrinsic size equal to the decorated bounding box of the referenced element:
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.
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. [[!CSS-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; }
#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>
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>
For example, all of the following ‘element()’ uses will result in a transparent
background:
<!DOCTYPE html> <p id='one' style="display:none;">one</p> <iframe src="http://example.com"> <p id='two'>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>
#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.
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 rendered.
In HTML, the <img>, <video>, and
<canvas> elements provide paint sources (defined in each
element's section in HTML5).
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:
px’ unit.
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.
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 by keeping track of a dependency graph and using common
cycle-detection algorithms.
The dependency graph consists of edges such that:
element()’ function pointing to an element B, A
depends on B
If the graph contains a cycle, any ‘element()’ functions participating in the cycle
must represent a fully transparent image with no intrinsic dimensions.
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.
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:
<image-combination> = cross-fade( <image>, <image>, <percentage> )
The function represents an image generated by combining the first and
second image (referred to in this section as the "start" and "end" images,
respectively). The percentage represents how far along the transformation
is, with 0% representing the start image, 100% representing the end image,
and percentages between that representing corresponding combinations of
the two images. The <percentage> must be between 0% and
100% inclusive; any other value is invalid.
More precisely, given ‘cross-fade(A,B,p)’, where A and
B are images and p is a percentage between 0% and
100%, the function represents an image with width equal to
widthA × (1-p) + widthB
× p and height equal to heightA ×
(1-p) + heightB × p. The contents of
the image must be constructed by first scaling A and
B to the size of the generated image, then applying
dissolve(A,1-p) plus
dissolve(B,p). The
"dissolve()" function and "plus" compositing operator are defined in the
literature by Porter-Duff.
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 notations 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> ]
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.
linear-gradient()’ notationA 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.
The linear gradient syntax is:
<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's direction may be specified in two ways:
0deg’ points upward, and positive angles represent
clockwise rotation, so ‘90deg’ point
toward the right.
If the argument is ‘to top’,
‘to right’, ‘to
bottom’, or ‘to left’,
the angle of the gradient line is
‘0deg’, ‘90deg’, ‘180deg’, or ‘270deg’, respectively.
If the argument instead specifies a corner of the box such as
‘to top left’, the gradient line must be angled such that
it points into the same quadrant as the specified corner, and is
perpendicular to a line intersecting the two neighboring corners of the
gradient box. This
causes a color-stop at 50% to intersect the two neighboring corners (see
example).
Starting from the center of the gradient box, extend a line at the specified angle in both directions. 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 the specified direction. The starting point is determined identically, but in the opposite direction.
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.
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%.
The color of the gradient at any point is determined by finding the unique line passing through that point that is perpendicular to the gradient line. The point's color is the color of the gradient line at the point where this line intersects it.
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:
![[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.]](gradient-diagram.png)
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)
* SVG-in-HTML support required to view the image.
radial-gradient()’ notationIn 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 uniformly-scaled concentric
ellipses are drawn and colored according to the specified color stops.
The radial gradient syntax is:
<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:
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’.
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.
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.
If the ending-shape is an ellipse, its axises are aligned with the horizontal and vertical axises.
Both ‘circle’ and ‘ellipse’ gradients accept the following keywords
as their <size>:
closest-side’
farthest-side’
closest-side’, except
the ending shape is sized based on
the farthest side(s).
closest-corner’
closest-side’ were specified.
farthest-corner’
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:
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, <size> may instead be given explicitly as:
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
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. A color-stop can be placed
at a negative location; though the negative region of the gradient ray is never directly consulted
for rendering, color stops placed there can affect the color of
non-negative locations on the gradient
ray through interpolation or repetition (see repeating gradients). 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.
The color of the gradient at any point is determined by first finding the unique ellipse passing through that point with the same center, orientation, and ratio between major and minor axises as the ending-shape. The point's color is then the color of the gradient ray at the location where this ellipse intersects it.
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:
0px’.
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);
repeating-linear-gradient()’ and ‘repeating-radial-gradient()’ notationsIn addition to <linear-gradient> and <radial-gradient>, this specification defines <repeating-linear-gradient> and <repeating-radial-gradient> values. These two notations 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:
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);
<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:
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:
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, and thus the colors transition to/from black while the opacity
transitions:
* 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.
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.
In order to define this handling, we define a few terms, to make it easier to refer to various concepts:
The term intrinsic dimensions refers to the set of the intrinsic height, intrinsic width, and intrinsic aspect ratio (the ratio between the width and height), each of which may or may not exist for a given object. These intrinsic dimensions represent a preferred or natural size of the object itself; that is, they are not a function of the context in which the object is used. CSS does not define how the intrinsic dimensions are found in general.
Raster images are an example of an object with all three intrinsic
dimensions. SVG images designed to scale might have only an intrinsic
aspect ratio; SVG images can also be created with only an intrinsic
width or height. CSS gradients, defined in this specification, are an
example of an object with no intrinsic dimensions at all. Another
example of this is embedded documents, such as the
<iframe> element in HTML. An object cannot have only two
intrinsic dimensions, as any two automatically define the third.
If an object (such as an icon) has multiple sizes, then the largest size (by area) 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. Determine this by seeing which aspect ratio produces the largest area when fitting it within the default object size using a contain fit; if multiple sizes tie for the largest area, the wider size is chosen as its intrinsic size.
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.
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.
Objects in CSS are sized and rendered as follows:
url()’ value in a ‘background-image’ property or an
src attribute on an <img> element, CSS
queries the object for its intrinsic
dimensions.
Currently the rules for sizing objects are described in each context that such objects are used. This section defines some common sizing constraints and how to resolve them so that future specs can refer to them instead of redefining size resolution in each instance.
The default sizing algorithm is a set of rules commonly used to find an object's concrete object size. It resolves the simultaneous constraints presented by the object's intrinsic dimensions and either an unconstrained specified size or one consisting of only a definite width and/or height.
Some object sizing rules (such as those for ‘list-style-image’) correspond exactly to the
default sizing algorithm.
Others (such as those for ‘border-image’) invoke the default sizing
algorithm but also apply additional sizing rules before arriving at a
final concrete object size.
The default sizing algorithm is defined as follows:
Two other common specified sizes are the contain constraint and the cover constraint, both of which are resolved against a specified constraint rectangle using the object's intrinsic aspect ratio:
In both cases, if the object doesn't have an intrinsic aspect ratio, the concrete object size is the specified constraint rectangle.
The following examples show how the CSS 2.1 and CSS3 Backgrounds & Borders sizing algorithms correspond to concepts defined in this specification.
background-image’
background-size’ property can
give a sizing constraint, invoking either the default sizing algorithm or
one of the contain or cover
constraints. The concrete object size is further adjusted in later steps
if ‘background-repeat’ has a
‘round’ value. [CSS3BG]
list-style-image’
border-image’
border-image-repeat’ property can drop the
specified size in one or more directions and may also apply an
additional rounding step. [CSS3BG]
cursor’
content’
content’ property are anonymous replaced
elements, and are sized the same way. [CSS21] Note that such anonymous
elements have all their non-inherited properties (including ‘width’, ‘height’, etc.) set to their initial values.
content’) in
sections 10.3.2,
10.4,
10.6.2,
and 10.7.
[CSS21] The
‘object-fit’ property defined below
defines how the concrete object
size corresponds to the element's used width and height; by
default they coincide.
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 fitted to the box established by
its used height and width.
fill’
contain’
cover’
none’
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 (shown with a green background), using the initial value
for ‘object-position’. The fifth value,
‘scale-down’, in this case looks
identical to ‘contain’.
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 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.
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.
image-resolution’ propertyThe 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. 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>’
from-image’
1ddpx’.
snap’
<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. 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).
image-orientation’ propertyIf a picture is taken with a camera turned on its side, or a document
isn't positioned correctly within a scanner, the resultant image may be
"sideways" or even upside-down. The ‘image-orientation’ property provides a way
to apply an "out-of-band" rotation to image source data to correctly
orient an image.
Note that some devices will "tag" an image with some metadata indicating its correct orientation, so image viewing software can do the necessary transformation themselves. Due to legacy compatibility restraints, Web browsers are required to ignore this data by default. A future level of this specification is expected to have a value that applies the metadata-specified transformation automatically.
Note that this property 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: | all elements |
| Inherited: | yes |
| 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. It applies only to content images (e.g. replaced
elements and generated content), not decorative images (such as
‘background-image’). 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.).
The ‘image-orientation’ property must be
applied before any other transformations, such as being specified in the
‘image()’ function with an opposite
directionality to its context, or using CSS Transforms.
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.
image-rendering’ property| Name: | image-rendering |
|---|---|
| Value: | auto | crisp-edges | pixelated |
| Initial: | auto |
| Applies to: | all elements |
| Inherited: | yes |
| Media: | visual |
| Computed Value: | specified value |
The ‘image-rendering’ property provides a hint
to the user-agent about what aspects of an image are most important to
preserve when the image is scaled, to aid the user-agent in the choice of
an appropriate scaling algorithm. When specified on an element, it applies
to all images given in properties for the element, such as background
images, list-style images, or the content of replaced elements when they
represent an image that must be scaled. The values of the ‘image-rendering’ property are interpreted
as follows:
The image should be scaled with an algorithm that maximizes the appearance of the image, possibly smoothing colors or introducing minor blur. This value is intended for use with photos and similar "real-life" images.
For example, algorithms such as bilinear interpolation or lancosz interpolation are acceptable. Lesser or greater algorithms may be used as well; in high-load situations, user agents may choose to use a very cheap algorithm such as nearest-neighbor, while in low-load situations they may choose to use a very expensive and high-quality scaling algorithm.
The image should be scaled with an algorithm that preserves contrast and edges in the image, and which does not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art, or diagrams with sharp, straight lines. When downscaling an image, some color-smoothing is acceptable, but should not introduce blurriness.
For example, when upscaling an image, algorithms such as nearest-neighbor are acceptable, as are specialized pixel-art scaling algorithms like EPX or the algorithm described in this SIGGRAPH paper. When downscaling an image, algorithms such as nearest-neighbor or bilinear interpolation are acceptable.
The image should be scaled with an algorithm that preserves a "pixelated" look. This is intended for images such as pixel art.
If the image is upscaled an integer multiple of its original size, it must be scaled with the nearest-neighbor algorithm. When upscaled by any other factor, nearest-neighbor is acceptable, as are other algorithms that preserve a pixelated look. When downscaling an image, any algorithm that preserves a pixelated look are acceptable, such as nearest-neighbor or bilinear interpolation.
This property does not dictate any particular scaling algorithm
to be used. For example, with ‘image-rendering:auto’, a user agent might scale
images with bilinear interpolation by default, switch to nearest-neighbor
interpolation in high-load situations, and switch to a high-quality
scaling algorithm like Lanczos interpolation for static images that aren't
moving or changing. Similarly, with ‘image-rendering:crisp-edges’, a user agent might
scale images with nearest-neighbor interpolation by default, and switch to
EPX interpolation in low-load situations.
This property must only have an effect on raster images. Vector images can be upscaled or downscaled infinitely without losing detail, and thus do not require any hints as to what details are important to preserve.
This property previously accepted the values ‘optimizeSpeed’ and ‘optimizeQuality’. These are now deprecated; a user
agent may accept them as valid values, but must treat them as aliases for
the ‘auto’ value.
dbaron suggests that optimizeSpeed should instead alias to crisp-edges.
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%.
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(<start image>, <end image>, t).
Combinations of the same images at different progress points can be smoothly animated by simply animating the progress. Theoretically, this produces the same visual effect as the generic <image> interpolation would; in practice, implementations may have slight differences due to how they scale or rasterize images. Additionally, the generic <image> interpolation produces nested cross-fade() functions, which is undesirable if it can be avoided.
If both the starting and ending images are <image-combination>s with the same image arguments, they must be interpolated by interpolating their third argument, the percentage. Otherwise, they must be interpolated as generic <image>s.
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:
If the two gradients satisfy both of those constraints, they must be interpolated as described below. If not, they must be interpolated as a generic image.
bottom’ to
‘0deg’, ‘left’ to ‘90deg’, ‘top’ to ‘180deg’, or ‘right’ to ‘270deg’.
bottom
left’ or ‘left
bottom’, the angle must be between 0deg and 90deg; for
‘top left’ or ‘left top’, the angle must be between 90deg and
180deg; for ‘top right’ or
‘right top’, the angle must be
between 180deg and 270deg; for ‘bottom
right’ or ‘right
bottom’, the angle must be between 270deg and 360deg.
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.
Conformance to CSS Image Values and Replaced Content Module Level 3 is defined for three conformance classes:
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.
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.
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.
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.
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:
The specification will remain Candidate Recommendation for at least six months.
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
Michael Day, Håkon Lie, and Shinyu Murakami for ‘image-resolution’; and to L. David Baron,
Kang-Hao Lu, Leif Arne Storset, Erik Dahlstrom, and Øyvind Stenhaug for
their careful review, comments, and corrections.
Major changes include:
element()’ feature has been
deferred to Level 4.
ltr’/‘rtl’
annotations in ‘image()’) has been
deferred to Level 4 to address some design-level feedback.
image()’.
object-fit’ property no longer resizes
the element's content box in any cases.
image-orientation’ property is now
inherited.
Significant details updated:
image()’ notation.
image()’ in order to satisfy
the prerequisite for supporting ‘image()’.
image-orientation’ was applied after CSS
transforms.
object-fit’ and ‘object-position’ properties may no longer
be aliased to ‘image-fit’ and
‘image-position’. A future
edition of the CSS Print
Profile may allow this for printer implementations, however.
There were also many clarifications and several sections were rearranged to make them easier to read.
The Disposition of Last Call Comments is available.
closest-corner’, 5.2.1.
closest-side’, 5.2.1.
dpcm’, 3.
dpi’, 3.
dppx’, 3.
farthest-corner’, 5.2.1.
farthest-side’, 5.2.1.
| Property | Values | Initial | Applies to | Inh. | Percentages | Media |
|---|---|---|---|---|---|---|
| image-orientation | <angle> | 0deg | all elements | yes | visual | specified value, rounded and normalized (see text) |
| image-rendering | auto | crisp-edges | pixelated | auto | all elements | yes | visual | specified value |
| image-resolution | [from-image || <resolution>] && snap? | 1dppx | all elements | yes | visual | as specified, except with ‘<resolution>’ possibly altered by computing for ‘snap’ (see below) |
| object-fit | fill | contain | cover | none | scale-down | fill | replaced elements | no | N/A | visual |
| object-position | <position> | 50% 50% | replaced elements | no | refer to width and height of box itself | visual |