Re: Proposal to ammend the composition event spec.

On Fri, May 21, 2010 at 4:17 PM, James Su <suzhe@chromium.org> wrote:

> 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.
>

What's the use-case for canceling the confirmed composition? I can
see canceling individual keypresses, but I don't see why someone would want
to cancel the composition when the user just confirmed it.

Firing textInput before each time the DOM is modified does make
compositionUpdate a bit redundant, but it makes textInput more useful by
making it consistently happen before the DOM is ever modified from a
user-initiated text input.

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
>>
>>
>