Re: Proposal to ammend the composition event spec.

More points about the second proposal:

For the second proposal, we do:
1. fire compositionupdate event after mutating the dom
2. delete composition string before firing compositionend event
3. fire textInput after compositionend but before inserting the text

So that:
1. We can know when composition mode starts by hooking compositionstart
event
2. We can get updated composition string in compositionupdate handler
synchronously
3. We can know when composition mode finishes by hooking compositionend
event
4. textInput event can be cancelled in order to revert the DOM tree
completely.

About the deleting and inserting again issue: because compositionend and
textInsert events are fired in the same event loop iteration, it should not
cause additional rendering. So the visual and performance impact would
be negligible.

The only issue of this proposal is: we need to change composition* events to
non-cancellable. But anyway, cancelling these events make completely no
sense. If somebody really wants to cancel the composition process, he/she
can just cancel the keydown event.

Regards
James Su

在 2010年5月18日 上午7:49，Daniel Danilatos <daniel@danilatos.com>写道：

> The spec should make it clear that mutations must be bounded between
> compositionstart and compositionend events.
>
> Background:
>
> https://bugs.webkit.org/show_bug.cgi?id=31902
> Hironori has asked me to write up this email arguing for adjusting the
> spec.
>
> Summary:
>
> >From our implementation experience, it is broken not to bound
> mutations with compositionstart and compositionend events. not having
> this severely limits their utility - and requires large amounts of
> hacky workaround code, even involving asynchronous logic.
> Firefox already has the correct behaviour, and it is off firefox that
> we largely based the spec (so the spec should be adjusted)
> The fix for webkit is already implemented - it was just rejected
> because it supposedly doesn't match the spec; once the spec is
> adjusted, both Webkit and FF will be in line with eachother with
> respect to the composition events.
> The tricky thing to consider is, when should a textinput event be
> fired. This is a secondary issue to the strong requirement, that
> mutations must be bounded by composition events. The options then seem
> to be:
>
> (Compatible with existing spec) Fire textInput after the composition
> has ended - thus textInput would no longer be a pre-input-event, but
> really, it never was, as the dom is mutating before the event anyway.
> Currently, webkit creates the composition text, then removes it again,
> just so it can then fire the textInput event, and if not cancelled,
> will then insert the content.
> (Compatible with existing spec) If textInput really, really must fire
> before input, even though the dom has already been mutating from the
> composition, then delete the composition, but do that BEFORE the
> compositionend event. then fire a regular cancellable textInput. In my
> opinion this seems wasteful, though.
> (Incompatible with existing spec) Fire textInput before every change.
> This is more generally consistent, especially with other proposals to
> extend textInput (or introduce a similar event) that fires before
> every change to the DOM at all, including for things like paste, undo,
> and deletion. For the use case where the application wants to know
> when some content is ready and in a consistent state (i.e. not during
> composition), a post-change event is more applicable. Such an event
> does not have to fire after every single change.
> We shouldn't fear the final option above - the composition events spec
> is still in its infancy. Now is the time to make meaningful changes.
>
> Best,
> Dan
>
>