[XBL] Bound elements implementing language specific interfaces

Hi.

This is a last call comment from the SVG WG on the XBL 2 Editor’s Draft
(dated 12 January 2007).

For the best integration of bound elements in a host language, certain
interfaces need to be implemented by those bound elements.  For example,
a custom graphical SVG element should implement SVGStylable, so that it
can be styled, and SVGTransformable, so that its geometry can be
transformed.

In sXBL (and ASV6pr1’s implementation of RCC), it was perhaps assumed
that all custom elements would implement these SVG interfaces.  In a
more host language agnostic binding language such as XBL 2.0, this won’t
work: it’s unreasonable to have an HTML+SVG CDF browser have all
elements that aren’t in the HTML or SVG namespace implement SVGStylable,
etc., especially if the custom element were a child of an HTML element.

We have two suggestions on how to handle this.

The first suggestion is to have all bound elements implement the
“standard” interfaces that are appropriate according to the language of
the parent element.  For example, bound elements that are children of an
html:div element would implement HTMLElement and ElementCSSInlineStyle,
and those that are children of an svg:g would implement SVGStylable,
SVGTransformable, SVGLocatable, etc.

This method is simple; there’s no need to change the way bindings are
specified.  However, a binding whose shadow tree is an SVG fragment
can’t be used on an element that is a child of an HTML element and
vice versa.  Also, not all custom elements in SVG are “graphical”
elements (and so getBBox wouldn’t make sense on them, for example).
These would have to be overridden in the binding to throw an exception
or something.

The second suggestion is for the bindings to say what interfaces they
implement.  This could be done by having bindings extend a “special”
(standard) binding that the UA knows about.

  <xbl:binding element="ex|star"
               extends="http://www.w3.org/2000/svg#graphical-element">
    <xbl:template>
      <path d="…"/>
    </xbl:template>
  </xbl:binding>

This would indicate that elements bound by this binding would also
implement the standard SVG interfaces for graphical elements.  For
example:

  <ex:star id="s" fill="yellow" transform="rotate(30)"/>
  <script>
    var s = document.getElementById("s");
    var b = s.getBBox();
    …
  </script>

The standard presentation attributes and the transform attribute are now
handled on the ex:star element.

Or an HTML example:

  <xbl:binding element="ex|datePicker"
               extends="http://www.w3.org/1999/xhtml#box-element">
    …
  </xbl:binding>

  <ex:datePicker style="font-size: 12pt"/>

This method has the advantage of being more flexible than the previous
suggestion: bindings can be declared to implement the desired
interfaces.  It also fits in nicely with the model of bindings
augmenting the DOM objects of the elements they bind.  A disadvantage is
that UAs must know about these special binding URIs and handle them
differently from regular ones.  Would a UA that doesn’t understand SVG
try to fetch http://www.w3.org/2000/svg to look for a non-existing
binding element?

On the other hand, it seems overkill to require the UA to fetch that
special binding URL every time it is used.  Two solutions present
themselves: use non-dereferenceable URIs for these special bindings,
such as URNs, or put actual bindings at the locations but have UAs not
fetch them if they recognised as a special one.

For example, if http://www.w3.org/2007/html-xbl-bindings were used, it
could contain something like:

  <xbl xmlns="…">
    <binding id="HTMLElement" predefined-binding="true"/>
  </xbl>

and then bindings would use:

  <xbl:binding
    extends="http://www.w3.org/2007/html-xbl-bindings#HTMLElement">
    …
  </xbl:binding>

UAs that don’t support HTML will fetch the URL, see the
predefined-binding attribute, and realise that they cannot handle this
binding.  UAs that do support HTML will recognise the URL and not fetch
it.

Owners of host languages would define these special bindings and what
they mean for bound elements.


All of these suggestions don’t work well with strongly typed languages
like Java, though.  Elements can be bound and unbound at any time, and
the particular interfaces that a DOM object implements can’t actually
change in Java.  However, given the focus on ECMAScript in XBL 2.0
already, we don’t really see this as a problem.


Integration of custom elements in the way described in this mail is
essential for SVG (and we suspect it would also be of use to HTML and
other languages).  At SVG Open in 2005, there were many projects which
demonstrated uses of sXBL and RCC, the two implementations of which
(Batik and ASV6pr1) both have the ability to access the standard
graphical element interfaces on custom elements.  The SVG WG requests
that such a feature be introduced.

Thanks,

Cameron
-for the SVG WG

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Saturday, 13 January 2007 00:51:11 UTC