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

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

You seem to be the first browser person saying this, so I would like to find out what exactly is hindering this from happening. Maybe it's just browser developers who have to rethink about how some things can be put together. Or maybe we need to reformulate this slightly to get around restrictions browser makers face.

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

Ok, well that means it's kind of useless. What exactly is hindering browsers from creating two new menu entries that have nothing to do with the existing undo/redo functionality that are labeled "undo" and "redo" which are shown whenever the selection is in a contenteditable area? 

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

I've had a look at it. So far I have not been able to find any JavaScript project that would seem to have any use of it. It would just mean they have to spend a lot of time implementing something that gives them no advantage.

I think we need to look at what advantages assistant technologies have from using the current native undo stack, and then look at how we can give access to that to the JavaScript undo stacks editors are using anyway. 

-- 
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-249625458