Re: [XBL] Bound elements implementing language specific interfaces

On Sat, 13 Jan 2007, Cameron McCormack wrote:
> 
> 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.

The <implementation> element allows any interface to be implemented 
(though, since XBL2 is by nature very dynamic, it is not possible to 
expose the actual implemented interface names in a way that is directly 
usable by statically typed languages).


> 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.

Which interfaces are implemented is at the control of the binding author. 
It would not be possible to require that an author implement a certain set 
of interfaces, since the author could simply not do it.


> 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.

When XBL2 is used with statically typed languages, using fixed <?xbl?> PIs 
to declare the bindings, one could specify a static implementation, e.g. 
using an implementation-specific attribute that specifies a binary. 
However, given the security implications of this, it doesn't seem wise. 
Short of doing this, however, it isn't clear how one could state what 
interfaces are supported. In particular, extending a binding wouldn't 
work, since that would not actually implement the interfaces (though it 
could theoretically specify the interfaces that are to be implemented, 
which, as mentioned above, leaves open the possibility of declared 
interfaces not being implemented by the author).


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

It's not clear to me how this is expected to work. Without the author 
actually implementing getBBox(), how is the UA supposed to implement it?


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

What's a "box-element" in HTML and what DOM APIs would this expose? I'm 
very confused as to what is intended here.


> This method has the advantage of being more flexible than the previous 
> suggestion: bindings can be declared to implement the desired 
> interfaces.

If the idea is to extend bindings that actually do implement the 
interfaces in question, then this is possible today, and doesn't require 
any special binding URIs -- someone just needs to implement bindings and 
make them available, just like people make JS libraries today.


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

I don't really understand what this would do.


> 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.

For statically typed languages, the <?xbl?> PI and static binary 
implementations are the expected solutions.


> 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.

In so far as I can work out what is being requested, it seems XBL already 
supports this. However, I'm not really sure I understand the proposal. 
Maybe some specific use cases and examples would help clarify the 
situation. Could you elaborate?

Thanks,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'