W3C home > Mailing lists > Public > public-appformats@w3.org > May 2007

Cloning XBL bound elements

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 08 May 2007 18:09:18 -0700
Message-ID: <46411F3E.5000007@sicking.cc>
To: "WAF WG (public)" <public-appformats@w3.org>

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.

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
Received on Wednesday, 9 May 2007 01:12:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC