CSS Image Values and Replaced Content Module Level 4

Editor’s Draft, 3 October 2014

This version:
http://dev.w3.org/csswg/css-images-4/
Latest version:
http://www.w3.org/TR/css4-images/
Previous Versions:
http://www.w3.org/TR/2012/WD-css4-images-20120911/
Feedback:
www-style@w3.org with subject line “[css-images] … message topic …” (archives)
Editors:
fantasai (Mozilla)
Issue Tracking:
http://www.w3.org/Style/CSS/Tracker/products/27

Abstract

This is a delta spec over Images 3; when next published, it will be a real spec with everything filled in, but for now removing duplication is more important than having a complete spec.

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

Status of this document

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

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 “css-images” in the subject, preferably like this: “[css-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.

Table of Contents

1. Images Values: the <image> type

1.1. Image Fallbacks and Annotations: the image() notation

The image() notation is defined as:

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

1.1.1. Bidi-sensitive Images

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

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

A list may use an arrow for a bullet that points into the content. If the list can contain both LTR and RTL text, though, the bullet may be on the left or the right, and an image designed to point into the text on one side will point out of the text on the other side. This can be fixed with code like:
<ul style="list-style-image: image(ltr 'arrow.png');">
  <li dir='ltr'>My bullet is on the left!</li>
  <li dir='rtl'>MY BULLET IS ON THE RIGHT!</li>
</ul>

This should render something like:

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

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

1.2. Using Elements as Images: the element() notation

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

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

The syntax for element() is:

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

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

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

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

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

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

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

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

an element that is rendered, is not a descendant of a replaced element, and generates a stacking context
The function represents an image with its intrinsic size equal to the decorated bounding box of the referenced element:

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

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

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

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

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

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

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

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

an element that is not rendered, but which provides a paint source
The function represents an image with the intrinsic size and appearance of the paint source. The host language defines the size and appearance of paint sources.
For example, the element() function can reference an SVG <pattern> element in an HTML document:
<!DOCTYPE html>
<svg>
  <defs>
    <pattern id='pattern1'>
      <path d='...'>
    </pattern>
  </defs>
</svg>
<p style="background: element(#pattern1)">
  I’m using the pattern as a background!
  If the pattern is changed or animated,
  my background will be updated too!
</p>

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

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

The function represents an invalid image.

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

<!DOCTYPE html>
<p id='one' style="display:none;">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.

1.2.1. Paint Sources

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

In HTML, the <img>, <video>, and <canvas> elements provide paint sources (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:

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

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

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

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

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

partial interface CSS {
  [SameObject] readonly attribute Map elementSources;
};

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

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

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

For example, fancy animating backgrounds can be done with an external canvas:
<script>
var bg = document.createElement('canvas');
bg.height = 200;
bg.width = 1000;
drawFancyBackground(bg);
CSS.elementSources.set('fancy', bg);
</script>
<style>
h1 {
  background-image: element(#fancy);
}
</style>

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

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

1.2.3. Cycle Detection

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

The dependency graph consists of edges such that:

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

2. Gradients

A gradient is an image that smoothly fades from one color to another. These are commonly used for subtle shading in background images, buttons, and many other things. The gradient 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()> | <repeating-linear-gradient()> |
  <radial-gradient()> | <repeating-radial-gradient()> |
  <conic-gradient()>  | <repeating-conic-gradient()> ]

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

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

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

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

2.1. Conic Gradients: the conic-gradient() notation

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

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

Note: These gradients are called "conic" or "conical" because, if the color stops are chosen to be significantly lighter on one side than the other, it produces a pattern that looks like a cone observed from above.

2.1.1. conic-gradient() Syntax

The syntax for a conic gradient is:

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

The <position> argument 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 'at center'.

Anything else that might be useful? Defining the shape of the gradient as elliptical, perhaps?

2.1.2. Placing Color Stops

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

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

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

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

2.1.3. Conic Gradient Examples

Produce examples. Better yet, strike this section, and intermix some examples into the sections above. Do this for the other two types of gradients as well.

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

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

repeating-conic-gradient(at 20%, white 0deg, white 20deg, red 20deg, red 40deg)

Insert rendering here.

2.3. Gradient Color-Stops

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

This is past the complexity point where it can be easily understood with just prose. Add a diagram illustrating the possibilities, preferably for all three kinds of gradients (to show off the three shapes of gradient lines).

The colors in gradients are specified using color stops. A color stop is a combination of a color and one or two positions. (Depending on the type of gradient, that position can be a length, angle, or percentage.) While every color stop conceptually has at least one position, the position can be omitted in the syntax. (It gets automatically filled in by the user agent; see below for details.)

Between two color stops there can be a color interpolation hint, which specifies how the colors of the two color stops on either side should be interpolated in the space between them (by default, they interpolate linearly). There can only be at most one color interpolation hint between any two given color stops; using more than that makes the function invalid.

Color stops are organized into a color stop list, which is a list of one or more color stops. The first and last color stops in the list must have a color (though their position can be omitted).

Color stops and color hints are placed on a gradient line, which defines the colors at every point of a gradient. The gradient function defines the shape and length of the gradient line, along with its starting point and ending point.

Color stops and color hints must be specified in order. Percentages refer to the length of the gradient line between the starting point and ending point, with 0% being at the starting point and 100% being at the ending point. Lengths are measured from the starting point in the direction of the ending point along the gradient line. Angles are measured with 0deg pointing up, and positive angles corresponding to clockwise rotations from there.

Color stops and color hints 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 or color hint can be placed at any position on the gradient line.

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

The position of a color stop can be omitted. This causes the color stop to position itself automatically between the two surrounding stops. If multiple stops in a row lack a position, they space themselves out equally.

The following steps must be applied in order to process the <color-stop-list>. After applying these rules, all color stops and color hints will have a definite position and color (if appropriate) 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 or color hint has a position that is less than the specified position of any color stop or color hint before it in the list, set its position to be equal to the largest specified position of any color stop or color hint before it.
  3. If any color stop still does not have a position, then, for each run of adjacent color stops without positions, set their positions so that they are evenly spaced between the preceding and following color stops with positions.

This requires us to wait until after layout to do fix-up, because implied-position stops (set by step 3) may depend on stops that need layout information to place, and which may be corrected by step 2. Swapping steps 2 and 3 would let us interpolate color stops purely at computed-value time, which is a nice plus, at the cost of changing behavior from level 3 for some edge cases that triggered fixup. Make sure this is handled well in the serialization rules.

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

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

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

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

Note: If the hint is placed halfway between the two stops, this is thus the ordinary linear interpolation. If the hint is placed anywhere else, it dictates the position of the "halfway point", where the color is an equal blend between the two color stops, and produces smooth, even blends between the color stops and the "halfway point".

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.

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)
8. linear-gradient(red, 25%, white)
   =14=>
   linear-gradient(red 0%, rgb(100%,50%,50%) 25%, white 100%)
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)

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.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet
A CSS style sheet.
renderer
A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool
A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Partial implementations

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

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.

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.

