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

Composition Events in DOM3 Events (was: Fwd: A super rough draft for composition events)

From: Doug Schepers <schepers@w3.org>
Date: Thu, 20 Aug 2009 05:23:49 -0400
Message-ID: <4A8D1625.3010700@w3.org>
To: Daniel Danilatos <daniel@danilatos.com>, www-dom@w3.org, Hironori Bono <hbono@chromium.org>
CC: Masayuki Nakano <mnakano@mozilla-japan.org>
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?

2) relationship of 'compositionEnd' to 'textInput':
You wrote in your proposal for 'compositionend':

This event type is almost the same as a TextInput event but this event 
type is also sent when an input method cancels composing a text.

It struck me that a better way to model that is for 'textInput' to be 
fired whenever 'compositionend' results in a string, and is not 
canceled, and when its data attribute is not null or does not contain 
the empty string.  Another way of saying this is that a 'compositionend' 
may or may not be followed by a 'textInput'.  Is this a reasonable 
approach, or does it violate implementations in some way?

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?

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? Note that this 
would be different than the event being 'cancelable' in the event-flow 

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?

6) canceled Composition Events and 'compositionupdate':
You raise the question of whether there should be a 'compositionupdate' 
event which clears @data just prior to the 'compositionend', when an 
Composition Event is canceled by the user.  Have you got any more 
thoughts on this?  Is there implementation experience we should fall 
back on (MacOS does seem to do this), or is it inconsistent?

7) handwriting recognition ambiguity:
I know this section was only sketched out, but what were you trying to 
convey by having 2 'compositionupdate' events, one with the word "test" 
and one with the word "text"?  Is that similar to the "Accept" process 
in the Kanji IME example?

8) next steps:
Assuming we resolve these issues, what other considerations should we 
make in order to consider this feature done and usable?  Dan has put 
together some other considerations [5]... which of these are the highest 
priority (keeping in mind feature creep)?

Thanks so much for your consideration of these issues.

[5] http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0143.html

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Daniel Danilatos wrote (on 7/14/09 11:52 PM):
> Hi guys,
> Here is the draft proposal for composition events from Bono san. They
> are very similar to firefox's implementation, I believe.
> Dan
> ------------
> This is the super-draft that proposes IME events. This draft is just
> copied texts from the DOM event spec (*1), (*2) and added IME events.
> So, it is better to read them as well as this document.
> (*1) <http://www.w3.org/TR/DOM-Level-3-Events/events.html>
> (*2) <http://www.w3.org/TR/DOM-Level-3-Events/keyset.html>
> Please feel free to give me your comments.
> Regards,
> Hironori Bono
Received on Thursday, 20 August 2009 09:24:00 UTC

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