Re: Proposal to ammend the composition event spec.

Ojan pretty much said what I was thinking. Just a few additional comments.

On Tue, May 18, 2010 at 9:51 AM, Ojan Vafai <ojan@chromium.org> wrote:
> On Tue, May 18, 2010 at 9:11 AM, Doug Schepers <schepers@w3.org> wrote:
>>
>> In my opinion, the spec should be changed to match the implementation
>> experience, and I expect that others will agree.  The DOM3 Events spec is
>> not (quite) in Last Call yet, so it's not a question of maintaining
>> compatibility with the spec, but rather in doing what works best for
>> implementations and authors.
>
> I agree.
>
>>
>> I'm not opposed to option 3, but it doesn't seem to take into account the
>> fact that some IMEs swallow all key events, so the result of the composition
>> isn't available until the end.  Or maybe I'm misunderstanding it?
>
> Option 3 seems best to me. The UA always knows before it modifies the DOM,
> so it can ensure that textInput fires before the DOM is modified. It might
> be that the result of the full composition isn't available until the end,
> but the UA certainly knows about any state changes to the DOM before they
> happen. Stated differently, textInput does not need to fire due to internal
> state changes in the IME, but should fire due to changes to the DOM.
> However, it may be that canceling a textInput event during a composition
> will do strange things. I think that's fine. In the worst case, we can say
> either of the following:
>
> textInput events during IME composition cannot be canceled
> textInput events during IME composition can be cancelled, but may leave the
> composition in an indeterminate state

I prefer the second option here, because I can't think of any
potential intermediate-state-related problems.

For example, say textInput is cancelled at some point in the middle of
composition. Ideally, the UA should convey this information to the IME
and bring the IME's state in line with the DOM. However, if that is
not possible, then the UA can just ignore the fact, until the user
types another key (or does something to change the IME state). Then
the UA could adjust the composed text to once more match the IME
state, unless of course the corresponding textInput is again
cancelled.

At worst, (though I can't think of an example where this would be
necessary), the issue could be resolved in a similar way to how we
might handle Reconversion as proposed in
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0143.html

>
> It's not ideal, but at least it keeps textInput consistent by making it
> always fire before any text is input, which is more important.

I think it's also worth noting that if we use textInput for every
single change, the compositionUpdate event becomes redundant (unless
we specify it to fire synchronously *after* each composition change,
which would be a useful thing to have).

> Ojan

Received on Tuesday, 18 May 2010 19:28:54 UTC