1 Introduction
Contents
1.1 About dSVG
This specification defines the features and syntax for Dynamic Scalable Vector
Graphics (dSVG).
dSVG is a language for describing UI controls and behaviors in XML [XML10].
It contains eleven types of UI controls ('button', 'checkBox', 'radioButton',
'contextMenu', 'comboBox', 'listBox', 'listView', 'slider', 'spinBox',
'textBox' and 'window'), six categories of behaviors (DOM
manipulation, viewer manipulation, coordinate conversion, constraints, flow
control and selection ability), and two container elements ('action' and
'share').
dSVG UI controls have instrinsic states (up, down, hover, focus and disabled),
which change according to mouse and keyboard events. Their appearances are
defined in skins that are completely customizable. These skins can also contain
dSVG constraints, which allow the UI controls to be "intelligently" resized.
SVG files with dSVG elements are interactive and dynamic. Behaviors
can be directly or indirectly associated to SVG elements or to dSVG
UI controls and triggered by specified events.
Sophisticated applications of SVG are possible by use of a supplemental
scripting language which accesses the SVG Document Object Model (DOM), which
provides complete access to all elements, attributes and properties. A rich set
of event handlers such as onmouseover and onclick can be assigned to any SVG
graphical object. However, scripting has many downsides, as described in the
next section.
1.2 The Limitations of Script
-
Requires programming ability.
Most Web designers do not have the programming skills required for DOM
manipulation via scripting.
-
Requires time to develop.
Even for developers, creating a suite of robust, responsive UI controls
requires a significant amount of script, which takes a significant
amount of time to implement.
-
Difficult to auto-generate.
One could attempt to assist Web designers by creating pre-canned scripts for
the most commonly required functionality. However, supporting the insertion of
pre-canned scripts via an IDE is both very complicated and very limiting.
Auto-generated script cannot easily be customized afterwards, unless the IDE
absolves itself of all responsibility should the designer make modifications.
-
Difficult to data-map.
Software exists that allows one to map input XML markup to output markup,
automatically generating XSLT (the most commonly used XML markup language for
transforming XML markup to a different form of markup). But there is no
software that allows the user to map input XML data to variables in pre-canned
script functions.
-
Relies on full DOM support.
Scripts are only as powerful as the DOM methods that the viewer supports.
Although all viewers should support the entire spectrum of DOM methods, the
fact is that they currently do not. Thus one must write script that only uses
the API's supported by all viewers, in order to ensure that the script works on
all viewers (i.e. one must program towards the lowest common denominator).
-
Complex.
Abstracting the DOM methods using dSVG markup has allowed for the creation
of a more direct linkage between the syntax and the intent of the author. Take
the example of a designer creating a new element dynamically in the DOM. The
designer wishes to create a circle at a particular location in the DOM tree.
The syntax is very straightforward with dSVG's 'createElement' or 'copyElement'
markup , but to do it in script is quite complicated, requiring over a hundred
lines of code. You must first use getElementById() to find the target element,
and then either the parent or sibling element. You then use createElement() to
create the circle. If inserting beneath a parent, you use parent.appendChild().
If inserting before a sibling, you use sibling.insertBefore(). If inserting
after a sibling you use sibling.nextSibling.insertBefore(), unless there is no
nextSibling, in which case you use sibling.parentNode.appendChild(). The author
may wish to insert it as, say, the fourth sibling from the top or bottom,
requiring you to write a loop which counts the siblings and accounts for the
fact that maybe there aren't that many siblings. Or the author may wish the new
element to be the parent of existing elements, which requires removal of those
elements and appending them as the children of the new one. Then finally you
use setAttribute() to set its ID so that you can refer to it later.
-
Slower than native code.
Scripts are interpreted, and thus provide slower performance than what would be
possible with a natively-implemented markup language. Just having a script
interpreter is a lot of overhead for a small device. While dSVG 1.0 has itself
been implemented with ECMAScript, it is our hope that it will one day become
part of an existing standard and implemented natively.
-
Must use DOM interfaces.
Scripts can only manipulate the DOM via the DOM methods, which are abstractions
on top of the real object model used by the viewer. Natively-implemented markup
could access the real object model directly, which may improve performance even
more.
-
More data to transfer. Scripts greatly add to the amount of
data needed to be transferred. This is a problem especially for small devices.
A natively-implemented DOM Manipulation Markup Language would greatly reduce
the size of the file being transferred. It also allows for the possibility of
further reducing the file size by creating a binary version of the markup
language via opcodes, something that is not possible with script.
1.3 The Advantages of dSVG
-
Requires no programming ability.
Enables Web designers with no programming skills to create dynamic, interactive
Web applications.
-
Rapid Application Development.
dSVG is very intuitive, abstracting the DOM methods to create a more direct
linkage between the syntax and the intent of the author. This allows even
developers to develop Web applications much more quickly than via scripting.
-
Easily auto-generated.
Because dSVG is a markup language, it can be easily created and customized with
an IDE such as Corel Smart Graphics Studio.
-
Easily data-mapped.
The dSVG markup can be made to be data-driven using existing software that
allows one to map input XML markup to output markup via an XML transformation
language such as XSLT.
-
No script engine required.
If natively implemented, the need for a script engine on a small device would
be greatly reduced.
-
Intuitive.
The dSVG elements 'setStyle' and 'setTransform' make modifying the 'style' and
'transform' attributes much easier for the author. These attributes are very
difficult to modify with script because they do not map directly to one
value; instead they are composed of a string of separate properties or
property-value pairs themselves. For instance, if an element contains a 'style'
attribute which sets the stroke width to 1, and you want to change the
stroke-width to 2, you cannot directly set the stroke-width value–you have to
instead generate the string "stroke-width:2". But it is complicated further by
the fact that the 'style' attribute might have more style properties defined,
such as style= ”stroke-width:1;fill:red;opacity:0.5“, so simply setting the
'style' attribute to “stroke:2” would accidentally remove the other style
properties. So you must first get the value of the 'style' attribute, parse it,
determine if it already has the property you want to set, set it or replace it,
and write the new delimited string again. This is all done for you with dSVG's
'setStyle' element. Modifying a 'transform' attribute has similar problems
except it is made even more difficult by its syntax of transform=”matrix(a b c
d e f) translate(x [y]) scale(sx [sy] rotate(angle [cx cy]) skewX(angle)
skewY(angle))“. It is even more complicated by the fact that the final
transfomation depends on the order of these individual transformations. And if
you want, say, to apply a scale factor to an element, this could have the
effect of also translating the element, so you need to calculate the
transformation required to preserve the elements centre or edge coordinates.
Again, this is all handled for you with dSVG's 'setTransform' element. These
elements and others effectively abstract the author from having to understand
the details of SVG's syntax.
-
Expressions.To create dynamic,
interactive Web applications, you often need to reference the real-time values
of attributes of other elements within the document, or even within a
different documentFragments. For example, you might wish to set the 'fill'
color of a circle to be whatever color has been entered in a textBox. The dSVG
expression syntax allows you to refer to such real-time values easily without
script, and to manipulate them with mathematical operators and functions, as
well as to concatenate them with strings. For instance, if you had a circle
element with id="myCircle" and a dSVG textBox element with id="myTextBox",
you could set the circle's fill colour to be the value of the textBox like so:
<dsvg:setAttribute elementID="myCircle" attribute="fill"
value="%myTextBox@value%"/>.
-
Faster.
The dSVG markup could be natively-implemented, providing faster
performance than script.
-
Less data to transfer. If natively implemented, the amount of
data needed to be transferred would be greatly reduced, which is especially
beneficial for wireless devices with low bandwidth and small memory.
1.4 UI Controls
HTML has been, for quite some time, the platform (markup language) with which
to build Web applications. It has always been limiting, though, in its poor
graphics support (only bitmaps, no vectors), its lack of absolute positioning,
its small set of UI controls and its inability to describe the appearance of
those UI controls (it's up to the HTML browser to decide on the appearance).
SVG (Scalable Vector Graphics) is a powerful new XML markup language which
promises to soon become the platform of choice with which to build Web
applications. Although it provides the author with a rich set of vector
graphics features (as well as bitmaps) and absolute control over their
positioning, it suffers from the absolute lack of any markup for UI controls.
In lieu of UI markup, SVG-based Web applications are forced to create their
own UI controls using script. This means, however, that non-developers cannot
author the content, a fair amount of script for the UI controls must be
transferred to the client (a real problem for wireless devices) and the UI
controls are not as responsive as natively-implemented UI controls, unless
being run on very fast processors.
What is needed is an XML markup language for UI controls, which:
-
encompasses all the UI controls most commonly needed to build applications
-
allows for absolute control of the positioning of the UI controls
-
allows for absolute control of the appearance of the UI controls
-
can be easily hooked up to actions, defined via markup or script functions
-
can be easily used for forms
-
is not tied to a model specifically intended for forms (i.e. does not force the
author to jump through hoops to create an application which does not use forms)
XUL is an XML markup language for UI
controls created by The Mozilla Organization, specifically for use in their
Mozilla HTML Web browser. While it does offer an extensive list of UI controls,
offers limited skin-ability (control of the appearance) and is not tied to a
forms creation/processing/submission model, it is intended for use in HTML
browsers and thus does not allow for absolute positioning nor absolute control
of the appearance, cannot be easily hooked up to actions and cannot be easily
used for forms. XUL has not been proposed to the W3C or any other standards
body. It is not supported in the Corel or Adobe SVG Viewers.
XForms is another XML markup
language which includes UI controls. As the name implies, it was designed for
forms, plus its first intended host platform was HTML. So, of the six
requirements listed above, it only meets #5. It only supports those UI controls
needed for forms, does not allow absolute control over their positioning and
their appearance, cannot be easily hooked up to actions (except those that
affect just its own UI controls and its "instance", or forms, data) and is very
tightly tied to its forms model. XForms is an official working draft at the
W3C. It is not supported in the Corel or Adobe SVG Viewers.
The dSVG markup for UI controls meets all of the above six requirements.
1.5 Behaviors
Using SVG as the markup language for creating rich Web applications requires
scripting to provide the dynamic and interactive features. There are many
downsides to scripting, however.
-
Developers are required to author the script, which can take a fair amount of
time, especially for developers unfamiliar with scripting.
-
All the script must be transferred to the client (an issue for wireless
devices).
-
Script cannot be easily data-mapped from XML data like markup can.
-
Script cannot be transformed via XSLT.
-
Scripts are interpreted and are thus inherently slower than native code.
-
Scripts interpreters increase the footprint of the SVG Viewer, which is an
issue for small devices.
What is needed is an XML markup language for behaviors, which encompasses all
the actions most commonly needed to build applications. This includes:
-
viewer manipulation (e.g. zooming and panning)
-
DOM manipulation
-
mouse position tracking
-
coordinate conversion
-
constraints
-
flow control
-
selection ability
SMIL is an XML markup language
designed for multimedia purposes, whose animation features are partially
supported by the SVG specification. While it does offer the 'set' element,
which allows attribute values to be modified, it does not actually change the
attribute values in the core DOM, but rather in the animated DOM. Thus using
SMIL to modify attributes does not create mutation events, which might be
useful. There is also no way to access the animated DOM to determine what the
current value of an attribute is, which is essential to building applications.
Regardless, SMIL does not offer markup analogies for the rest of the DOM
methods that allow the DOM to be fully manipulated.
The dSVG markup for behaviors meets all of the above seven requirements.