W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Composition Events in DOM3 Events

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 26 Aug 2009 23:30:01 +0300
Message-ID: <4A959B49.7020708@helsinki.fi>
To: Doug Schepers <schepers@w3.org>
CC: Daniel Danilatos <daniel@danilatos.com>, www-dom@w3.org, Hironori Bono <hbono@chromium.org>, Masayuki Nakano <mnakano@mozilla-japan.org>
On 8/20/09 12:23 PM, Doug Schepers wrote:
> Hi, Bono-san-
> Thanks for your excellent write-up. I've now integrated Composition
> Events into the DOM3 Events spec. The relevant parts of the spec that
> were changed are ready for review [1][2][3][4], but are not yet complete.
> I made some modifications and came up with a few questions while editing
> the material, which I hope you, Dan, or someone else might enlighten me on:
> 1) spelling of events:
> In different places, you use all lowercase, or camelCase for
> compositionStart/compositionstart, compositionUpdate/compositionupdate,
> and compositionEnd/compositionend. The camelCase is more consistent with
> 'textInput', but more unwieldy to type and unlike other event types like
> 'mousedown', 'keyup', etc. Which should it be? Will this affect existing
> implementations?

Gecko has compositionstart/compositionend

> 3) order of events:
> In your proposal, the examples showed 'compositionEnd' events following
> 'textInput' events. It seemed to me that the order should be reversed...
> that the end of the composition mode (after the IME dialog closes, etc.)
> would "trigger" the 'textInput' event. This is how I represented it in
> DOM3 Events. Does this violate existing implementations? Is there some
> rationale I'm missing to have the order as you proposed?

textInput should be after compositionend.

> 4) canceling a composition:
> In your examples, you include an example of an IME operation being
> canceled. Should we add a 'compositionCancel' event, or a
> 'cancelCompositionEvent' method to account for this?
Or is it just enough if compositionend.data is null (in which case 
textInput doesn't fire).

> 5) event flow:
> Since Composition Events are, in some sense, happening outside the
> normal document (in that the UA or OS provides the composition context,
> how should these operate in the event flow? Should these events bubble
> or be cancelable?
I see no reason why they shouldn't bubble.
But cancelable... what would it mean for them to be cancelable?
Maybe cancelling compositionend should prevent textInput to fire.
Cancelling compositionstart could prevent IME input? (Have to check if 
that is easily implementable in common OSes)

Received on Wednesday, 26 August 2009 20:30:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC