Re: Cloning XBL bound elements

Here is what I am seeing:

>From the XBL2 spec:
------------
Bindings attached through CSS must only remain on the bound element as long
as the element continues to match the style rule. If at any time a
resolution of style on the element determines that a different binding
should be attached, the old binding (and all bindings that it explicitly
extends in its explicit inheritance chain) must be detached.
------------

What this is trying to say is tha the model for XBL is that the CSS cascade
(and presumably <binding> elements) are (conceptually) continuously
reapplied across the entire document with each change in the document's
Infoset to determine if any previously applied bindings should be detached
and any new bindings attached.

In the case of a clone, if there is a <foo> element that gets cloned and if
there is a <binding element="foo"> or a style declaration for "foo" which
applies a binding, then dynamic reapplication of bindings would cause the
cloned foo element to have the given binding attached to it. So, the clone
would get its own binding, its own separately built shadow tree, along with
invocation of xblBindingAttached() and things like that.

Jon




                                                                           
             Jonas Sicking                                                 
             <jonas@sicking.cc                                             
             >                                                          To 
             Sent by:                  "WAF WG (public)"                   
             public-appformats         <public-appformats@w3.org>          
             -request@w3.org                                            cc 
                                                                           
                                                                   Subject 
             05/08/2007 06:09          Cloning XBL bound elements          
             PM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Currently the spec doesn't mention what happens when you clone an
element that has XBL bindings attached to it. We can go two ways with
this I think.

Option A:
Either we could basically say that nothing special happens. When .clone
is called only the DOM element object is cloned. The new clone may or
may not get the same set of bindings attached to it, but in any case no
state is automatically carried over.

Bindings that do want to propagate data to the clone could register a
UserDataHandler which is notified about the cloning and could copy the
data over. However a binding on the original element can't reach in to
the same bindings private data on the clone, so there is no way to copy
private information over.

Option B:
We state that when the original element is cloned so is all the bindings
attached to it and all the data in all those bindings. The bindings that
are no longer applicable (since the clone doesn't live in the same place
in the DOM as the original element not the same CSS rules necessarily
match) are removed the same way as normal. A xblLeftDocument call is
also made if appropriate, i.e. if the original node lived in a document.

In other words, to the clone it will look as if it was living inside the
document with the exact same state as the original, and then removed
from the document.

We may also want to add some notification to tell the bindings on the
clone that they were cloned, just in case there is some state that needs
to be adjusted or they need to register somewhere.

Option C:
Something inbetween. When cloning we only clone the DOM element, but
then we could notify all bindings on the clone that existed on the
original element and give the notification function the inner object of
the binding on the original element.

Option D:
Combination of B and C. Have notification with a default implementation
that copies all the data and calls xblLeftDocument, but let the user
override it to do whatever the user wants.

Discussion:
The advantage of A is that it's the easiest to implement. However it
also means that you can't create bindings that deal well with cloning
and still keep all their data private.

Option B is very cool in that the binding doesn't have to do anything,
it's all automatic. But it might be a lot of work to implement, though I
don't think it'll be too bad. It is a bit scary to just unconditionally
just clone the binding data though. It's also tricky to know how deep
the data should be cloned, do you copy just the references and make them
point to the same objects? Or do you do a deep clone of the private data?

Option C is a compromise, the binding is still responsible for doing all
the cloning, but it's given all the tools needed for it.

D is basically what C++ does.

I think D gets my vote as long as we can draft a good notification.

/ Jonas