dSVG stands for Dynamic Scalable Vector Graphics, an XML grammar for UI controls and behaviors that extends SVG, providing enhanced dynamic and interactive capabilities that were previously only available via scripting. The word 'dynamic' encompasses the concepts of "interactive", "data-driven" and "visual changes".
Every dSVG UI control is composed of a persistent object in memory, which gets instantiated when the dSVG UI control element is processed, as well as the visible SVG elements defined via a skin/template, which can exist within a 'def' block in the SVG file or in a separate file. The skins must follow specific formats. The appearance for every state must be described in SVG markup within a group 'g' container with an 'id' attribute equal to 'up', 'down', 'hover', 'focus' or 'disabled'. Within each of these containers, the individual components of that control must be defined via predefined ID's. For instance, a slider control requires components specified with the ID's "label", "body", "skinSliderBar", "skinSliderThumb", "tickMajor", "tickMinor", "tickLabelMajor", "tickLabelMinor" and "mask". The markup within these containers, however, is completely customizable. The intrinsic behaviors of dSVG's UI controls make no a priori assumptions regarding the nature of the appearance, except insofar as the obvious, such the element with id="label" must be either a 'text' or 'tspan' element. When the UI control is instantiated, the skin is retrieved and used, along with the attributes of the UI control element, to create the visible SVG objects in the DOM that make up the appearance. For instance, the slider skin's "tickMajor" markup will be cloned as many times as required, based on the 'slider' element's 'tickMajor' attribute, and positioned appropriately.
Because there are no assumptions made regarding the SVG markup comprising a UI control's skin, the skins must contain dSVG 'constraint' elements, if they are to be resized "intelligently". When a UI control element's 'width' and/or 'height' attribute is set, the desired dimensions of the UI control are compared to the existing dimensions of its bounding box and, if different, a transform is applied to the visible markup. With no constraints defined in the skin, this could cause unwanted side effects, such as the label also being stretched, or the stroke-widths appearing to be thicker or thinner. Contraints can be defined in the skin to counteract these effects due to scaling.
Behavior elements represent actions that can be executed in response to an event triggered by an SVG element or a dSVG UI control. They fall into the following categories: DOM manipulation, viewer manipulation, coordinate conversion, constraints, flow control, selection ability and containers. Behaviors can be associated to an element in two different ways.
The first way is to directly associate the behaviors to the element by inserting them as a children of that element. Whenever the element triggers an event, the behaviors whose 'event' attribute matches the event type are run in the order in which they are listed. To avoid specifying the same 'event' attribute for multiple associated behaviors, you can group all those behaviors with common 'event' attributes as children of a dSVG 'action' element, which specifies the 'event' attribute just once. For example, if a 'zoom' element with an 'event' attribute equal to 'onclick' is added as a child of a 'circle' element, then clicking on the circle will execute the zoom behavior, while hovering over it with the mouse will not.
The second way is to indirectly associate the behavior to the element by creating a dSVG 'listener' element, which specifies the 'event' attribute, whose 'observer' attribute is the ID of the element that will trigger the event and whose 'handler' attribute is the ID of the behavior element. It is best practice to create just one 'listener' element per event for a given observer element by pointing it to a handler element that is an 'action' element containing all the behaviors that should be run in response for that particular event. In such a case, the 'action' element should not specify the 'event' attribute, as it has already been specified by the 'listener' element. The advantage of indirectly associating behaviors to elements is that the same behaviors can be re-used by multiple elements. Note that to achieve the quickest load times, the 'action' elements should appear at the beginning of the document (beneath the root <svg> element), followed by the 'listener' elements, followed by the rest of the content.
dSVG behaviors that are to be executed at load time should be inserted as children of the root <svg> element, in the order they are to be executed, with their 'event' attributes equal to 'onload' (the default).
Objects are passive behaviors or containers, which usually get instantiated and then exist as persistent objects in memory. They usually exist as direct children of the 'svg' root element and are associated to target elements indirectly.
The dSVG expression syntax allows you to refer to real-time values of any attribute of any element in any accessible document or documentFragment easily without a complex syntax like XPath and without script. It also allows you 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%"/>.