About CSVG
The recent SVG 1.2 Working Draft has suggested that SVG is extended in some way to allow expressions as attribute values and for these expressions to be evaluated at display-time to determine the attribute value (3.2.7 Expression-based attribute values). Potentially this extension is very useful for supporting widget layout and dynamic layout, two of the aims of SVG 1.2.
In order to better explore the capabilities that expression-based attributes allows we have extended Batik to provide this ability and have built several representative examples illustrating the extra power. The examples demonstrate that adding dynamic evaluation of expression-based attribute values to SVG allows the SVG author to:
Specify how to adjust the SVG layout in response to viewer requirements and the viewing environment such as a small browser window on a PDA. Expression-based attributes allow differential scaling of SVG document elements, and alternate layouts depending on the viewing context, thus increasing the accessibility of SVG documents. In particular the layout can adjust when text changes size because for instance the user requests a larger font or a different language. Example 1.
-
Specify widget layout which adjusts to the viewing context. In particular it is relatively easy to specify grid-based widget layout and widget placement and size which is fixed regardless of zooming on other parts of the SVG document. Example 2, example 3.
-
And expression-based attribute values provide support for user interaction and animation since the expressions can be in terms of variable values set by the user during interaction or in terms of the time since the animation started. In particular, this supports hierarchical diagrams in which the viewer can collapse and expand parts of the diagram. Example 4.
This is achieved without a need for RCC or complex scripting. Indeed our feeling is that providing dynamic evaluation of expression-based attributes and allowing parameters in use or def directly in SVG would remove most of the need for complex RCC scripts.
Our implementation utilises one-way constraint solving algorithms developed for a variety of applications including GUIs, spreadsheets, customisable graphic editors such as Visio. The one-way constraint solver is responsible for determining dependencies between the attributes and appropriately ordering expression evaluation. Thus order of expression evaluation is independent of the order of SVG elements in the document. This means the document author is free to specify what they want without worrying about how it should be computed. The solver is also responsible for updating the value of expressions when one of the attributes changes value, such as for example if the user resizes the browser window. Because it knows the dependencies between attributes it can do this very efficiently. This means that user interaction and animation can be efficiently supported.
The current SVG 1.2 proposal proposes to provide the power of dynamic evaluation of expression-based attributes by using the RCC-SVG translator to compute the values when generating the shadow tree. The examples utilise scripting to do this. This works but has two problems:
-
It does not easily support animation and user interaction with the shadow tree. One would like the re-layout required in animation or at least some user interaction to not require generation of the shadow tree from scratch (and even this is a bit tricky since it requires the animation and user interaction to be couched in terms of elements in the RCC.)
-
It may require several passes through the DOM to compute the attributes so as to ensure that they are computed in the right order and quite complex, lengthy code to do so.
These problems would be overcome if dynamic evaluation of expression-based attributes was either (a) added to SVG so RCC could just generate SVG with the appropriate expressions, or (b) if the RCC-SVG translator itself generated one-way constraints that appropriately update the attributes of the SVG (and possibly attributes of the RCC) during animation and interaction. The reason for doing one of these is so that it becomes the responsibility of the one-way constraint solver rather than RCC-SVG translator to ensure that the attributes are computed in the right order and also to maintain the specified relationships between the attributes when other attributes are modified through user interaction or animation.
An advantage of adding dynamic evaluation of expression-based attributes to SVG itself is that one-way constraint solving is considerably less expensive to support than scripting and probably RCC. This means that less powerful mobile computing devices could support dynamic evaluation of expression-based attributes and get many of the benefits of RCC (widget layout, dynamic layout) without needing to support full RCC and scripting.