[Bug 22059] New: Composition dictionary should be changed

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

            Bug ID: 22059
           Summary: Composition dictionary should be changed
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IME API
          Assignee: mike@w3.org
          Reporter: kochi@google.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

As the spec dropped Javascript IME spec, Composition dictionary
doesn't have to be a separate dictionary but can be a part of
InputMethodContext.

In 20130404 WD:
dictionary Composition {
    readonly attribute Node  text;
    readonly attribute Range caret;
};

In Microsoft's proposal
https://dvcs.w3.org/hg/ime-api/raw-file/default/proposals/IMEProposal.html


interface InputMethodContext : EventTarget {
    ...
    readonly    attribute DOMString     compositionText;
    readonly    attribute unsigned long compositionStartOffset;
    readonly    attribute unsigned long compositionEndOffset;
    ....
};

The rationale for this is "
For composition dictionary in current proposal, we can see exposing IME clauses
as child nodes of text node, and making them real DOM nodes with styles being
useful for a JS-based IME as the IME needs to tell the web application how to
render the composition, but if JS IME is not a goal, is there any other
scenarios that will benefit from this? If not, how about a simple design that
expose the text being composed as DOMString?

For caret range, if it’s for enabling JS-based IME, then exposing the caret
ranges of IME clauses is helpful, but if it’s not for JS IME, is there any
other usage? We understand that web applications want to know about the whole
string of the tentative composition, but we are not sure in which case they
want to know how the whole tentative composition string is divided into several
parts. Another issue is that the range type only tells the start and end
offsets of the composition from its immediate parent. Web application usually
wants to know the offset from the beginning of the text field so that it could
combine the composition alternate with the text before it to create a full text
string. But the beginning of the text field can be up in the parent tree if
it’s a contentEditable element and requires JavaScript code to trace up in the
parent tree to get the right offset.

So instead of a dictionary type for composition, we suggest compositionText,
compositionStartOffset and compositionEndOffset as a simpler design. Please let
us know if you have scenarios that need to be the other way."

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

Received on Thursday, 16 May 2013 09:42:59 UTC