Re: [ime-api] Composition dictionary should be changed [Bug 22059] (#4)

Comment #2 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059#c2> @travisleithead 

 Travis Leithead [MSFT] 2013-08-20 14:21:57 EDT

(In reply to comment #1)
> As suggested by James Su, I'd like to incorporate composition dictionary
> within InputMethodContext.
> 
> It would look like:
> interface InputMethodContext {
>     ...
>     readonly    attribute DOMString   text;

The interface is labelled "InputMethodContext" and so "text" is a little ambiguous in my opinion. I liked "compositionText" better, but I could be OK with this.


>     readonly    attribute long        selectionStart;
>     readonly    attribute long        selectionEnd;

Selection & composition are two completely different underlying concepts that shouldn’t be combined. I think calling these "selection.." is confusing with normal text selection. The currently selected text will already be available via the input and textarea's selection properties--no need to duplicate the functionality. Offset (in the MS proposal) makes it clear that it’s character positions and not DOM nodes. These offset character positions mark the actual "active" composition range (which may be different from what is currently selected). Maybe for brevity: "startOffset"/ "endOffset"? or "textContentStart"/"textContentEnd"?


>     readonly    attribute Uint32Array segments;

OK. This is not relevant to all IMEs though. I suppose we could implement this for other IMEs by always returning only 1 segment.


> where selectionStart/End means identical to that for <input>/<textarea>,
> and added segments information for dividing the text into clauses.

No need for the redundancy. What we found is that we actually needed the "active" composition offsets, not the selected text which varies depending on the state of the IME. See above.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ime-api/issues/4#issuecomment-147405821