Re: Proposal to ammend the composition event spec.

在 2010年5月28日 上午7:30，Ojan Vafai <ojan@chromium.org>写道：

> 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.
>
textInput event is defined as cancellable. Not sure if there is any real
world use-case.


>
> 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.
>
The text being composed and the confirmed text are different. I don't think
we should mix them. The effect of textInput event for a node is to append a
piece of text to existing content, while compositionUpdate is not. And
textInput is already in specification for quite a long time, it's not good
to change its behavior which may break backward compatibility.


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