Make scalable vector graphics more active with sXBL

The Scalable Vector Graphics (SVG) Working Group has released an updated Working Draft of SVG's XML Binding Language (sXBL). The sXBL language defines the presentation and interactive behavior of elements outside the SVG namespace. sXBL is intended to be used to enable XML vocabularies (tag sets) to be implemented in terms of SVG elements. For instance, a tag set describing a flowchart could be mapped to low-level SVG path and text elements, possibly including interactivity and animation. sXBL is intended to be an SVG-specific first version of a more general-purpose XBL specification (e.g., XBL 2.0, for old 2001 spec).

The intent is that, in the future, a general-purpose and modularly-defined XBL specification will be developed which will replace this specification and will define additional features that are necessary to support scenarios beyond SVG, such as integration into web browsers that support CSS. Once a general-purpose XBL is defined, sXBL would just become an SVG-specific subset (i.e., a profile) of the larger XBL specification.

XBL cannot be used to give a document new semantics (except if script invoked by XBL explicitly changes the original DOM). The meaning of a document is not changed by any bindings that are associated with it, only its presentation and interactive behavior.

The sXBL specification is the culmination of several years of work by several groups: already mentioned XBL (XML Binding Language) submitted by Mozilla.org in 2001, "Behavioral Extensions to CSS" in 1999, RCC (Rendering Custom Content) as part of some SVG 1.2 drafts etc.

Hello, world!

The following is a simple SVG example (Example1.svg) where a custom element (<myNS:HelloWorld/>) acquires the alternate presentation behavior defined by the  element at the top of the file. The <myNS:HelloWorld/> element will be rendered by using the contents of the shadow tree which is attached by the binding. The shadow tree consists of an <svg:text> element which has the string "Hello, world, using sXBL" inside:

Example1.svg

The above example results in equivalent rendering to the following SVG (Example2.svg). The highlighted sections (i.e., the <g> and <text> elements) represent the shadow tree which the binding definition (i.e., the <xbl:definition> element defined above) attaches to the custom element. The SVG user agent renders the shadow tree in place of the custom element (hello-world-sxbl.png / Figure A).

Example2.svg

Figure A

Hello World

XBL in detail

The start of any XBL subtree is an <xbl> element. This fact is not interesting and thus let's move to <xbl:definition> element.

According to XBL terminology, a binding is the definition of behavior that can be applied to an element so as to define its presentation. This means that any element of an SVG document can be bound to an sXBL code that will handle its behavior. Therefore a bound element is an element in an arbitrary XML namespace, to which a binding has been applied.

The shadow tree for a bound element is the subtree of nodes that are attached to a bound element as a result of XBL processing. The contents of the shadow tree augment the bound element's standard presentation and interactive behavior with alternate behavior. The shadow tree is hidden from normal DOM processing (hence the name "shadow"). The shadow tree is attached to the bound element. Once attached, the shadow tree can be accessed only via XBL-specific DOM extensions and therefore is not accessible via Core DOM navigation facilities. The term shadow content refers to the various nodes in the shadow tree of a bound element. Shadow content is created by cloning a shadow content template during binding attachment.

The <definition> element describes a single XBL binding that adds presentation and interactive behavior to non-SVG elements. Each binding has these optional components:

• Template
• Behavior

