Re: before/after editaction

On Tue, Aug 30, 2011 at 6:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Aug 30, 2011 at 5:07 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> > On Tue, Aug 30, 2011 at 4:34 PM, Darin Adler <darin@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.