[Bug 22194] New: Clarificaiton of 'enabled' property behavior

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22194

            Bug ID: 22194
           Summary: Clarificaiton of 'enabled' property behavior
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IME API
          Assignee: kochi@google.com
          Reporter: kochi@google.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 29 May 2013 06:47:44 UTC