Re: [w3c/editing] undo manager (#209)

@johanneswilm Thank you for the explanation. I now see how control can be assumed by user code. I had the belief that the browser's storage for `UndoItem` elements had to be used with the actual elements, but the indirection in your example makes it clear that I was wrong.

Nevertheless, I have new concerns I would like to raise:

1. The `§ 6. Processing Model` leads me to believe that I can click outside of the `<input type="text">` (so that it is blurred), but inside the `<form>` that has an `undo scope` associated and I should be able to use the native undo/redo controls (i.e. : macOS's menu bar). The proposal doesn't specify whether that is actually true or not. I would expect it to be true. But then I would also expect the _beforeinput_ events to be dispatched to different fields, depending on where the editing events occured, even if none of them are currently focused. Not receiving those events would prevent taking full control of the stacks in the way you described in your previous reply.
1. I also fear it is going to be hard to take full control of the undo/redo stacks for one user-defined advanced `<input>` element if the `undo scope` is set on the `<form>` element as it forces the user to take care of the undo/redo behavior of the other regular `<input>` elements. In other words, clearing the undoManager's stacks also clears the `UndoItem` added by the user agent for other fields, which is too drastic, but there is a need to prevent the user agent from adding items for the advanced field itself.

-- 
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/209#issuecomment-560956668