Implementations of SVG must implement the rendering model as described in this
chapter, as modified in the appendix on conformance
requirementswhich describes
situations where an implementation may deviate.
In practice variability is allowed based on 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).
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).
3.2. The rendering tree
The components of the final rendered representation of an SVG document
do not have a one-to-one relationship with the underlying
elements in the document model.
The appearance of the graphic instead reflects a parallel structure,
the rendering tree,
in which some elements are excluded and others are repeated.
Many elements in the SVG namespace do not directly represent
a component of the graphical document.
Instead, they define graphical effects, metadata,
content to be used to represent other elements,
or alternatives to be displayed under certain conditions.
In dynamic documents, certain components of the graphic
may be rendered or not, depending on interaction or animation.
These non-rendered elements are not directly included
in the rendering tree.
Because SVG supports the reuse of graphical sub-components,
some elements are rendered multiple times.
The individual renderings may have context-dependent styling
and may be rasterized at different scales or transformations.
3.2.1. Definitions
rendering tree
The rendering tree is the set of elements being rendered
in an SVG document fragment.
It is generated from the document tree
by excluding non-rendered elements
and inserting additional fragments for re-used graphics.
Graphics are painted and composited in rendering-tree order,
subject to stacking and re-ordering based on the
z-index and paint-order properties.
Note that elements that have no visual paint may still be in the rendering tree.
rendered element
An element that has a direct representation in the
rendering tree for the current document.
Includes a rendered instance of an element in a use-element shadow tree.
Does not include elements that affect rendering
as the source definition of re-used graphics
but are not directly rendered themselves.
See Rendered versus non-rendered elements
non-rendered element
An element that does not have a direct representation in the
rendering tree for the current document.
It may nonetheless affect the rendering tree as re-used graphics
or graphical effects.
See Rendered versus non-rendered elements.
re-used graphics
Graphical components that are included in the rendering tree
but do not have a single direct equivalent element
in the document model.
They may be represented through shadow DOM elements
(as in graphics re-used with a ‘use’ element),
or as image fragments generated as part of a graphical effect
(as in patterns or masks).
A renderable element may or may not be rendered
in a given document or point in time.
3.2.2. Rendered versus non-rendered elements
At any given time, every SVG element
(or element instance in a use-element shadow tree)
is either rendered or non-rendered.
Whether an element is currently rendered or not affects
not only its visual display but also interactivity
and geometric calculations.
An element is not rendered in any of these four situations:
Non-rendered elements are not represented in the document accessibility tree.
Nonetheless, they remain part of the document model, and
participate in style inheritance and cascade.
3.2.3. Controlling visibility: the effect of the ‘display’ and ‘visibility’
properties
SVG uses two properties to toggle the visible display of
elements that are normally rendered:
display and visibility.
Although they have a similar visible effect in static documents,
they are conceptually distinct.
The display property affects the direct processing
of a given element, but it does not prevent it from
being referenced by other elements.
For example, setting
display: none on a ‘path’ element
will prevent that element from getting rendered directly onto the
canvas, but the ‘path’ element can still be referenced by a
‘textPath’ element and its geometry will be used
in text-on-a-path processing.
When applied to a graphics element or ‘use’ element,
setting visibility to hidden
or collapse
results in the element not being painted.
It is, however, still part of the rendering tree.
It may be sensitive to pointer events
(depending on the value of pointer-events),
may receive focus (depending on the value of ‘tabindex’),
contributes to bounding box calculations and clipping paths,
and does affect text layout.
Graphical content defined in one part of the document
(or in another document)
may be used to render other elements.
There are two types of re-used graphics from a rendering perspective:
shadow DOM elements,
such as those generated by ‘use’ elements
or by cross-references between paint servers;
Shadow DOM elements are rendered in the same way as normal elements,
as if the host element (e.g., the ‘use’ element)
was a container and the shadow content was its descendents.
Style and geometry properties on the shadow DOM elements
are resolved independently from those on their corresponding element
in the source document.
The display property has its normal effect on shadow elements,
except for special rules that apply to the ‘symbol’ element.
Unless properties on the host element create a stacking context,
z-index values on shadow DOM elements
can change their rendering order relative to elements in the main DOM.
For blending purposes, the ‘use’ element forms a non-isolated group.
In contrast,
graphical effects elements generate a self-contained SVG fragment
which is rendered independently as a stacking context
and an isolated group.
The canvas for this fragment is scaled
The graphical effect element's child content
is rendered and composited into this canvas.
The flattened canvas as a whole is treated as a vector image
when compositing and blending with other paint layers
The display property on any child content of a graphical effects element
has its normal effect when set to none,
excluding that subtree from being used in rendering.
However, the graphical effect is not altered
by a value of display: none
on the graphical effect element or an ancestor.
3.3. 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.
3.4. Rendering order
Elements in SVG are positioned in three dimensions. In addition to their
position on the x and y axis of the SVG 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.
3.4.1. Controlling element rendering order: the ‘z-index’ property
This feature is at risk.
See the CSS 2.1 specification for the definition
of z-index. [CSS2]
The z-index property allows an element to be assigned to a
stack level.
The rules governing behavior 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 stack level of the element in the current stacking context.
Whether the element establishes a new local stacking context.
Values have the following meanings:
<integer>
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.
auto
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.
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.
3.4.2. Establishing a stacking context in SVG
A new stacking context must be established at an SVG element for its descendants if:
it is the root element
the z-index property applies to the element and its computed
value is an integer
the element is an inner ‘svg’ element and the computed value of its
overflow property is a value other than visible
the element is subject to explicit clipping:
the clip property applies to the element and it has a
computed value other than auto
the clip-path property applies to the element and it has a
computed value other than none
the opacity property applies to the element and it has a
computed value other than 1
the mask property applies to the element and it has a computed
value other than none
the filter property applies to the element and it has a
computed value other than none
a property defined in another specification is
applied and that property is defined to establish a stacking context in SVG
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:
the background and borders of the element forming the stacking
context, if any
child stacking contexts created by descendants with negative stack
levels, primarily ordered by most negative first, then by tree order
descendants with 'z-index: auto' or
'z-index: 0', in tree order
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:
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.
Grouping elements, such as the ‘g’ element (see container elements
) create a compositing group.
Similarly, a ‘use’ element creates a compositing group for its shadow content.
The Compositing and Blending
specification normatively describes how to render compositing groups.
In SVG, effects may be applied to a group. For example, opacity, filters
or masking. These effects are applied to the rendered result of the group
immediately before any transforms on the group are applied, which are applied
immediately before the group is blended and composited with the
group backdrop. Applying any such effects to a group makes that
group isolated.
Thus, rendering a compositing group follows the following steps:
If the group is isolated:
The initial backdrop is set to a new buffer initialised with
rgba(0,0,0,0)
The contents of the group that are graphics elements or
‘g’ elements are rendered
in order, onto the
initial backdrop. The group transforms are applied to each element
as they are rendered.
3.6.1. Object and group opacity: the
effect of the ‘opacity’ property
See the CSS Color Module Level 3 for the definition
of opacity. [css3-color]
The opacity property specifies how opaque a given
graphical element or container element will be when it is
painted to the canvas. When applied to a container element,
this is known as group opacity, and when applied to
an individual rendering element, it is known as object
opacity. The principle for these two operations however
is the same.
There are several other opacity-related properties in SVG:
fill-opacity, which specifies the opacity of a fill
operation;
stroke-opacity, which specifies the opacity of a stroking
operation;
solid-opacity, which specifies the opacity of a solid color
paint server; and
stop-opacity, which specifies the opacity of a gradient stop.
These four opacity properties are involved in intermediate rendering operations.
Object and group opacity however can be thought of as a post-processing operation.
Conceptually, the object or group to which opacity applies
is rendered into an RGBA offscreen image. The offscreen image as whole is then blended
into the canvas with the specified opacity value used uniformly
across the offscreen image.
Thus, the presence of opacity causes the group to be
isolated.
Each group of red and green circles is first rendered
to an offscreen image before being blended with the background
blue rectangle as a whole, with the given opacity values.
In the example, the top row of circles have differing opacities,
ranging from 1.0 to 0.2. The bottom row illustrates five ‘g’ elements,
each of which contains overlapping red and green circles, as follows:
The first group shows the opaque case for reference. The group has
opacity of 1, as do the circles.
The second group shows group opacity when the elements in the group are
opaque.
The third and fourth group show that opacity is not commutative. In the
third group (which has opacity of 1), a semi-transparent green circle is
drawn on top of a semi-transparent red circle, whereas in the fourth group a
semi-transparent red circle is drawn on top of a semi-transparent green
circle. Note that area where the two circles intersect display different
colors. The third group shows more green color in the intersection area,
whereas the fourth group shows more red color.
The fifth group shows the multiplicative effect of opacity settings.
Both the circles and the group itself have opacity settings of .5. The
result is that the portion of the red circle which does not overlap with the
green circle (i.e., the top/right of the red circle) will blend into the
blue rectangle with accumulative opacity of .25 (i.e., .5*.5), which, after
blending into the blue rectangle, results in a blended color which is 25%
red and 75% blue.
3.7. Types of graphics elements
SVG supports three fundamental types of graphics elements
that can be rendered onto the canvas:
Shapes, which represent some combination of straight line
and curves
Text, which represents some combination of character glyphs
Raster images, which represent an array of values that
specify the paint color and opacity (often termed alpha) at a
series of points on a rectangular grid. (SVG requires support
for specified raster image formats under
conformance requirements.)
3.7.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).
For certain types of shapes, marker
symbols (which themselves can consist of any combination of shapes,
text and images) can be drawn at positions along the
shape boundary. 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.
The fill and stroke operations are entirely independent
painting operations. 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.
SVG supports numerous built-in types of paint which can
be used in fill and stroke operations. These are described in
Paint Servers.
3.7.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.
As in HTML [HTML, 10.4.2],
all animated images with the same absolute URL and the same image
data are expected to be rendered synchronised to the same timeline as a group,
with the timeline starting at the time of the least recent addition to the
group.
When a user agent is to restart the animation for an img element showing an
animated image, all animated images with the same absolute URL and the same
image data in that img element's node document are expected to restart their
animation from the beginning.
3.8. Filtering painted regions
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.
3.9. Clipping and masking
SVG supports the following clipping/masking features:
clipping paths, which either uses
any combination of ‘path’, ‘text’ and
basic shapes or basic shapes to serve as
the outline of a (in the absence of anti-aliasing) 1-bit
mask, where everything on the "inside" of the outline is
allowed to show through but everything on the outside is
masked out
masks, which are
container elements
which can contain graphics elements
or other container elements which define a set of graphics
that is to be used as a semi-transparent mask for compositing
foreground objects into the current background.
Both, clipping and masking, are specified in the module CSS Masking
[css-masking-1].
3.10. Parent compositing
SVG document fragments can be semi-opaque.
In accordance with the Compositing and Blending specification,
the ‘svg’ element always creates an isolated group.
When an SVG document is a top-level document,
meaning it is not embedded in another document,
the root ‘svg’ element
is considered to be the page group and is composited with
a backdrop of white with 100% opacity.
In all other cases, the SVG document or document fragment is composited into the parent
document with opacity preserved.
3.11. The effect of the ‘overflow’
property
See the Cascading Style Sheets Level 2 Revision 1 (CSS 2.1)
Specification [CSS2] for the definition of
overflow.
A summary of the behavior of the overflow property in SVG.
element
initial
ua stylesheet
auto
visible
hidden
scroll
document root svg
visible
n/a
visible | scroll
visible
hidden
scroll
other svg
visible
hidden
visible | scroll
visible
hidden
scroll
mesh
visible
n/a
visible
visible
hidden
hidden
text
visible
hidden
visible
visible
hidden
hidden
pattern
visible
hidden
visible
visible
hidden
hidden
hatches
visible
hidden
visible
visible
hidden
hidden
marker
visible
hidden
visible
visible
hidden
hidden
symbol
visible
hidden
visible
visible
hidden
hidden
image
visible
hidden
visible
visible
hidden
hidden
iframe
visible
hidden
visible | scroll
visible
hidden
scroll
foreignObject
visible
hidden
visible | scroll
visible
hidden
scroll
The overflow property has the same parameter values and has the
same meaning as defined in CSS 2.1
([CSS2], section 11.1.1);
however, the following additional points apply:
If the overflow property has a value of 'visible',
the property has no effect (i.e., a clipping rectangle is not created).
For those elements to which the overflow property can apply.
If the overflow property has the value
hidden or scroll, a clip,
the exact size of the SVG viewport is applied.
When scroll is specified on an
‘svg’ element and if the user agent uses a scrolling mechanism that
is visible on the screen (such as a scroll bar or a panner), that mechanism
should be displayed for the SVG viewport whether or not any of its content is clipped.
Within SVG content, the value auto implies
that all rendered content for child elements must be
visible, either through a scrolling
mechanism, or by rendering with no clip.
For elements where the value of scroll results
in a scrolling mechanism being used by the user agent, then a value of
auto may be treated as
scroll. If the user agent has no scrolling
mechanism, the content would not be clipped, or the value 'scroll' is treated
as hidden, then the value
auto must be treated as
visible
Although the initial value for overflow is auto. In the User Agent style sheet,
overflow is overriden for the ‘svg’ element when it is not the root
element of a stand-alone document, the ‘pattern’ element, ‘hatch’
element, and the ‘marker’ element to be hidden by default.
