Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This specification defines a way to override the default document-order rendering model of SVG, in a manner similar to the CSS 'z-index' property.
This document defines the markup used by SVG Rendering Order.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document is the first public working draft of this specification. There is an accompanying SVG Rendering Order 1.0, Part 1: Primer that lists the ways SVG Rendering Order may be used.
This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.
We explicitly invite comments on this specification. Please send them to www-svg@w3.org (archives), the public email list for issues related to vector graphics on the Web. Acceptance of the archiving policy is requested automatically upon first post to either list. To subscribe to this list, please send an email to www-svg-request@w3.org with the word subscribe in the subject line.
The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.
Publication of this document does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a work in progress.
This draft of SVG Rendering Order introduces new Rendering Order syntax and markup for the SVG language. One of the goals is that this specification can be re-used more easily by other specifications that want to have advanced Rendering Order features. This specification introduces syntax that may not be backwards compatible with older SVG User Agents, and the use of this syntax should be accompanied by a fallback using the 'switch' element.
The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to www-svg@w3.org. Please include some kind of keyword that identifies the area of the specification the comment is referring to in the subject line of your message (e.g "Section X.Y - Foo attribute values" or "[RO]"). If you have comments on multiple areas of this document, then it is probably best to split those comments into multiple messages.
The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document. There is also a specific area related to the specification that is listed here:
There are use cases when it is desirable to change the the rendering order of an SVG document. Typically the method used is to remove the elements from the document tree and then re-insert them at the desired new location, using script. This has performance implications and adds complexity to content creation. It is also unsuitable for many effects, such as animation.
This proposed specification enhances the rendering order of SVG documents such that order may be specified through content, in a manner that is consistent with the SVG rendering model, and with considerations for performance and ease of implementation.
ISSUE: explain how this is different than the CSS 'z-index' property, and why.
Note that even though this specification references parts of SVG 1.1 and SVG Tiny 1.2 it does not require a complete implementation of those specifications.
This document is normative.
This document contains explicit conformance criteria that overlap with some RNG definitions in requirements. If there is any conflict between the two, the explicit conformance criteria are the definitive reference.
The rendering tree is the set of elements being rendered, aurally or visually using the painters model, in an SVG document fragment. The following elements in the fragment and their children are part of the SVG document fragment, but not part of the rendering tree (and thus are not rendered):
The copies of elements referenced by a 'use' element, on the other hand, are not in the SVG document fragment but are in the rendering tree. Note that elements with zero opacity, or no 'fill' and no 'stroke', or with an 'audio-level' of zero, or with the 'visibility' property set to hidden, are still in the rendering tree.
The rootmost 'svg' element is the furthest 'svg' ancestor element that does not exit an SVG context.
Note that this definition has been carefully chosen to be applicable not only to SVG Tiny 1.2 (where the rootmost 'svg' element is the only 'svg' element, except when there is an 'svg' element inside a 'foreignObject') but also for SVG Full 1.2 and SVG that uses XBL [XBL2]. See also SVG document fragment.
An SVG document fragment is the XML document sub-tree whose rootmost element is an 'svg' element (that is, the rootmost 'svg' element.)
An SVG document fragment consists of either a stand-alone SVG document, or a fragment of a parent XML document where the fragment is enclosed by the rootmost 'svg' element.
In SVG Tiny 1.2, the SVG document fragment must not contain nested 'svg' elements. Nested 'svg' elements are unsupported elements and must not be rendered. Note that document conformance is orthogonal to SVG document fragment conformance.
For further details, see the section on Conforming SVG Document Fragments.
SVG defines a rendering tree. Elements in the rendering tree have an implicit drawing order. Elements are rendered using a pre-order, depth-first walk of the SVG document fragment. Subsequent elements are painted on top of previously painted elements.
The rendering order of 'g' elements can be adjusted using the ‘render-order' attribute. When a 'g' element is encountered during the depth-first walk, a secondary walk is performed. Conceptually, as direct children are encountered, they are added to a rendering order list - this list contains a reference to the element as well as a rendering order number. For 'g' elements, this is the value of the render-order attribute, and is ‘0' for all other elements. It is important to note that nested containers are not traversed during this walk - only direct descendants of the 'g' element are added to the rendering order list. Once the walk is complete, the list is sorted by the render order value. Any render order values which are equal are sorted by the order in which they appeared in the document fragment.
The implications are as follows:
The render-order property applies to the 'g' element.
Property definitions:
The ‘render-order’ property must be a integer that represents the relative rendering order of this element's children. The lacuna value is '0'.
Animatable: yes.
In this example, the default rendering order is modified due to the render-order properties on the 'g' elements. The first 'g' element now becomes the last to render, due to the value of '1'. The last 'g' element becomes the first to render due to the value of '1'.
<svg xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 160 120">
<g>
<g render-order="1">
<circle fill="red" cx="100" cy="100" r="20"/>
<circle fill="green" cx="100" cy="105" r="20"/>
</g>
<circle fill="blue" cx="100" cy="110" r="20"/>
<g render-order="-1">
<circle fill="yellow" cx="100" cy="90" r="20"/>
<circle fill="orange" cx="100" cy="95" r="20"/>
</g>
</g>
</svg>
The editors would like to acknowledge and thank the following people for substantive aid with this specification: .