- From: Daniel Danilatos <daniel@danilatos.com>
- Date: Tue, 25 Aug 2009 17:58:25 +1000
- 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. Regards Dan 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