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

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

From: Daniel Danilatos <daniel@danilatos.com>
Date: Tue, 25 Aug 2009 17:58:25 +1000
Message-ID: <b2cb92d0908250058r10516139vf5057874d177e900@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: www-dom@w3.org, Hironori Bono <hbono@chromium.org>, Masayuki Nakano <mnakano@mozilla-japan.org>
Thanks Doug,

I'm swamped this week, I'll try to get back onto this next week.


On Thu, Aug 20, 2009 at 7:23 PM, Doug Schepers<schepers@w3.org> 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?
> 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 sense.
> 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.
> [1]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-CompositionEvents-Interfaces
> [2]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-DeadKeys
> [3]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-IME
> [4]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset-handwriting
> [5] http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0143.html
> Regards-
> -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 Tuesday, 25 August 2009 07:59:06 UTC

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