W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2010

Proposal to ammend the composition event spec.

From: Daniel Danilatos <daniel@danilatos.com>
Date: Tue, 18 May 2010 07:49:52 -0700
Message-ID: <AANLkTimmV3sPoZg3sIO6BO8v1Z-kkV_Ivu-0SNKE57oC@mail.gmail.com>
To: www-dom@w3.org
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 14:58:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT