SVG 2 – 09 April 2015 TopContentsPreviousNextElementsAttributesProperties

Chapter 2: Rendering Model


SVG 2 Requirement: Support the z-index.

Resolution: We will add Jonathan Watt's z-index proposal to SVG 2.

Auckland 2011 F2F day 5.

Purpose: Allow reordering (such as when a planet orbits the sun). Reordering without script support (e.g. CSS :hover).

Owner: Jonathan (Action 3002).

The SVG 2 rendering model will follow the rules defined by the Compositing and Blending specification.

Resolution: Seattle/Paris 2012 F2F day 3.

Owner: Nikos (Action 3332).

2.1. Introduction

Implementations of SVG are expected to behave as though they implement a rendering (or imaging) model corresponding to the one described in this chapter. Real implementations may choose to implement the model in the way that they see fit, but the result on any device supported by the implementation must, in most cases, match this model.

The appendix on conformance requirements describes the extent to which an actual implementation may deviate from this description. In practice an actual implementation may deviate slightly because of limitations of the output device (e.g. only a limited range of colors might be supported) and because of practical limitations in implementing a precise mathematical model (e.g. for realistic performance curves are approximated by straight lines, the approximation need only be sufficiently precise to match the conformance requirements).

2.2. The painters model

SVG uses a "painters model" of rendering. Paint is applied in successive operations to the output device such that each operation paints onto some area of the output device, possibly obscuring paint that has previously been layed down. After each object or group is painted, it becomes part of the background for the next painting operation. SVG 2 supports advanced blending modes and compositing operations that control how each painting operation interacts with the background. The rules governing these painting operations are outlined in the Compositing and Blending Specification.

2.3. Rendering order

Elements in SVG are positioned in three dimensions. In addition to their position on the x and y axis of the viewport, SVG elements are also positioned on the z-axis. The position on the z-axis defines the order that they are painted.

Along the z-axis, elements are grouped into 'stacking contexts', each stacking context has an associated stack level. A stack level may contain one or more child nodes - either child stack levels, graphics elements, or g elements. graphics elements and g elements within single stack level are painted in document order - that is, they are painted in the order that they are defined in the document.

Each stack level is assigned an integer value that defines it's position on the z-axis relative to other stack levels within the same stacking context. Lower values are painted first, and so elements in a stack level with a higher value will paint over one with a lower value.

By default, everything is placed in stack level zero.

2.3.1. Controlling element rendering order: the ‘z-index’ property

See the CSS 2.1 specification for the definition of ‘z-index’. [CSS21]

The ‘z-index’ property allows an element to be assigned to a stack level.

The rules governing behaviour for SVG elements with the ‘z-index’ property specified are outlined below:

CSS specifies a property named ‘z-index’. The CSS rules that define the effect of the ‘z-index’ property were written specifically for the CSS box model, and those rules do not make sense as they stand for most SVG elements (most SVG elements do not participate in or establish a CSS box model layout). This section specifies how implementations must handle the ‘z-index’ property on elements in the SVG namespace.

Contrary to the rules in CSS 2.1, the ‘z-index’ property applies to all SVG elements regardless of the value of the ‘position’ property, with one exception: as for boxes in CSS 2.1, outer svg elements must be positioned for ‘z-index’ to apply to them.

The ‘z-index’ property specifies:

  1. The stack level of the element in the current stacking context.
  2. Whether the element establishes a new local stacking context.

Values have the following meanings:

This integer is the stack level of the element in the current stacking context. The element also establishes a new local stacking context for its descendants.
The stack level of the element in the current stacking context is the same as its parent element, unless its parent established a new stacking context, in which case its stack level is 0. The element does not establish a new local stacking context.

Here is a simple example:

<svg xmlns="">
  <rect x="0"  width="100" height="100" fill="red"    z-index="-1"/>
  <rect x="40" width="100" height="100" fill="lime"/>
  <rect x="80" width="100" height="100" fill="blue"   z-index="1"/>
  <rect x="60" width="100" height="100" fill="aqua"/>
  <rect x="20" width="100" height="100" fill="yellow" z-index="-1"/>

