- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Mon, 7 Nov 2011 11:15:34 -0500
(sorry for the long delay in responding, life is sometimes flaky for me right now) On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > But that manual transaction may be mutating DOM outside of the editable > region. i.e. in the slide app case, you may have plane that's showing a list > of slides. Since that's a part of the UI provided by the app, the DOM state > of that UI may change over time without necessarily undoing or redoing > insertions and removals of slides. So when you undo/redo an insertion of a > slide, the exact change you make to the DOM may not be a mere > restoration.?Yet, the app still may want undo/redo in text fields to be > implemented by UAs. What you're saying is that maybe there will be parts of the DOM that the author doesn't want the UA to touch? In that case, how about we let the author specify that UA undo/redo shouldn't affect certain subtrees? E.g., have the plane that shows a list of slides in <div noundo> or something like that. Then just like the UA doesn't undo/redo DOM changes outside the undo scope, it shouldn't undo/redo changes in a noundo region (or whatever you want the attribute to be called). This way, again, the UA will never be faced with the problem of undoing/redoing changes in a part of the DOM that the author may have tampered with. This is critical for making the APIs work reliably -- if automatic undo/redo can fail because of authoring bugs, authors won't want to use it. It also simplifies the API by getting rid of the distinction between automatic and manual transactions. Are you (or anyone) making a list of use-cases somewhere? If not, I guess I will, because it's really essential to designing a good API.
Received on Monday, 7 November 2011 08:15:34 UTC