This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13891 - Allow author scripts that fire before or after every command
Summary: Allow author scripts that fire before or after every command
Status: RESOLVED DUPLICATE of bug 13118
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
: 12533 (view as bug list)
Depends on:
Reported: 2011-08-24 19:32 UTC by Aryeh Gregor
Modified: 2012-02-24 14:09 UTC (History)
7 users (show)

See Also:


Description Aryeh Gregor 2011-08-24 19:32:37 UTC
Ehsan, Ryosuke, Annie, Jonas, and I spoke about this today.  We agreed that some use-cases for mutation events in editing would best be served by allowing authors to specify scripts that fire before and after every command, particularly:

* Replace a command by an entirely custom implementation.  This is useful for commands that are fired by the UA rather than the author, like insertText or insertParagraph.  I've been told Safari also automatically lets the user run bold/italic/etc. via the usual keyboard shortcuts.
* Modify the results of a command.  E.g., adding classes or id's to added elements.

Actual events that wait for the event loop are inappropriate -- we need these to run immediately before or after the command.  Scripts that run before the command need to be able to cancel it for the first use-case.  Scripts that run after it need info about what it did, like a list of newly-created elements, for the second use-case.

Speccing the before part should be easy if we provide no info except the command name and value.  Speccing the after part will require careful work to decide which nodes to expose.  If new use-cases arise, we can expose more info for both the before and after events.

This might provide a better solution to some of the use-cases for a mutation events replacement, but not all of them.
Comment 1 Aryeh Gregor 2011-08-29 18:33:51 UTC
Copying some more details from the Etherpad notes:

For the before event, we might want to provide a normalized value as well as the actual value, so that colors etc. are in an easy-to-use format.  It's not clear whether we want to fire the event if the browser would throw a NOT_SUPPORTED_ERR or similar -- it doesn't seem like a huge deal either way.

For the after event, we really need exact use-cases.  Some use-cases that have been spotted in the wild are:

* Add a custom class to the result of insertImage.
* Change <b> to <strong> for the bold command.

We should start by adding a limited number of properties here, and add more only as we're given clear use-cases, to keep the complexity down.
Comment 2 Aryeh Gregor 2011-11-07 20:29:05 UTC
*** Bug 12533 has been marked as a duplicate of this bug. ***
Comment 3 Aryeh Gregor 2012-02-24 14:09:46 UTC

*** This bug has been marked as a duplicate of bug 13118 ***