Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:25 PM, Glenn Maynard wrote: > No text is selected, the user hits control-backspace, and then undo. The > restored word "world" now may or may not be selected, depending on the UA > and platform. Ah, okay. Got it.
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Thu, Oct 20, 2011 at 12:16 AM, Ryosuke Niwa wrote: > Hi, > The way selection is restored on WebKit after undoing selection is different > from the way it is done on Firefox and Internet Explorer. > Say you had "hello world" and "world" is deleted by an user. When the user > undoes the deletion, WebKit selects "world" whereas Firefox and Internet > Explorer do not select "world". WebKit's behavior matches Mac's NSTextView > and we probably would like to keep the current behavior. > However, there's no easy way for the user agent to figure out whether a > given transaction wants to select some contents on undo or not. In fact, we > don't even know whether we want to restore selection at all. If an automatic > transaction was modifying non-text nodes (e.g. SVG line elements), then > restoring selection isn't desirable at all. > I can think of two approaches to solve this problem: > > Let automatic transactions also have unapply/reapply and call them after > user agents had done its work, and make the user agent do nothing in regards > to selection. We can name them afterUnapply/afterReapply if we want. The > benefit of this approach is that it's very general and authors can do other > things as well while the disadvantage being author needs to be fully aware > of platform-convention of how selection is restore upon undo/redo. There are a couple of competing interests here: 1.) simple content editable scenarios that don't involve a lot of code should "just work" the way the underlying OS does 2.) code-driven editing should be completely normalized by default 3.) sophisticated code-driven editing will want to re-create OS-native behavior It seems like mixing #1 with #2 is what's causing the tension here. It almost feels like if you add any custom commands, you need to replace *all* of the default commands. Mix/match feels like the bug here. I don't like the implications of that in terms of apparent code-size, but I'm wondering how bad it really is. > Add a boolean restoreSelection and isDeletion properties to the Transaction > interface. The user agent restores the selection when the value is true and > does not restore selection when the value is false. isDeletion is true when > the transaction is meant to delete contents and false otherwise. (Maybe > negate the property so that common case will be easy?) The user agents can > probably use some heuristics to determine whether a given transaction is > deleting contents or not. > > But I don't like either solution so I'm open to your ideas and thoughts on > this. > Best, > Ryosuke Niwa > Software Engineer > Google Inc. > >
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:21 PM, Aryeh Gregor wrote: > I was assuming that Ryosuke meant that the word "world" was selected, > and the user hit delete, then undo. So it was selected before the > delete, and undoing should re-select it. > No text is selected, the user hits control-backspace, and then undo. The restored word "world" now may or may not be selected, depending on the UA and platform. -- Glenn Maynard
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:03 PM, Ehsan Akhgari wrote: >> Say you had "hello world" and "world" is deleted by an user. When the >> user undoes the deletion, WebKit selects "world" whereas Firefox and >> Internet Explorer do not select "world". WebKit's behavior matches >> Mac's NSTextView and we probably would like to keep the current >> behavior. > > This confuses me. I think that WebKit's behavior doesn't make a lot of sense > (at least in every case). For example, when Ctrl+Backspacing after a word. > But moreover, why is this relevant to the question of whether/how we should > restore a selection after undoing an operation? I was assuming that Ryosuke meant that the word "world" was selected, and the user hit delete, then undo. So it was selected before the delete, and undoing should re-select it.
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 1:03 PM, Ehsan Akhgari wrote: > > Say you had "hello world" and "world" is deleted by an user. When the > > user undoes the deletion, WebKit selects "world" whereas Firefox and > > Internet Explorer do not select "world". WebKit's behavior matches > > Mac's NSTextView and we probably would like to keep the current > > behavior. > > This confuses me. I think that WebKit's behavior doesn't make a lot of > sense (at least in every case). For example, when Ctrl+Backspacing after a > word. But moreover, why is this relevant to the question of whether/how we > should restore a selection after undoing an operation? > WebKit's trying to match Mac's NSTextView here. This is relevant because unapplying / reapplying an automatic transaction should behave like unapplying / reapplying native editing actions. - Ryosuke
Re: [whatwg] UndoManager: restoring selection after undoing deletion
> Say you had "hello world" and "world" is deleted by an user. When the > user undoes the deletion, WebKit selects "world" whereas Firefox and > Internet Explorer do not select "world". WebKit's behavior matches > Mac's NSTextView and we probably would like to keep the current > behavior. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? Ehsan
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Thu, Oct 20, 2011 at 3:16 AM, Ryosuke Niwa wrote: > However, there's no easy way for the user agent to figure out whether a > given transaction wants to select some contents on undo or not. In fact, we > don't even know whether we want to restore selection at all. If an automatic > transaction was modifying non-text nodes (e.g. SVG line elements), then > restoring selection isn't desirable at all. I think I'm missing something: why isn't it desirable?
[whatwg] UndoManager: restoring selection after undoing deletion
Hi, The way selection is restored on WebKit after undoing selection is different from the way it is done on Firefox and Internet Explorer. Say you had "hello world" and "world" is deleted by an user. When the user undoes the deletion, WebKit selects "world" whereas Firefox and Internet Explorer do not select "world". WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. However, there's no easy way for the user agent to figure out whether a given transaction wants to select some contents on undo or not. In fact, we don't even know whether we want to restore selection at all. If an automatic transaction was modifying non-text nodes (e.g. SVG line elements), then restoring selection isn't desirable at all. I can think of two approaches to solve this problem: 1. Let automatic transactions also have unapply/reapply and call them after user agents had done its work, and make the user agent do nothing in regards to selection. We can name them afterUnapply/afterReapply if we want. The benefit of this approach is that it's very general and authors can do other things as well while the disadvantage being author needs to be fully aware of platform-convention of how selection is restore upon undo/redo. 2. Add a boolean restoreSelection and isDeletion properties to the Transaction interface. The user agent restores the selection when the value is true and does not restore selection when the value is false. isDeletion is true when the transaction is meant to delete contents and false otherwise. (Maybe negate the property so that common case will be easy?) The user agents can probably use some heuristics to determine whether a given transaction is deleting contents or not. But I don't like either solution so I'm open to your ideas and thoughts on this. Best, Ryosuke Niwa Software Engineer Google Inc.