In this example there are three stack levels: -1, 0 (the default) and 1. The red and yellow rects are in stack level -1, the lime and aqua rects are in stack level 0 (the default), and the blue rect is in stack level 1. Going from lowest stack level to highest, and painting the elements in each stack level in document order, the painting order is: red, yellow, lime, aqua, blue.

A new stacking context must be established at an SVG element for its descendants if:

Stacking contexts and stack levels are conceptual tools used to describe the order in which elements must be painted one on top of the other when the document is rendered, and for determining which element is highest when determining the target of a pointer event. Stacking contexts and stack levels do not affect the position of elements in the DOM tree, and their presence or absence does not affect an element's position, size or orientation in the canvas' X-Y plane - only the order in which it is painted.

Stacking contexts can contain further stacking contexts. A stacking context is atomic from the point of view of its parent stacking context; elements in ancestor stacking contexts may not come between any of its elements.

Each element belongs to one stacking context. Each element in a given stacking context has an integer stack level. Elements with a higher stack level must be placed in front of elements with lower stack levels in the same stacking context. Elements may have negative stack levels. Elements with the same stack level in a stacking context must be stacked according to document order.

With the exception of the foreignObject element, the back to front stacking order for a stacking context created by an SVG element is:

  1. the background and borders of the element forming the stacking context, if any
  2. child stacking contexts created by descendants with negative stack levels, primarily ordered by most negative first, then by tree order
  3. descendants with 'z-index: auto' or 'z-index: 0', in tree order
  4. child stacking contexts created by descendants with positive stack levels, primarily ordered by lowest index first, then by tree order

Since the foreignObject element creates a "fixed position containing block" in CSS terms, the normative rules for the stacking order of the stacking context created by foreignObject elements are the rules in Appendix E of CSS 2.1.

In the following example, the ‘z-index’ property on the g element is set to zero. This creates a new stacking context to contain the g element's children without moving the g to a different level in the document's root stacking context:

<svg xmlns="">
  <g z-index="0">
    <!-- this is a self contained graphic -->
    <rect x="40" width="100" height="100" fill="lime" z-index="1"/>
    <rect x="20" width="100" height="100" fill="yellow"/>
  <rect x="60" width="100" height="100" fill="aqua"/>
  <rect x="0" width="100" height="100" fill="red" z-index="-1"/>

The example's root stacking context contains two stack levels: -1 and 0. The red rect is in level -1, and the g element and aqua rect are in level 0. Inside stack level 0, the g element's ‘z-index’ property creates a new nested stacking context at the g for the g element's children. In this child stacking context there are two stack levels: 0 and 1. The yellow rect is in level 0 (the default), and the lime rect is in level 1.

Painting of this example starts with the stack levels of the root stacking context. First the red rect is painted in level -1, then in level 0 the g element is painted followed by the aqua rect. When the g element is painted, the child stacking context that its z-index created and all of that context's stack levels are also painted. In this child stacking context, first the yellow rect in level 0 is painted, followed by the lime rect in level 1. It's only after the g and the stacking context that it creates has been painted that the aqua rect is painted. Note that this means that although the z-index of 1 for the lime rect is a higher value than the (implicit) z-index of 0 for the aqua rect, the containment provided by the g's child stacking context results in the aqua rect painting over the lime rect. The painting order is therefore: red, yellow, lime, aqua.

2.4. How groups are rendered

Grouping elements, such as the g element (see container elements ) create a compositing group. The compositing group will composite and blend with the group backdrop with behaviour depending on the values of the compositing and blending properties, such as isolation. See Compositing and Blending Specification.

What is the status of the knock-out property?

2.5. How elements are rendered

Individual graphics elements are rendered as if each graphics element represented its own compositing group; thus, the effect is as if a temporary separate canvas is created for each graphics element. The element is first painted onto the temporary canvas (see Painting shapes and text and Painting raster images below). Then any filter effects specified for the graphics element are applied to create a modified temporary canvas. The modified temporary canvas is then composited into the background, taking into account any clipping, masking and object opacity settings on the graphics element.

