22194 2013-05-29 06:47:43 +0000 Clarificaiton of 'enabled' property behavior 2013-07-04 07:42:29 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - IME API unspecified All All RESOLVED FIXED P2 normal --- 1 kochi kochi adrianba mike public-webapps travil yoichio public-webapps-bugzilla oldest_to_newest 88365 0 kochi 2013-05-29 06:47:43 +0000 Even though the spec assumes that the 'enabled' property associated with the context can be used to detect whether the IME is turned on or not, but for some cases it may not work as intended. On Chromium (and possibly other browsers) a real IME context is shared in a browser, and the state of the IME may change on focus change. To illustrate this, if a page has one input field which has focus and IME is turned on, context.enabled is expected to return true. But once outside of the input field is clicked, the browser turns off IME. A naive implementation of .enabled property will return false in that case, but the state of IME will be restored when the input field gets focus again, and .enabled returns true. Webapps developers may assume that the state won't change on focus change. Possible solutions: 1. Do not change the spec. Users of the API will accept the behavior as is and let the behavior implementation dependent. 2. Hold the .enabled state within context and restore when it gets focus Retain the state and change the state only when the field has focus, and once it loses focus and gets focus again, then restore the state. This may be an expected behavior of most developers. 3. Remove .enabled from the spec As .enabled may not be implemented on Mac/Android, it may be a good idea to abandon .enabled and focus on having 'inputmode' attribute. Microsoft's proposal also dropped .enabled (for the reason that it won't support the case for non-editable element, though). 4. none of the above Any other ideas? 90341 1 kochi 2013-07-04 07:42:29 +0000 I'll choose 3, abondoning .enable property. Something like input type= or inputmode should be used instead to give hint to user agent.