SVG Layout: Use Cases and Requirements

W3C Editor’s Draft 13 February 2009

Latest Editor’s Draft:
Latest Published Version:
Cameron McCormack, Invited Expert <cam@mcc.id.au>


This document presents requirements and use cases for layout functionality in SVG. These requirements will be used as the basis for a layout module that builds on SVG Tiny 1.2.

Editorial note

This is revision $Id: SVGLayoutReqs.html,v 1.12 2009-02-13 01:20:22 cmccorma Exp $.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the 13 February 2009 Editor’s Draft of the SVG Layout: Use Cases and Requirements specification. Please send comments about this document to www-svg@w3.org (archived) with “[Layout]” at the start of the subject line.

It is intended that this document be eventually published as a W3C Note, but not before work on the “SVG Layout” module for which it documents the requirements has been published as a Candidate Recommendation. As work on the layout module progresses, new use cases and requirements that would be appropriate for inclusion may be discovered. As such, the requirements document will be somewhat of a work in progress, and intended to be more of an outlet for the reasons why certain functionality has been included in the module, rather than being a prescriptive document that prevents any deviation from the Working Group’s initial decisions. This document does not make any normative requirements of the “SVG Layout” module that is to be written.

This document is produced by the SVG Working Group, part of the Graphics Activity in the W3C Interaction Domain. Changes made to this document can be found in the W3C public CVS server.

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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. Introduction

SVG currently has little support for automatic layout and positioning of graphical content. There is support for uniform scaling of content to fit in a given rectangle (possibly subject to aspect ratio fitting), and positioning and sizing objects relative to canvas and font size. In general, uses of SVG tend to fall into three broad categories: static artwork, static diagrammatic or illustrative content, and interactive web applications. For static artwork, this lack of support for layout is mostly not a problem, since the content is usually intended to be presented exactly as the artist intended. For diagrammatic and illustrative content, as well as web applications, the need for layout of content whose size is not known until display time is much more common, and the minimal support for layout that SVG does have currently is most often insufficient.

This document presents requirements for layout functionality in SVG. A use case to support each of these requirements is also given. These requirements will be used to inform the development of an “SVG Layout” specification, which will be formulated as a module to be used in conjunction with SVG Tiny 1.2 [SVGT12].

2. Requirements

This section lists requirements that have been identified for the “SVG Layout” specification.

R1. Use a declarative mechanism for specifying layout

The mechanism used to specify layout should not need to be invoked explicitly by script to be applied (although interfaces for script to interact with the layout mechanisms should be provided, as described in R17, below). Thus, a declarative mechanism (using element or attribute markup, or CSS properties) should be specified.

The use case for requiring a declarative mechanism for layout is where an author wants to specify a layout where the position or size of one object depends on the size or position of one or many others. By specifying layout declaratively, the dependent object positions and sizes can be updated automatically, without needing the author to to explicitly register event handlers and invoke the layout mechanism manually.

[figure showing a layout where changing one of multiple elements would result in a change in layout]

R2. Reuse existing specifications where appropriate

There exist other W3C specifications that deal with layout in some way. Some of these may be appropriate for direct use, or adaptation for use, with SVG. A non-exhaustive list of specifications to be looked at for reuse includes:

Other, non-W3C specifications, markup langauges or documents may also be suitable for reuse or consideration:

The obvious reasoning behind this requirement is that it is desirable to avoid duplicating functionality that already exists and can be referenced, especially if the reinvented work is needlessly incompatible with the existing specification, as this would complicate implementations that support both.

R3. Support fallback to non-layout capable user agents

Where possible, newly introduced layout functionality should not cause content to break in user agents that do not support the functionality.

[use case: publish layout capable content now that displays reasonably in older UAs]

R4. Allow layout to adapt to variation in font and choice of text content

The layout module should allow positions and sizes of objects to be specified relative to text so that it can adapt to changes in the font used or the actual text content.

[use case: fonts may differ due to different UA or user stylesheets or available fonts, and text content may differ due to internationlization]

R5. Allow layout to adapt to arbitrary child content

The layout mechanism should be able to position and size arbitrary graphical content that may not be known before display time.

[use case: XSLT generation of SVG documents, insertion of content from database queries, ...]

R6. Allow layout to adapt to medium capabilities

The layout of content should be able to respond to different capabilities and properties of the presentation context. This might include, for example, the size of the canvas in which the SVG content is rendered, the color depth of the target device, whether the target medium supports interaction or animation, etc.

[use case: create a single document that can adapt its layout to various viewing conditions]

R7. Support hierarchical container based layout