Should this mention blending as well?

2.6. Types of graphics elements

SVG supports three fundamental types of graphics elements that can be rendered onto the canvas:

2.6.1. Painting shapes and text

Shapes and text can be filled (i.e., apply paint to the interior of the shape) and stroked (i.e., apply paint along the outline of the shape). A stroke operation is centered on the outline of the object; thus, in effect, half of the paint falls on the interior of the shape and half of the paint falls outside of the shape.

For certain types of shapes, marker symbols (which themselves can consist of any combination of shapes, text and images) can be drawn at selected vertices. Each marker symbol is painted as if its graphical content were expanded into the SVG document tree just after the shape object which is using the given marker symbol. The graphical contents of a marker symbol are rendered using the same methods as graphics elements. Marker symbols are not applicable to text.

The order in which fill, stroke and markers are painted is determined by the ‘paint-order’ property. The default is that fill is painted first, then the stroke, and then the marker symbols. The marker symbols are rendered in order along the outline of the shape, from the start of the shape to the end of the shape.

Each fill and stroke operation has its own opacity settings; thus, you can fill and/or stroke a shape with a semi-transparently drawn solid color, with different opacity values for the fill and stroke operations.

The fill and stroke operations are entirely independent painting operations; thus, if you both fill and stroke a shape, half of the stroke will be painted on top of part of the fill.

SVG supports the following built-in types of paint which can be used in fill and stroke operations:

Mention hatches, mesh gradients?

2.6.2. Painting raster images

When a raster image is rendered, the original samples are "resampled" using standard algorithms to produce samples at the positions required on the output device. Resampling requirements are discussed under conformance requirements.

Should we mention anything regarding animated images?

2.7. Filtering painted regions

This section needs more detail on the interaction between compositing and blending and filter effects. Waiting on the Compositing and Blending spec to define the accumulated background removal process. Filtering will need to fit into that process as the final step before the group buffer is composited with the page.

SVG allows any painting operation to be filtered. (See Filter Effects.)

In this case the result must be as though the paint operations had been applied to an intermediate canvas initialized to transparent black, of a size determined by the rules given in Filter Effects then filtered by the processes defined in Filter Effects.

2.8. Clipping, masking and object opacity

SVG allows any painting operation to be limited to a subregion of the output device by clipping and masking. This is described in Clipping, Masking and Compositing.

Need to remove reference to compositing in the Clipping, Masking and Compositing chapter.

Clipping uses a path to define a region of the output device to which paint can be applied. Any painting operation executed within the scope of the clipping must be rendered such that only those parts of the device that fall within the clipping region are affected by the painting operation. A clipping path can be thought of as a mask wherein those pixels outside the clipping path are black with an alpha value of zero and those pixels inside the clipping path are white with an alpha value of one. "Within" is defined by the same rules used to determine the interior of a path for painting. The clipping path is typically anti-aliased on low-resolution devices (see ‘shape-rendering’. Clipping is described in Clipping paths from CSS Masking ([CSS-MASKING], section 8).

Masking uses the luminance of the color channels and alpha channel in a referenced SVG element to define a supplemental set of alpha values which are multiplied to the alpha values already present in the graphics to which the mask is applied. The resulting alpha value is used as input to the Compositing and Blending operations described in the Compositing and Blending Specification [COMPOSITING-BLENDING]. Masking is described in detail in CSS Masking [CSS-MASKING].

A supplemental masking operation may also be specified by applying a "global" opacity to a set of rendering operations. In this case the mask is infinite, with a color of white and an alpha channel of the given opacity value. (See the ‘opacity’ property.)

2.9. Parent Compositing

SVG document fragments can be semi-opaque. In many environments (e.g., Web browsers), the SVG document fragment has a final compositing step where the document as a whole is blended translucently into the background canvas.

SVG 2 – 09 April 2015 TopContentsPreviousNextElementsAttributesProperties