Bugzilla – Bug 13891
Allow author scripts that fire before or after every command
Last modified: 2012-02-24 14:09:46 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.
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.
*** Bug 12533 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 13118 ***