AFBarstow
commented
9 years ago Comment #1 from https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059 @TakayoshiKochi
Takayoshi Kochi 2013-07-04 03:35:40 EDT
As suggested by James Su, I'd like to incorporate composition dictionary within InputMethodContext.
It would look like: interface InputMethodContext { ... readonly attribute DOMString text; readonly attribute long selectionStart; readonly attribute long selectionEnd; readonly attribute Uint32Array segments; .... }
where selectionStart/End means identical to that for /
This Issue is a copy of comment zero of W3C Bugzilla . Additional comments for this issue contain other comments for the original Bugzilla bug.
= Comment 0: Takayoshi Kochi 2013-05-16 05:42:53 EDT
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."