- From: <bugzilla@jessica.w3.org>
- Date: Tue, 08 Apr 2014 06:46:28 +0000
- To: www-dom@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25288 Masayuki Nakano <masayuki@d-toybox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #3 from Masayuki Nakano <masayuki@d-toybox.com> --- (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? -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 8 April 2014 06:46:29 UTC