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

<?xml version=”1.0″?>
<svg width=”10cm” height=”3cm” viewBox=”0 0 200 60″
     xmlns=”http://www.w3.org/2000/svg” version=”1.2″
     xmlns:xbl=”http://www.w3.org/2004/xbl”
     xmsns:myNS=”http://www.example.com”>
<title>Example example1.svg – “hello world” sample file</title>
<desc>A simple “Hello, world” sXBL example where the
         rendering behavior of a custom element ‘myNS:HelloWorld’
         consists of an ‘svg:text’ element which has the string
         “Hello, world, using sXBL” inside.</desc>
<defs>

    <xbl:xbl>

      <!– The following ‘xbl:definition’ element defines the
         presentation and interactive behavior that must be used
         for all ‘myNS:HelloWorld’ elements in this document. –>
      <xbl:definition element=”myNS:HelloWorld>
        <xbl:template>
          <text>Hello, world, using sXBL</text>

        </xbl:template>
      </xbl:definition>

    </xbl:xbl>
</defs>

<rect x=”1″ y=”1″ width=”198″ height=”58″ fill=”none” stroke=”blue”/>

<g font-size=”14″ font-family=”Verdana” transform=”translate(10,35)”>

    <!– Here is an instance of an ‘myNS:HelloWorld’ element.
       The above binding definition attaches a shadow tree which
       defines alternative rendering and interactive behavior for this element.
       Instead of the standard SVG behavior where unknown elements are not rendered,
       the binding definition causes an ‘svg:text’ element to be rendered. –>
    <myNS:HelloWorld/>

</g>

</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>:

                <xbl:definition element=”myNS:button”>
      …
        </xbl:definition>

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

<myNS:button id=”b1″>…</myNs:button>
<myNS:button id=”b2″>…</myNs:button>
<myNS:button id=”b3″>…</myNs:button>

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:

<xbl:definition element=”myNS:button”>
<xbl:template>…</xbl:template>

   <xbl:handlerGroup>
      <svg:handlerev:event=”DOMActivate”…>…</svg:handler>
   </xbl:handlerGroup>
</xbl:definition>
…
<myNS:button id=”b1″>…</myNs:button>

<myNS:button id=”b2″>…</myNs:button>
<myNS:button id=”b3″>…</myNs:button>

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

     </xbl:template>
    </xbl:definition>
    <xbl:definition element=”green”>
     <xbl:template>
      <svg:text fill=”green”><xbl:content/></svg:text>

     </xbl:template>
  </xbl:definition>
    <xbl:definition element=”blue”>
     <xbl:template>
      <svg:text fill=”blue”><xbl:content/></svg:text>

     </xbl:template>
    </xbl:definition>
   </xbl:xbl>
</svg:defs>

<green> Green text.</green>
<blue> Blue text. </blue>

</svg: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

<!–XPointer reference to the location for the flowchart extensions –>
<xbl:import bindings=”example4-flowcharts.svg#flowcharts”/>

<!– Define elements that use the flowchart extensions. As a result of using
       the extensions, a shadow tree of low-level SVG (circle, rect, path elements)
       is attached to the ‘flowchart’ element. The user agent renders the shadow tree. –>
<flowchart xmlns=”http://example.org/flowcharts”
             x=”0%” y=”0%” width=”100%” height=”100%”>
  <terminalNode>Start</terminalNode>
    <processNode>Step 1</processNode>
    <processNode>Step 2</processNode>

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.

With so many agile project management software tools available, it can be overwhelming to find the best fit for you. We've compiled a list of 10 tools you can use to take advantage of agile within your organization.

PURPOSE Recruiting an automation specialist with the right combination of technical expertise and experience will require a comprehensive screening process. This Hiring Kit from TechRepublic Premium provides a flexible framework your business can use to find, recruit and ultimately hire the right person for the job. From the hiring kit: DETERMINING FACTORS, DESIRABLE PERSONALITY TRAITS ...

PURPOSE Recruiting a cybersecurity engineer with the right combination of technical and industry experience will require a comprehensive screening process. This hiring kit from TechRepublic Premium provides a flexible framework your business can use to find, recruit and ultimately hire the right person for the job. From the hiring kit: DETERMINING FACTORS, DESIRABLE PERSONALITY TRAITS ...

Make scalable vector graphics more active with sXBL