The optional child element <template> corresponds to Template component and defines the initial shadow content for the bound element (as said above, it's just a subtree of new nodes attached to element, hidden from normal DOM model).

As for Behavior component, a binding can define event listeners for various types of events. Some examples are: UI events (e.g., key and mouse events) on the bound element or on elements within the shadow content; mutation events on the bound element and its descendants; and events having to do with XBL's binding operations.

Alternatively, a binding may reference an existing binding, with the "ref" attribute. In this case, the "ref" attribute must reference a <definition> element which in turn supplies the binding definition. Bindings may also act as an attachment mechanism, specifying a namespace and local name of elements to associate with the given binding when the binding is imported, using the "element" attribute. In addition to the above, the <definition> element may contain any element outside the XBL namespace, for example svg:defs. These are handled as they would be in any other context, and are ignored by the XBL processing model. It's also worth mentioning that the <definition> element defines a presentation and behavior binding, and does not define an element's semantics.

The <template> element contains child nodes that can be in any namespace. The subtree specified by the <template> element is referred to as the shadow content template. When a binding is attached, the <template> element's child nodes are cloned and attached to the bound document under the bound element. Because these cloned nodes are hidden from their parent and exist outside the normal document tree, they are referred to as "shadow content". When the <template> element is cloned, it is renamed to <shadowTree>, as will be revised in details later.

Binding mechanism

Bindings shall be attached as soon as the following conditions have been met: (a) it is known that the element is bound to the given binding (b) the element has been created and (c) the binding has loaded. The binding mechanism is the <definition>element, it declares which bindings should be attached to which elements.

When a new binding is attached, the UA must perform the following steps:

• Events must start being routed through the binding's <handlerGroup> element, when there is one;
• The shadow content template is then cloned, if needed, to create the shadow tree, and the prebind event is fired before it is attached;
• Once all the bindings of any descendent elements are attached, a bound event is fired on the bound element.
• Before a binding is detached, an unbinding event is fired on the bound element. The shadow content nodes, the shadow tree, any forwarding of events to the binding, etc, are then removed from the element.

Event mechanism

As you may have already surmised, sXBL uses event-driven logic in defining an interactive behavior for SVG model. Every time an event fires on a bound element (whether during the capture, target, or bubbling phases), if any event listeners for the given event exist on the corresponding <handlerGroup> element, then those listeners must be invoked. <handlerGroup> element may content any event listening element, in particular ev:listener and svg:handler. The <handlerGroup> element's event handlers can be called for events that flow through the bound element. When a given event is received by a bound element, if a corresponding event listener has been attached to the <handlerGroup> element, then the event will be forwarded to that event listener.

Often, XBL developers will want to register the same event listener on all bound elements corresponding to a given <definition> element. For example, suppose your XBL contains the following <definition>:

And suppose you create three instances of "myNS:button" as follows:

And suppose you want to attach a "DOMActivate" event listener to each of the three instances. You can certainly register three separate event listeners using either three separate event listener registration elements (e.g., in the case of SVG, you can use svg:handler) or using three separate DOM method calls (e.g., three calls to EventTarget::addEventListener). However, sometimes it is more convenient to define the event listener once as part of the <definition> element and then have the given event listener (in effect) automatically assigned to each bound element instance that corresponds to the given <definition>. In order to provide such convenience, XBL provides an automatic event forwarding mechanism for all events listeners attached to a <handlerGroup> element.

To illustrate, if we update the above example to add <handlerGroup> and <svg:handler> elements as follows:

The result is that the user agent must automatically attach an implicit "DOMActivate" event listener to each <myNS:button> element. If the DOMActivate event is fired and dispatched to any of the <myNS:button> elements, then the user agent must invoke DOMActivate event handlers defined by the <svg:handler> element.

"Shadowed" content

The <content> element is used inside shadow content to specify insertion points for explicit content that might already exist underneath the bound element. As far as the presentation model is concerned, any shadow content the binding places between the bound element and the <content> elements is interleaved between the bound element and its explicit children without affecting the document model (See illustration xbl_image_1.png / Figure B).

Figure B

Document Model

If the binding has a shadow content template, then its <template> element is deeply cloned. Otherwise, no shadow content will be generated for the bound element, its "xblShadowTree" attribute will be null, and its "xblChildNodes" attribute will equal its "childNodes" attribute. The newly cloned <template> element is then renamed to be a <shadowTree> element in the XBL namespace.

It is possible to manipulate the shadow content contained underneath a bound element using standard DOM APIs. If shadow content that contains a <content> element is removed, then any explicit children assigned to that element are relocated to the first <content> elements that match them.

Let's have a look at a more complicated example (Example3.svg). In this example bindings are used to make three new elements act like colored text blocks.

Example3.svg

In the following example (Example4.svg), an SVG file references a set of custom elements for flowcharting from an external file (Example4-flowcharts.svg ) using the <import> element, and then uses the flowcharting custom elements to lay out and render a flowchart.

Example4.svg

Figure C (xbl_image_2.png) is what we get for the output.

Figure C

Flowchart

Far and beyond

The sXBL specification is still under development. With its first public draft of sXBL, the SVG 1.2 feature formerly known as RCC (Rendering Custom Content) has been factored out into its own reusable namespace and reconciled to be forward-looking for use by other XBL grammars. sXBL is a mechanism for defining the presentation and interactive behavior of particular elements described in a namespace other than SVG's with a "binding". Bindings can be attached to elements by declaring, in XBL, that a particular element in a particular namespace is implemented by a particular binding. The element that the binding is attached to, called the bound element, acquires the new behavior and presentation specified by the binding.

An SVG 1.2 is the specification currently being developed, giving a new breed of unifying two-dimensional graphics and graphical applications in XML. And it seems that SVG will go far and beyond.