Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
One of the primary uses for SVG is precise layout for advanced design. However, some designs, and many Web applications, need dynamic layout capabilities, and relative positioning based on the viewport or other elements. This specification provides specific and general mechanisms for pragmatic layout of SVG elements.
Although originally designed for use in SVG, some aspects of layout in this specification are defined in XML and are accessed via a presentation property, and therefore could be used in other environments, such as HTML styled with CSS and XSL:FO.
This document defines the markup used by SVG layout.
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 Layout 1.0, Part 1: Primer that lists the ways SVG Layout 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 Layout introduces new Layout 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 Layout 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 "Layout Functionality"). 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:
This chapter describes a declarative syntax for an advanced layout feature set, which when combined with the other web technologies, like SVG or CSS, can describe much of the common layout needs on the Web in such a way that client-side generation and alteration can be performed easily.
Note that even though this specification references parts of SVG 1.1 it does not require a complete SVG 1.1 implementation.
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.
This section is normative.
An <absotive> is a value that is a combination of two basic types of value, an absolute value and a relative value, within the user coordinate system. An absotive value consists of a length (that is, a number followed by an optional unit) followed by an arithmetic function, followed by another length. This may be a percentage to which an absolute pixel value is added or subtracted, or it may be a pixel value to which a percentage is added or subtracted.
It's not yet clear whether the syntax should use an addition or subtraction sign (e.g. "50% - 10px", "20px + 10%"), or if it should be function calls (e.g. "50% subtract(10px)", "20px add(10%)"). It's also not yet clear what arithmetic functions should be allowed, such as subtraction, addition, multiplication, or division.
This section is non-normative.
These are definitions from SVG 1.1 and 1.2, and are included here temporarily for reference. They will be removed before this specification is published as a Last Call document.
<length>: A length is a distance measurement. The format of a <length> is a <number> optionally followed immediately by a unit identifier. (Note that the specification of a <number> is different for property values than for XML attribute values.)
If the <length> is expressed as a value without a unit identifier (e.g., 48), then the <length> represents a distance in the current user coordinate system.
If one of the unit identifiers is provided (e.g., 12mm), then the <length> is processed according to the description in Units.
Percentage values (e.g., 10%) depend on the particular property or attribute to which the percentage value has been assigned. Two common cases are: (a) when a percentage value represents a percent of the viewport (refer to the section that discusses Units in general), and (b) when a percentage value represents a percent of the bounding box on a given object (refer to the section that describes Object bounding box units).
Within the SVG DOM, a <length> is represented as an SVGLength or an SVGAnimatedLength.
<coordinate>: A <coordinate> represents a <length> in the user coordinate system that is the given distance from the origin of the user coordinate system along the relevant axis (the x-axis for X coordinates, the y-axis for Y coordinates).
Within the SVG DOM, a <coordinate> is represented as an SVGLength or an SVGAnimatedLength since both values have the same syntax.
A <coordinate> represents a <length> in the user coordinate system that is the given distance from the origin of the user coordinate system along the relevant axis (the x-axis for X coordinates, the y-axis for Y coordinates).
A length is a distance measurement. The format of a <length> is a <number> optionally followed by a unit identifier. If the <length> is expressed as a value without a unit identifier (e.g., 48), then the <length> represents a distance in the current user coordinate system.
SVG Tiny 1.2 only supports optional units on the 'width' and 'height' attributes on the 'svg' element. These can specify values in any of the following units: in, cm, mm, pt, pc, px and %. If one of the unit identifiers is provided (e.g., 12mm), then the <length> is processed according to the description in Units.
Percentage values (e.g., 10%) on the width and height attributes of the svg element represent a percent of the viewport (refer to the section that discusses Units in general).
SVG 1.1 specifies a <coordinate> or a <length> value for the x, y, width, and height attributes. This specification extends the allowed attribute values to include <absotive> values.
How does this work with SMIL animation?
How does this normalize?
A User Agent which supports this feature must evaluate to "true" for a requiredFeatures attribute whose value is http://www.w3.org/Graphics/SVG/feature/1.2/#ArithmeticValues.
http://www.w3.org/Graphics/SVG/feature/1.2/#ArithmeticValues
Currently, SVG units can express a coordinate N pixels from the top or left edge of the viewport,
but not from the right or bottom edge (unless N is 0, in which case I can use %). So it's easy to
draw a 10px-wide rectangle along the left edge of the viewport, but not the right edge.
I can work around this limitation in some cases by introducing an <svg> container. For example,
I can actually draw a 10px wide rectangle along the right edge using
<svg ...>
<svg x="100%" style="overflow:visible">
<rect x="-10" width="10" y="0" height="100%"/>
</svg>
</svg>
However, as far as I can tell there is no way to use this to draw, say, a rectangle inset from the
viewport by 10px on each side. (And of course it's very ugly.)
A very simple extension would be to allow length values like "50%-10". This is necessarily trivial
to implement since length interpretation already requires support for viewport percentages and
user-space units; this just combines them into a single value.
An important use-case for this is "nine-grid" image stretching
(see e.g. http://msdn.microsoft.com/en-us/library/bb189722.aspx). It would be very useful if SVG
images supported this, for example for use as background images for flexible HTML content.
Of course, SVG direly needs a real layout mechanism. But this is a very small tweak that would provide
a great deal of value.
The schema for SVG Layout 1.0 is written in RelaxNG [RelaxNG], a namespace-aware schema language that uses the datatypes from XML Schema Part 2 [Schema2]. This allows namespaces and modularity to be much more naturally expressed than using DTD syntax. The RelaxNG schema for SVG Filter 1.2 may be imported by other RelaxNG schemas, or combined with other schemas in other languages into a multi-namespace, multi-grammar schema using Namespace-based Validation Dispatching Language [NVDL].
Unlike a DTD, the schema used for validation is not hardcoded into the document instance. There is no equivalent to the DOCTYPE declaration. Simply point your editor or other validation tool to the IRI of the schema (or your local cached copy, as you prefer).
The RNG is under construction, and only the individual RNG snippets are available at this time. They have not yet been integrated into a functional schema. The individual RNG files are available here.
The following interfaces are defined below: RandomInterface.
The RandomInterface interface corresponds to the 'RandomInterface' element.
interface RandomInterface : SVGElement {
readonly attribute InterfaceString foo;
};