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

> Wouldn't it be good to provide menu entries that would allow iCloud Pages to function as it does now, but with working Undo/Redo buttons? It Apple's policy requires having one global undo stack on some types of pages, should we maybe look for a solution that allows for both a global undo stack and one that has separate undo stacks?

Right, this is likely to be implementation-dependent behavior like focus and selection.  The key here is to allow browser vendors to implement either behavior and let web authors choose which behaviors they want.  This is why the old undo manager API had `undoscope` attribute.

The only problem with the old API was that being able to add a new undoscope via a content attribute made things way too complicated for implementors.  I think a better solution would be adding a flag on `ShadowRoot`.  Since builtin text fields are modeled like they have their own shadow root, any UA that uses a separate undo stack per text field (e.g. Gecko) can be modeled using this way.

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