Re: before/after editaction
On Thu, Oct 20, 2011 at 7:02 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't think we can make such an assumption. People mutate DOM on input event all the time: http://codesearch.google.com/#search/q=%20oninput=type=cs Including any DOM mutations in the on-going transaction would mean that UA will end up trying to revert those changes since the entire document shares the one undo scope by default, and may end up mutation DOM in unexpected ways. I'll add that, most significantly, when reverting DOM changes made in the input event listener fails, the UA may end up aborting the undo/redo process before even get to revert the actual DOM changes made by the user editing action or execCommand. I do think sites will do that, but I expect that in practice the DOM changes they are making are related to whatever the input was and will undo fine. Having just beforeInput/input will be better than having input/beforeeditaction/aftereditaction (and possibly still beforeInput). We should strive for that end result if we can achieve it. It makes the input event more useful in ways that meet more use-cases than just aftereditaction. At the same time it avoids growing the platform unnecessarily with more events to make sense of.
Re: before/after editaction
On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai o...@chromium.org wrote: Overall I really like the proposal (both having the events and Jonas's addition to include them in the undo transaction). We'd fire the afterEditAction exactly everywhere we currently fire the input event though. Instead of adding two new events, could we instead add a beforeInput event as the beforeEditAction. Then add to both beforeInput and input an action property that is the edit action that was taken.* Yeah that'll be clean and neat way to support this. We probably need to add two properties though because some execCommand takes string value. The only downside I see to reusing input is that it might complicate Jonas's suggestion to include edits during the afterEditAction in the undo transaction. Although, my intuition is that there is *not* web content that depends on script executed during the input event not entering the undo stack. Right. I think we probably need to avoid firing them inside a transaction to maintain the backward compatibility. - Ryosuke
Re: before/after editaction
On Thu, Oct 20, 2011 at 6:35 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Oct 20, 2011 at 1:06 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai o...@chromium.org wrote: Overall I really like the proposal (both having the events and Jonas's addition to include them in the undo transaction). We'd fire the afterEditAction exactly everywhere we currently fire the input event though. Instead of adding two new events, could we instead add a beforeInput event as the beforeEditAction. Then add to both beforeInput and input an action property that is the edit action that was taken.* Yeah that'll be clean and neat way to support this. We probably need to add two properties though because some execCommand takes string value. The only downside I see to reusing input is that it might complicate Jonas's suggestion to include edits during the afterEditAction in the undo transaction. Although, my intuition is that there is *not* web content that depends on script executed during the input event not entering the undo stack. Right. I think we probably need to avoid firing them inside a transaction to maintain the backward compatibility. I really don't expect this to cause compat problems. I think we can move forward with whichever API we think is best assuming no compat problems and revise it should we hit compat problems once vendors start implementing it. I don't think we can make such an assumption. People mutate DOM on input event all the time: http://codesearch.google.com/#search/q=%20oninput=type=cs Including any DOM mutations in the on-going transaction would mean that UA will end up trying to revert those changes since the entire document shares the one undo scope by default, and may end up mutation DOM in unexpected ways. - Ryosuke
Re: before/after editaction
On Thu, Oct 20, 2011 at 6:57 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't think we can make such an assumption. People mutate DOM on input event all the time: http://codesearch.google.com/#search/q=%20oninput=type=cs Including any DOM mutations in the on-going transaction would mean that UA will end up trying to revert those changes since the entire document shares the one undo scope by default, and may end up mutation DOM in unexpected ways. I'll add that, most significantly, when reverting DOM changes made in the input event listener fails, the UA may end up aborting the undo/redo process before even get to revert the actual DOM changes made by the user editing action or execCommand. - Ryosuke
Re: before/after editaction
On Tue, Aug 30, 2011 at 6:39 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote: My question was not about the undo command. I meant that if I implemented a handler for the aftereditaction event that changed b tags to strong tags, how would the undo machinery undo what I had done? Ah, I see. So UA won't be able to undo/redo those DOM changes as of now. However, authors can use UndoManager and transactions (see http://rniwa.com/editing/undomanager.html) to hook into UA's undo manager. e.g. if authors wanted UAs to manage undo/redo for those changes, they can make those changes as a managed transaction. My suggestion during the above mentioned Toronto meeting was that the UA starts a managed transaction before firing the beforeEditAction event. This transaction would record any changes done during the beforeEditAction and the afterEditAction event. It would also record the changes done by the UA itself as the actual edit action. This way, and changes done during the beforeEditAction and afterEditAction events would be automatically part of the undo-able action created in response to the command. So if the page cancels the beforeEditAction in response to a bold command, and instead inserts strong elements, then this modification would be undone if the user or the page initiates an undo. I think this proposal got minuted for the first day. The one thing that this doesn't solve is what to do in cases when the page wants to replace the current action with a manual transaction rather than the managed one usually created. Ideas for how to solve that are welcome. Overall I really like the proposal (both having the events and Jonas's addition to include them in the undo transaction). We'd fire the afterEditAction exactly everywhere we currently fire the input event though. Instead of adding two new events, could we instead add a beforeInput event as the beforeEditAction. Then add to both beforeInput and input an action property that is the edit action that was taken.* The only downside I see to reusing input is that it might complicate Jonas's suggestion to include edits during the afterEditAction in the undo transaction. Although, my intuition is that there is *not* web content that depends on script executed during the input event not entering the undo stack. Ojan * Those of you who read www-dom will remember I proposed this a long time ago to that working group. At the time, I coupled with this that we should kill the textInput event as well since beforeInput would be a super-set. There wasn't really opposition to adding beforeInput/input except that some felt the DOM Events spec was too far along to add new features and some were really attached to keeping textInput.
Re: before/after editaction
Le 31 août 2011 à 03:39, Jonas Sicking a écrit : The one thing that this doesn't solve is what to do in cases when the page wants to replace the current action with a manual transaction rather than the managed one usually created. Ideas for how to solve that are welcome. Is there also an issue with `afterEditAction` event being an `undo`? -- Karl Dubost - http://dev.opera.com/ Developer Relations Tools, Opera Software
Re: before/after editaction
On 08/31/2011 02:00 AM, Ryosuke Niwa wrote: Greetings all, During the very constructive meeting in Toronto http://ehsanakhgari.org/blog/2011-08-31/future-editing-web, we came to a conclusion that we want events that fire before after user editing action and execCommand take place. Let us call these events beforeEditAction and afterEditAction respectively. From Ehsan's blog: The beforeeditaction event would fire before the browser initiates handling of an editing command. It would be cancelable, so that web applications which do not want certain commands enabled can just cancel the respective events. The aftereditaction event would fire when the browser is done performing the editing action. This event will provide semantic information about the editing operation performed, and will allow web content to alter the DOM generated as a result of the editing action. Think of a web application which wants to use strong tags instead of b tags for bold text generated by the bold command. With aftereditaction, the web application can just fix up the DOM after the browser has modified it to use strong tags. Can we add these events? What happens if beforeeditaction tears down the document, or changes the document significantly or closes the window etc. (Those a generic problems with before* events) Best regards, Ryosuke Niwa Software Engineer Google Inc.
Re: before/after editaction
On Wed, Sep 7, 2011 at 5:47 AM, Olli Pettay olli.pet...@helsinki.fi wrote: What happens if beforeeditaction tears down the document, or changes the document significantly or closes the window etc. (Those a generic problems with before* events) It shouldn't make any difference. The behavior of all the edit actions is well-defined for any document state. This kind of thing is only a problem for something like a mutation event, where the exact action to be performed is predetermined and might no longer make sense after DOM changes. But if you're just doing document.execCommand(foreColor, false, red), then it doesn't matter what any code does that runs before it. If it destroys the document or gets rid of the selection or whatnot, execCommand() will behave as it normally does in such a situation, probably either doing nothing or throwing an exception.
Re: before/after editaction
On Tue, Aug 30, 2011 at 4:08 PM, Darin Adler da...@apple.com wrote:
How would this work with undo?
That's a debatable point. Presumably, we'll be adding undo/redo events as
well so we could not fire before/after edit action events for
execCommand('undo') and execCommand('redo'). I know it's kind of ugly but I
think undo and redo are very special commands.
- Rysouke
Re: before/after editaction
On Aug 30, 2011, at 4:13 PM, Ryosuke Niwa wrote:
On Tue, Aug 30, 2011 at 4:08 PM, Darin Adler da...@apple.com wrote:
How would this work with undo?
That's a debatable point. Presumably, we'll be adding undo/redo events as
well so we could not fire before/after edit action events for
execCommand('undo') and execCommand('redo'). I know it's kind of ugly but I
think undo and redo are very special commands.
My question was not about the undo command. I meant that if I implemented a
handler for the aftereditaction event that changed b tags to strong tags, how
would the undo machinery undo what I had done?
-- Darin
Re: before/after editaction
On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote: My question was not about the undo command. I meant that if I implemented a handler for the aftereditaction event that changed b tags to strong tags, how would the undo machinery undo what I had done? Ah, I see. So UA won't be able to undo/redo those DOM changes as of now. However, authors can use UndoManager and transactions (see http://rniwa.com/editing/undomanager.html) to hook into UA's undo manager. e.g. if authors wanted UAs to manage undo/redo for those changes, they can make those changes as a managed transaction. - Ryosuke
Re: before/after editaction
On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote: My question was not about the undo command. I meant that if I implemented a handler for the aftereditaction event that changed b tags to strong tags, how would the undo machinery undo what I had done? Ah, I see. So UA won't be able to undo/redo those DOM changes as of now. However, authors can use UndoManager and transactions (see http://rniwa.com/editing/undomanager.html) to hook into UA's undo manager. e.g. if authors wanted UAs to manage undo/redo for those changes, they can make those changes as a managed transaction. My suggestion during the above mentioned Toronto meeting was that the UA starts a managed transaction before firing the beforeEditAction event. This transaction would record any changes done during the beforeEditAction and the afterEditAction event. It would also record the changes done by the UA itself as the actual edit action. This way, and changes done during the beforeEditAction and afterEditAction events would be automatically part of the undo-able action created in response to the command. So if the page cancels the beforeEditAction in response to a bold command, and instead inserts strong elements, then this modification would be undone if the user or the page initiates an undo. I think this proposal got minuted for the first day. The one thing that this doesn't solve is what to do in cases when the page wants to replace the current action with a manual transaction rather than the managed one usually created. Ideas for how to solve that are welcome. / Jonas
