[whatwg] Feedback on UndoManager spec
rniwa at webkit.org
Wed Oct 26 21:06:52 PDT 2011
On Wed, Oct 26, 2011 at 8:21 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> Why is it problematic to move an element with an undoManager from one
> document to another. If all the data that the undomanager needs lives
> inside the undoManager object itself, it seems quite possible to move
> between documents or even interact with while not inside a document.
The problem is that if the undo manager has automatic transactions in them,
then they'll have references to nodes to undo/redo transactions. But those
nodes's owner document is still that of the old document. At least in
WebKit, this will be a bit of an issue.
I guess we can just slightly fail in those cases when transactions are
attempted to be undone or redone if you'd prefer that.
On Wed, Oct 26, 2011 at 8:26 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> I don't see why the undoManager implementation would need to care why
> the element it's attached to is in the document tree or not all. All
> it needs to do is to observe modifications to the descendants of the
You're right. I got UndoManager on a detached node, UndoManager on an
adopted node, and the active undo manager all mixed up. It's fine to have
UndoManager on a detached node since it can never host the active undo
Note that the upcoming mutation observer spec makes no difference
> between nodes in a document and nodes which are not. So if the
> undoManager uses the same backend, or is even built on top of it, then
> things will just automatically work.
I thought about implementing UndoManager on top of new DOM mutation observer
API, but the asynchronous nature of new notification API makes it a little
hard, if not impossible, to implement UndoManager's synchronous API
I think there is a lot of value in allowing a element to be moved
> around in a document. Even when that element, or a descendant of it,
> has a undoManager attached.
More information about the whatwg