W3C home > Mailing lists > Public > www-svg@w3.org > September 2004

Re: XBL in document fragments

From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
Date: Wed, 29 Sep 2004 09:59:27 -0700
To: Jim Ley <jim@jibbering.com>, www-svg@w3.org
Message-id: <6.1.1.1.2.20040929095205.03be08b8@mailsj-v1.corp.adobe.com>

At 06:05 AM 9/29/2004, Jim Ley wrote:


>"Jon Ferraiolo" <jon.ferraiolo@adobe.com> wrote in message
>news:6.1.1.1.2.20040928113603.03bbb640@mailsj-v1.corp.adobe.com...
> >> I'm struggling to really see it, and
> >>can think of many situations where having the bind events before it's in
> >>the
> >>document are problematical (anything that relies on sizes etc. from the
> >>document.  You'd certainly get considerable complications, and start
> >>having
> >>to track mutation events as the element was inserted into the document.  I
> >>think it would be much easier to say that the binding happened on
> >>insertion.
> >
> > What we have done with sXBL is that there is an xbl:prebind event which
> > happens after raw XML cloning of <xbl:template> but before insertion into
> > xblShadowTree and an xbl:bound event which happens after insertion into
> > xblShadowTree (and after recursive XBL processing). When the xbl:prebind
> > event is fired, you are given a handle to the cloned <xbl:template>.
> > However, at this point the cloned subtree is unattached to any document;
> > thus, my analysis and understanding is that neither CSS nor recursive XBL
> > processing can be applied yet.
>
>My concern with doing the binding before the element is embedded in the
>document, makes it considerably more complicated to do things like <OL><LI>
>from HTML in sXBL - the LI sXBL component will need to know the child index
>of the LI element to provide the numbering - if the binding happens after
>creation rather than insertion, we have a more complicated problem, and
>anything that was created in the initial binds are of little use.   Of
>course we'd need to track the mutation events as the nodes move around for a
>proper implementation of LI, but for a simple implementation when you know
>nodes are only going to be appended to the end, and are not going to be
>re-inserted it would be nice not to have to worry about it.
>
>Jim.

Jim,
There is both an xbl:prebind event which is fired before attachment and an 
xbl:bound event which is fired after attachment. My experience is that the 
vast majority of components are best implemented by implementing xbl:bound 
event handlers and just never doing an xbl:prebind event. The only reason 
for an xbl:prebind is for the small percentage case where you need to do 
some initial accounting within the component implementation before 
recursive XBL processing happens on the embedded custom elements within the 
shadow tree.

So, the question back to you is whether OL/LI can be implemented via 
xbl:bound instead of xbl:prebind? I would think so. Also, I would point out 
that I think it is much more important to provide a robust facility for 
professional developers who create robust components with all of the 
appropriate mutation event handlers to take care of things like insertion 
and deletion of LI elements than it is to create an "easy-to-use" mechanism 
which might allow amateurs to create components which do not take care of 
insertion and deletion and thus are not robust.

Jon Ferraiolo
Adobe Systems, Inc.
sXBL co-editor 
Received on Wednesday, 29 September 2004 16:59:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:55 UTC