- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 07 Sep 2011 12:47:21 +0300
- To: Ryosuke Niwa <rniwa@webkit.org>
- CC: public-webapps <public-webapps@w3.org>, Alex Russell <slightlyoff@chromium.org>, Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, Ehsan Akhgari <ehsan@mozilla.com>, Annie Sullivan <sullivan@chromium.org>, Aryeh Gregor <Simetrical+w3c@gmail.com>, Anne van Kesteren <annevk@opera.com>
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. > >
Received on Wednesday, 7 September 2011 09:48:35 UTC