- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 May 2013 22:05:44 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 --- Comment #3 from Travis Leithead [MSFT] <travil@microsoft.com> --- Event target: is there any scenario where the developer wants to listen to candidatewindowshow of all the input boxes on the same page and run them through the same event handler? Our thinking is no, because the developer wants to position the suggestion list of a specific input box relative to that input box and its candidate window. The event handler would be different for each input box that needs this, and not all of the input boxes will need this. Not sending the event to input boxes that don’t have input method context and avoiding the event bubbling could save performance here. Synchronous: this has to be synchronous to avoid overlapping of IME and any other UI provided by the web app. Overlapping for an undetermined short time and then separating them is not a polished user experience. Actual usage: yes the suggestion UI could change with to keep consistent with the width of the IME candidate window, although a better design is that the IME candidate window maintains a fixed width that is the same as the input box, left aligns to the input box and docks below it. This is what we expect from specifying ime-align:after. Clarification: for mobile platforms where the IME UI is part of the keyboard, yes this event could be ignored and not be fired. It’s still useful for developers to get compositionText to assist dynamic search suggestions, but as the occlusion issue is not there, it’s unnecessary to tell developers where inside the keyboard is the IME. Maybe isCandidateWindowVisible() could return false, as technically it’s not a window, it’s part of the keyboard and developers shouldn’t worry about its existence. They could use hasComposition() and compositionstart event to find out that IME composition is going on. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 28 May 2013 22:05:49 UTC