Re: [w3c/editing] Removal of browser built-in Undo stack functionality from contenteditable (#150)

> The issue here is that the browser's undo-stack is unusable in the case of all editors that use even just a little bit of JavaScript to manipulate the DOM due to user intentions.

The issue is well understood. The problem is that your proposed solution is not implementable.

> Also, it needs to be able to add and remove great numbers of items to the undo and redo stack at arbitrary positions.

Removing and inserting arbitrary number of items is possible but not at arbitrary positions for the same reason we can't just enable/disable undo/redo.  In order to do that kind of manipulation, one has to remove all entries up to the entry to be removed, and re-insert all succeeding entries.

> @rniwa I have been looking through old discussions, but all I can find is a system whereby the browser changes the DOM and automatically applies DOM changes. That seems to be what we want to get away from now.

The old undo manager API did support automatically rolling DOM changes, but also provided a mechanism to insert an entry without any DOM mutations that get automatically unapplied & reapplied.  Basically, you just create a DOM transaction, don't do anything inside the transaction, and insert it to the undo manager.  Because a transaction can be associated with any JS data, and `undo` / `redo` events will be fired upon unapplying and reapplying those transactions, scripts can do whatever they want to do upon receiving those events.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/150#issuecomment-249623106