Re: before/after editaction

On Thu, Oct 20, 2011 at 6:35 PM, Ojan Vafai <ojan@chromium.org> wrote:

> On Thu, Oct 20, 2011 at 1:06 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>> On Thu, Oct 13, 2011 at 7:20 PM, Ojan Vafai <ojan@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