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: m...@w3.org
Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@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 on the CC list for the bug.
