W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: before/after editaction

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 20 Oct 2011 18:35:52 -0700
Message-ID: <CANMdWTtfp4+ZS6m99ahVjS9J2-=PXdmTbCfzW=HPbn5kW0bgGg@mail.gmail.com>
To: Ryosuke Niwa <rniwa@webkit.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Darin Adler <darin@apple.com>, public-webapps <public-webapps@w3.org>
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.
Received on Friday, 21 October 2011 01:36:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC