Re: Proposal to ammend the composition event spec.

Hi, Daniel-

Thanks for the concrete feedback, that's very helpful.

In my opinion, the spec should be changed to match the implementation 
experience, and I expect that others will agree.  The DOM3 Events spec 
is not (quite) in Last Call yet, so it's not a question of maintaining 
compatibility with the spec, but rather in doing what works best for 
implementations and authors.

I'm not opposed to option 3, but it doesn't seem to take into account 
the fact that some IMEs swallow all key events, so the result of the 
composition isn't available until the end.  Or maybe I'm 
misunderstanding it?

We'll talk about this at the next telcon.  Any more information you can 
provide will be most appreciated.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Daniel Danilatos wrote (on 5/18/10 10:49 AM):
> 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
>
>

Received on Tuesday, 18 May 2010 16:11:08 UTC