Re: Composition Events in DOM3 Events

Hi all,

Lots of great updates since I last read the spec. Here's some comments
on the composition events (inline below).

--Jacob

> 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?

Some consistency in the case of event types throughout the spec would
be nice. Briefly looking at it, textInput and the DOM________ events
are the only ones in camelCase. It makes sense that events with
corresponding HTML attributes have all lowercase names (goes nicely
with their "on_____" attribute names).

It'd be nice if all events had the same case convention. But that
might not be possible for back-compat and existing implementation
reasons.

If we make it compositionStart, compositionUpdate, and compositionEnd,
doesn't that make all the DOM-only events (ie, no corresponding HTML
attribute) in camelCase? That's at least some consistency. Just a
thought.

> 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?

I agree. It seems that textInput makes sense to be the default action
of the compositionend (when the composition is not canceled and the
data is not null/empty). So it should fire after 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?

It makes most sense to me for textInput to be the result of a
compositionEnd event, especially if canceling a compositionend
prevents the textInput from occurring.

> 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.

I would think you'd just fire compositionend with the data empty/null.
It could be canceled either by user interaction with the IME or by
preventDefault().

> 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 or be cancelable.


> 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)?

Can someone provide a clarification on how these composition events
occur when the user reactivates a previously created composition (see
"reconversion" in Dan's notes [1])? Any chance of including the
selection as a text range ([2]) instead of just a string (might be
helpful in a reconversion case)?


--Jacob
(used to be t-jacobr@microsoft.com)

[1] http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0143.html
[2] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html

Received on Saturday, 29 August 2009 16:50:30 UTC