One of the layout mechanisms supported should allow the specification of container based layout, as commonly found in widget toolkits, and should also support layout containers being placed within other layout containers. Common container based layout schemes, like the AWT’s BorderLayout and FlowLayout layout managers [AWT], should be supported.

[use case: creating UIs for web applications, where rich, graphical components can be composed]

R8. Ensure common diagrammatic layouts can be specified easily

It should be possible to create common types of diagrams and charts easily with the specified layout mechanisms.

[use case: using XSLT to generate charts from numerical data]

R9. Support choice between multiple layouts

The “SVG Layout” module should allow multiple layouts to be specified for content, where the layout chosen to be applied is determined at display time based on some criteria. The criteria may be related to the characteristics of the presentation context or the content that is to be laid out.

[use case: layout that is inappropriate at small screen sizes, switch to a different, more compact form]

R10. Support deriving document size and view box from layout

It should be possible to have the document size (that is, the 'width' and 'height' attributes on the root 'svg' element) and the area of interest (the 'viewBox' attribute) determined at display time based on the content of the document.

[use case: layout can be used to compute the document size needed to display content that is not known at design time]

R11. Support positioning of objects relative to key points on a shape

The layout mechanism should allow positioning objects relative to particular points on a shape, such as its mid-point, one of its corners, etc.

[use case: aligning graphical content]

R12. Support positioning of objects relative to text baselines


R13. Support positioning of objects relative to a point on the edge of a shape

The layout mechanism should allow positioning of objects relative to the closest point on the shape relative to a given other point.

[use case: simple connectors]

R14. Support positioning of objects relative to the bounding box of some content

It should be possible to to position objects relative to the bounding box of some arbitrary content.

[use case: aligning unknown compound graphical content]

R15. Support reuse of relative layout positions

It should be possible to elegantly reuse already-computed layout positions for positioning and sizing other elements.

[use case: defining positioning once and not repeating it on many elements, allowing such reference points to be animated or controlled by script]

R17. Support dynamic control of layout from script and SMIL animation

The layout mechanism should be designed such that script and SMIL animation can be used to control it. As much as possible, attributes and properties that control layout should be animatable and exposed to script in the SVG DOM.

[use case: inspecting layout decisions or computations without having to reverse engineer them from the positions or sizes of the elements being laid out; allowing user interaction to control layout]

R18. Consider the use of layout functionality in combination with XBL 2.0

The design of the layout mechanism should take into account how it might be used in conjunction with XBL 2.0 [XBL2]. Depending on the final design, it may be necessary to document how layout works with bound elements, or how custom elements can be created that participate in layout.

The need for this consideration is simply because XBL will at some point be implemented across browsers and is intended to be the standard method for creating custom components and widgets on the web platform. It is likely that the default handling of SVG content with XBL will not be sufficient to handle also the new layout functionality. Rather than leave that to be defined later, it should be considered as part of the design process.

R19. Consider functionality to specify custom layouts using script

The “SVG Layout” module might include support for integrating author-written layout script with the built-in layout functionality. This could be, for example, a way for script to implement a new type of container layout.

[use case: not all layout use cases are going to be covered by the module, so it would be advantageous to allow authors to integrate their own layout code so that it works in conjunction with the built-in layout functionality.]

R20. Allow specification of layout parameters from style sheets

As much as possible, parameters to control layout should be specified as CSS properties. This will allow certain kinds of layout to be applied to elements with particular classes, and for techniques such as Media Queries to be used to control layout based on properties of the target medium [MQ].

[use case: using CSS to set a common amount of padding to multiple layout containers; using Media Queries to select the kind of layout to be used based on the target screen size]

R21. Support grid layout

One of the kinds of hierarchical layout containers supported should be a grid [GRID]. Graphical content should be able to be placed such that its extents are aligned with the lines of the grid. Aligning content on grid lines should be able to be performed absolutely (that is, addressing particular grid lines) or relatively (selecting the next major grid line that follows some other graphical content, depending on that other content’s size).

[use case: grids are a very common design utility; magazine/book/newspaper type layout for an SVG document]

R22. Support templated designs

The “SVG Layout” module should support the creation of templated graphical designs, where authors can create a design to be used as an application “skin” that will be filled in with text and other content by the application.

[use case: mobile phone or window manager themes]

3. Non-goals

This section lists some explicit non-goals of the forthcoming “SVG Layout” module:

The above features might be supported by being implemented in script through the use of an interface designed for R19, however.

A. References