References

Normative References

[CSS3-TRANSFORMS]
Simon Fraser; et al. CSS Transforms. 11 September 2012. W3C Working Draft. (Work in progress.) URL: http://www.w3.org/TR/2012/WD-css3-transforms-20120911/
[SELECT]
Tantek Çelik; et al. Selectors Level 3. 29 September 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-css3-selectors-20110929/
[rfc2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Best Current Practice. URL: http://www.ietf.org/rfc/rfc2119.txt

Index

Issues Index

Do we need to be able to refer to elements in external documents (such as SVG paint servers)? Or is it enough to just use url() for this?
This name conflicts with a somewhat similar function in GCPM. This needs to be resolved somehow.
Want the ability to do "reflections" of an element, either as a background-image on the element or in a pseudo-element. This needs to be specially-handled to avoid triggering the cycle-detection.
When we have overflow:paged, how can we address a single page in the view?
Requiring some degree of stacking context on the element appears to be required for an efficient implementation. Do we need a full stacking context, or just a pseudo-stacking context? Should it need to be a stacking context normally, or can we just render it as a stacking context when rendering it to element()?
This reuse of the ID selector matches Moz behavior. I’m trying to avoid slapping a <custom-ident> right in the beginning of the grammar, as that eats too much syntax-space. Another possibility, though, is to start the value with a language-defined keyword followed by a <custom-ident>, like element(external fancy) or something. Naming suggestions welcome.
Anything else that might be useful? Defining the shape of the gradient as elliptical, perhaps?
Produce examples. Better yet, strike this section, and intermix some examples into the sections above. Do this for the other two types of gradients as well.
Insert rendering here.
This is past the complexity point where it can be easily understood with just prose. Add a diagram illustrating the possibilities, preferably for all three kinds of gradients (to show off the three shapes of gradient lines).
This requires us to wait until after layout to do fix-up, because implied-position stops (set by step 3) may depend on stops that need layout information to place, and which may be corrected by step 2. Swapping steps 2 and 3 would let us interpolate color stops purely at computed-value time, which is a nice plus, at the cost of changing behavior from level 3 for some edge cases that triggered fixup. Make sure this is handled well in the serialization rules.