Re: [XBL] Bound elements implementing language specific interfaces

Hi Ian.

Cameron McCormack:
> > 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.

Ian Hickson:
> 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.

Bound elements must at least implement Element, but this implementation
isn’t done by the binding’s implementation element, it’s done by the UA.
What we would like is a way to specify that certain language-specific
interfaces be implemented by the UA on that element.  For example, it
would be impossible to implement these SVG interfaces on bound elements
as efficiently as the UA can, or sometimes even at all.  It doesn’t make
sense to force the user to implement the CSS cascade so that it can have
a functional 'style' attribute on a custom element.

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

It’s a declaration of what language-specific interfaces are to be
implemented on that object by the UA.

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

Ok there is a good point: I was working under the assumption that
because declaring the binding as being for a graphical element
(extending that special http://www.w3.org/2000/svg#graphical-element
binding), the UA knows that ex:star is working like a group element
(like a 'g'), so it will gather up the bboxes of the shadow children
and construct the final bbox itself.

Would you say that the standard way to handle this would be for the
implementation to call getBBox on each of the shadow children and
unioning them itself?  And similarly for everything else (a reference to
.style gets forwarded on to a .style property on a shadow child by the
implementation)?  Though for .style, changing .style would cause
attribute changes on the shadow child, which would then need to be
copied back on the bound element.  So it seems like it’s still a bit of
work for the binding author.

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

I mean, HTML elements that participate in the CSS box model.  One that
implements ElementCSSInlineStyle and HTMLElement.  This allows the style
attribute to be set on the bound element and for the UA to be able to
handle it as it would any other rendered element that implements
ElementCSSInlineStyle.

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

While that might be possible for all cases (though I think there might
be some that cannot), the implementations already exist inside the UA,
so it would be good to be able to use them rather than recreating them
in script.

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

This would be a method of declaring that a binding extends this
UA-built-in binding that implements HTMLElement and having that binding
still be at a regular HTTP URI like user created bindings.  That binding
document would then have a binding that has this predefined-binding
attribute on it to indicate to the UA that this is indeed the special
http://www.w3.org/2007/html-xbl-bindings#HTMLElement that is knows
about.  (Or if it doesn’t know about it, can ignore it or signal an
error or whatever.)

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

Would that be similiar to what I suggested just above?  Except without
the intermediate step of going to an actual binding document (the
http://www.w3.org/2007/html-xbl-bindings in this case)?

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

Hopefully I have clarified in this mail.  The request is for a feature
that allows a binding to indicate that the UA should implement some
particular interface(s) on that bound element.  To make a binding that
implements SVGStylable, for example (which exposes the .style
attribute), would be a lot of work (reimplementing CSS parsing, etc.).
Also how would the binding’s implementation interact with the CSS engine
to get the cascade to work properly?  Surely the UA should get the style
attribute and perform the CSS processing on the element, if the binding
is so declared.

Thanks,

Cameron

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

Received on Monday, 22 January 2007 12:26:10 UTC