Re: XBL in document fragments

Jim,
I personally agree with your analysis on all fronts, but the W3C needs to 
consider these issues formally and update the sXBL specification to reflect 
decisions.

See below for a couple of detailed comments.

Jon Ferraiolo
Adobe Systems, Inc.
sXBL co-editor

At 10:50 AM 9/28/2004, Jim Ley wrote:


>"Erik Arvidsson" <erik@eae.net> wrote in message
>news:4159A03B.1020406@eae.net...
> > I'm not totally sure about this. The important part is that both the
> > following works:
> >
> > <p id="p" style="binding:url('test.xml#test')">Foo</p>
> > <script type="text/javascript">
> > // assuming the binding adds a test method
> > document.getElementById("p").test();
> > </script>
> >
> > and assuming that the document has defined my:test to have a binding
> >
> > var el = document.createElementNS(myns, "test");
> > el.test();
>
>but with a CSS binding, you should not expect the 2nd to work, since you
>can't work out the cascade until it's in the document, I agree with pure
>name binding in sXBL it's a different issue.

Yes, agreed. How can you perform the inheritance part of the CSS cascade 
without inserting into the document?


>Equally, I can't think of any scenario without custom methods where it
>matters (therefore there's no need to decide this for sXBL, and we can wait
>to decide on this behaviour until a complete XBL specification.)

Yes, agreed.


> > The important part that Mozilla and IE50 missed is that the interface of
> > the bound element needs to be available all the time.
>
>Do you have an actual use case why - 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.

It seems to be that an xbl:prebind event handler script can traverse the 
elements and attributes in the cloned subtree using DOM3 Core facilities 
(e.g., firstChild, nextSibling, etc.), but no extended DOM features are 
available that require attachment and special namespace-specific processing 
(e.g., getComputedValue(), getBBox()) until the subtree is attached to 
xblShadowTree.


>Cheers,
>
>Jim.

Received on Tuesday, 28 September 2004 20:58:52 UTC