This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, InputEvent.isComposing is defined as: "true if the input event occurs as part of a composition session, i.e., after a compositionstart event and before the corresponding compositionend event." However, this behavior isn't useful at committing composition. E.g., keydown: key="a", isComposing=false compositionstart: data=something compositionupdate: data="あ" beforeinput: data="あ", isComposing=true // DOM change input: data="あ", isComposing=true keyup: key="a", isComposing=true keydown: key="Enter", isComposing=true beforeinput: data="あ", isComposing=true // DOM change input: data="あ", isComposing=true compositionend: data="あ" keyup: key="Enter", isComposing=false Web apps must want to handle the last "input" event is as not a part of composition because the composition string is committed. So, I think that InputEvent.isComposing should be defined as: "true if the input event occurs as part of a composition session, i.e., after a compositionstart event and before the corresponding compositionend event. Additionally, there is uncommitted composition string." I think that this definition isn't useful for KeyboardEvent.isComposing because some Chinese IMEs don't expose composition string to applications until it's committed. So, KeyboardEvent.isComposing should just refer compositionstart and compositionend.
Although, I'm not sure if web apps expect what value to isComposing of the last beforeinput event.
I don't see what is gained by adding something like "Additionally, there is uncommitted composition string." to the end of the InputEvent definition. isComposing is true for all events between compositionstart and compositionend. It is false in all other cases. This is a simple and clear definition. If isComposing needs a more complex definition, then we should probably punt it into UIEvents so we have time to discuss it properly.
(In reply to Gary Kacmarcik from comment #2) > I don't see what is gained by adding something like "Additionally, there is > uncommitted composition string." to the end of the InputEvent definition. Web apps can ignore all input events caused by updating composing string. In other words, web apps can handle input events only when the editor modified by "fixed" string. > isComposing is true for all events between compositionstart and > compositionend. It is false in all other cases. This is a simple and clear > definition. Sure, but I think that it's not useful for web apps due to this issue. > If isComposing needs a more complex definition, then we should probably punt > it into UIEvents so we have time to discuss it properly. If you think so, I think that there are some options: 1. Keep isComposing with current definition. And then, add InputEvent.isFixed or something in UIEvents. (Mark as WONTFIX) 2. Keep isComposing with current definition. And then, overwrite the behavior of InputEvent.isComposing in UIEvents (Change the Component to UIEvents) 2. Put off the InputEvent.isComposing to UIEvents. (Change the Component to UIEvents) 3. Just add the summary with what I suggested in comment 0. (Mark as FIXED) Either is okay to me. Could you set the status again with new decision?
Ah, another possible solution is, define the event order at compositionend. If input event should be fired after compositionend (Firefox behaves so), the definition of InputEvent.isComposing can stay as current.
I tested with Firefox, Chrome and IE on Windows, with Firefox, Chrome and Safari on Mac. Then, all of them fire input event after "compositionend" event. So, this can be marked as INVALID. However, I think that D3E should define that input event should be fired compositionend event.