Re: Proposal to ammend the composition event spec.

Here's how I understand the changes needed:
1. compositionstart must fire before the DOM is modified due to a
composition in addition to the current text that "This event is dispatched
immediately before a text composition system is launched."
2. compositionend must fire after all DOM modifications due to a composition
are completed in addition to the current text that "This event is dispatched
immediately after the text composition system is completed"
3. textInput should be fired before compositionend and before the last DOM
mutation confirming the composition. In other words, swap items 3 and 4 in
the second list at
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-composition-event-orderand
change is so that the compositionend event has no default action.

Ojan

On Wed, Jul 28, 2010 at 11:33 AM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Folks-
>
> Just so we're clear, can you please summarize the changes you'd like to the
> spec on this issue, and the rationales for each change?  I'm completely open
> to changing the spec, but I am a little fuzzy on what specific changes are
> needed.
>
> Many thanks-
> -Doug
>
> Daniel Danilatos wrote (on 6/30/10 6:44 AM):
>
>  So it seems we're all happy with this. Doug, any chance of it finding
>> its way into the spec? We really would like to fix the outstanding
>> issues in Webkit.
>>
>> Dan
>>
>> On Thu, Jun 17, 2010 at 11:47 AM, Ojan Vafai<ojan@chromium.org>  wrote:
>>
>>>  I didn't mean to derail the original proposal. As best I can tell,
>>> everyone
>>>  who has voiced an opinion agrees that compositionstart/compositionend
>>> should
>>>  bound all IME related DOM modifications and that textInput should fire
>>>  before the compositionEnd event.
>>>  Whether it also fires before compositionStart is totally orthogonal. We
>>>  should try to address that after we've come to a conclusion on the other
>>>  thread about extending textInput to other input modes.
>>>  Ojan
>>>  On Wed, Jun 16, 2010 at 6:08 PM, James Su<suzhe@google.com>  wrote:
>>>
>>>>
>>>>  To prevent all text input, I think the preferred way is to just cancel
>>>>  keydown event. In this case we don't need to care about textInput and
>>>>  composition events at all. It's also compatible with non-IME input
>>>> mode. So
>>>>  I think textInput and composition events should not be fired at all if
>>>>  keydown is cancelled.
>>>>  Regards
>>>>  James Su
>>>>
>>>>  2010/6/16 Ojan Vafai<ojan@chromium.org>
>>>>
>>>>>
>>>>>  On Wed, Jun 16, 2010 at 2:38 PM, Ojan Vafai<ojan@chromium.org>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>>  to type "wo" ->  我
>>>>>>  user "w"<-- Canceling keydown should prevent the composition from
>>>>>>  starting and the DOM should not be modified.
>>>>>>
>>>>>
>>>>>  Upon further thought, I think we should also fire a textInput event
>>>>> here
>>>>>  (not sure if it should fire before or after compositionstart). "data"
>>>>> can
>>>>>  just be the empty string. It should be possible to only listen to
>>>>> textInput
>>>>>  and preventDefault to prevent all text insertion. You shouldn't need
>>>>> to
>>>>>  listen to both textInput and keydown/compositionstart.
>>>>>
>>>>>
>>>>>>  event compositionstart
>>>>>>  ("w")
>>>>>>
>>>>>>  user "o"<-- Not related to textInput since this keydown doesn't
>>>>>>  generate a textInput event. One cross-platform solution would be to
>>>>>> cancel
>>>>>>  the composition.
>>>>>>  ("wo")
>>>>>>
>>>>>>  user<space>    <-- Same as above.
>>>>>>  ("我")
>>>>>>
>>>>>>  user<space>  (to commit the composition)<-- Should cancel the
>>>>>> textInput
>>>>>>  and thus cancel the composition.
>>>>>>  ("")
>>>>>>  event textInput (cancelable)
>>>>>>  ("我")
>>>>>>  event compositionend
>>>>>>  -Ojan
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>