Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
This is revision $Id: SVGLayoutReqs.html,v 1.12 2009-02-13 01:20:22 cmccorma Exp $.
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.
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].
This section lists requirements that have been identified for the “SVG Layout” specification.
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]
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.
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]
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]
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, ...]
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]
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]
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]
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]
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]
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]
...
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]
It should be possible to to position objects relative to the bounding box of some arbitrary content.
[use case: aligning unknown compound graphical content]
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]
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]
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.
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.]
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]
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]
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]
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.
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.