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
