- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Thu, 27 Oct 2011 16:04:35 -0700
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor <ayg at aryeh.name> wrote: > On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > > I meant properties authors added to nodes. e.g. > > span.myProperty = true; > > Should span be removed by some automatic transaction, authors may expect > it > > to be restored on undo. > > That sounds like the ideal behavior, unless it's too difficult to > implement. If authors just used Node.dataset, that would solve their > problem, but it would be better to behave as expected to start with. > Since Gecko and WebKit can both implement this, I'd expect other UAs to do the same. I'll update the spec accordingly. > The assumption is transaction works like a regular object unless otherwise > > stated. I guess I can cite your example though. > > Some APIs copy objects in some way instead of maintaining a reference. > For instance, in WebKit, Selection.getRangeAt() doesn't return the > same object you added with Selection.addRange() (although the spec > currently says it should). It seems best to be explicit. > In the revised spec, I'd say it'll be an entry in the undo transaction history so the wording there should make clear that they're identical objects. >> But this doesn't define what happens in the face of manual > >> transactions. Also, it's not precise even if there are no manual > >> transactions. > > > > UAs don't do anything for manual transactions. They just call > > unapply/reapply. > > I mean, if there's a mix of automatic and manual transactions, and the > manual transactions don't restore the exact same DOM, nothing says how > the UA should unapply/reapply the automatic transactions. It just > says "the user agent still must do its best effort to restore the DOM > state." > Right. If authors decide to mess with DOM state of the highest node affected by an automatic transaction, user agents can't do anything to fix that. What's the use-case for manual transactions anyway? I'm sure it's > been discussed, but your spec doesn't say. It could use an example. > To be able to mix automatic transactions and manual transactions. Consider an application that lets you edit both text and drawing on canvas. Such an app may implement drawing action on canvas as a manual transaction while adding some extra editing commands as automatic transactions and manage them all in the same undo manager. > This is well defined in terms of DOM state. The spec says UAs should > restore > > the DOM state > > so it all depends on how DOM state is defined. > > I also vaguely remember Ehsan telling me Gecko might have a trouble > > restoring the exactly same object > > on undo/redo because of the way its undo and redo are implemented. > > Well, at some point we want to make sure we have interop if possible, > unless it's really performance-critical that this be UA-dependent. > IMO, it's critical that this part is left implementation dependent. - Ryosuke
Received on Thursday, 27 October 2011 16:04:35 UTC