java.awt (Java Platform SE 6) package summary. Sun Microsystems, 2008.
Available at http://java.sun.com/javase/6/docs/api/java/awt/package-summary.html.
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification (work in progress), B. Bos, et al., eds. World Wide Web Consortium, 19 July 2007.
This edition of CSS 2.1 is http://www.w3.org/TR/2007/CR-CSS21-20070719/.
The latest edition of CSS 2.1 is available at http://www.w3.org/TR/CSS21/.
CSS Grid Positioning Module Level 3 (work in progress), A. Mogilevsky and M. Mielke, eds. World Wide Web Consortium, 5 September 2007.
This edition of CSS3 Grid is http://www.w3.org/TR/2007/WD-css3-grid-20070905/.
The latest edition of CSS3 Grid is available at http://www.w3.org/TR/css3-grid/.
CSS3 Values and Units (work in progress), H. Lie and C. Lilley, eds. World Wide Web Consortium, 19 September 2006.
This edition of CSS3 Values and Units is http://www.w3.org/TR/2006/WD-css3-values-20060919/.
The latest edition of CSS3 Values and Units is available at http://www.w3.org/TR/css3-values/.
CSS Advanced Layout Module (work in progress), B. Bos, ed. World Wide Web Consortium, 9 August 2007.
This edition of CSS3 Layout is http://www.w3.org/TR/2007/WD-css3-layout-20070809/.
The latest edition of CSS3 Layout is available at http://www.w3.org/TR/css3-layout/.
Compiling Adaptive Diagrams into SVG, C. McCormack, K. Marriott and B. Meyer. Proceedings of the Fifth International Conference on Scalable Vector Graphics, 4 September 2007, Tokyo, Japan.
Available at http://www.svgopen.org/2007/papers/svgopen2007-paper/.
Adaptive layout using one-way constraint in SVG, C. McCormack, K. Marriott and B. Meyer. Proceedings of the Third Annual Conference on Scalable Vector Graphics, 7 September 2004, Tokyo, Japan.
Available at http://www.svgopen.org/2004/papers/ConstraintSVG/.
Device Independent Authoring Language (DIAL) (work in progress), K. Smith, ed. World Wide Web Consortium, 27 July 2007.
This edition of DIAL is http://www.w3.org/TR/2007/WD-dial-20070727/.
The latest edition of DIAL is available at http://www.w3.org/TR/dial/.
Content Selection for Device Independence (DISelect) 1.0 (work in progress), R. Lewis, R. Merrick and M. Froumentin, eds. World Wide Web Consortium, 25 July 2007.
This edition of DISelect is http://www.w3.org/TR/2007/CR-cselection-20070725/.
The latest edition of DISelect is available at http://www.w3.org/TR/cselection/.
Grid systems in graphic design, J. Müller-Brockmann. Niggli, 1996, Sulgen, Switzerland. ISBN 3721201450.
Layout Managers for SVG, M. Rotard and T. Ertl. Proceedings of the Fourth Annual Conference on Scalable Vector Graphics, 15 August 2005, Enschede, The Netherlands.
Available at http://www.svgopen.org/2005/papers/LayoutManagersForSVG/.
Media Queries (work in progress), H. Lie, et al., eds. World Wide Web Consortium, 15 October 2008.
This edition of Media Queries is
The latest edition of Media Queries is available at http://www.w3.org/TR/css3-mediaqueries/.
Scalable Vector Graphics (SVG) Tiny 1.2 Specification, O. Andersson, et al., eds. World Wide Web Consortium, 22 December 2008.
This edition of SVG Tiny 1.2 is http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/.
The latest edition of SVG Tiny 1.2 is available at http://www.w3.org/TR/SVGTiny12/.
Extensible Stylesheet Language (XSL) Version 1.1, A. Berglund, ed. World Wide Web Consortium, 5 December 2006.
This edition of XSL 1.1 is http://www.w3.org/TR/2006/REC-xsl11-20061205/.
The latest edition of XSL 1.1 is available at http://www.w3.org/TR/xsl11/.
XML Binding Language (XBL) 2.0 (work in progress), I. Hickson, ed. World Wide Web Consortium, 16 March 2007.
This edition of XBL 2 is http://www.w3.org/TR/2007/CR-xbl-20070316/.
The latest edition of XBL 2 is available at http://www.w3.org/TR/xbl/.
XUL — Mozilla Developer Center. Mozilla Foundation. Retrieved on 12 February 2009.
Available at https://developer.mozilla.org/en/XUL.

B. Acknowledgements

The members of the SVG Working Group who contributed to this document include:

The editor would also like to thank the following people for contributing to this document: Kim Marriott.