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.