[whatwg] Feedback on UndoManager spec

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
> element.
>

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
manager.

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
correctly.

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.


Agreed.

- Ryosuke

Received on Wednesday, 26 October 2011 21:06:52 UTC