Re: Feedback about W3C Input Method Editor API draft

Hi James,

Thanks for the comments!
My replies inlined.


On Tue, Apr 23, 2013 at 5:35 PM, James Su <suzhe@google.com> wrote:

> Hi all,
>   Please see below my initial feedback about *
> http://www.w3.org/TR/2013/WD-ime-api-20130404/.*
>
> * 5. The getInputContext() method
>
> partial interface HTMLElement {
>    InputMethodContext<http://www.w3.org/TR/ime-api/#idl-def-InputMethodContext>
> getInputContext<http://www.w3.org/TR/ime-api/#widl-HTMLElement-getInputContext-InputMethodContext>();
> };
>
> Feedback:
>
> 1. The name of the method and its return value type doesnt match. Suggest
> to rename the method to getInputMethodContext().
>
> *
>

Certainly.  I'll change the spec.


> * 6. The Composition Dictionary
>
> dictionary Composition {
>    readonly attribute Node  text<http://www.w3.org/TR/2013/WD-ime-api-20130404/#widl-Composition-text>
> ;
>    readonly attribute Range caret<http://www.w3.org/TR/2013/WD-ime-api-20130404/#widl-Composition-caret>
> ;
> };
>
> Question: Im wondering how should a web app render the styled text on a
> canvas? Can you provide an example code?
>
> Feedback: how about rename caret to selectedRange?
> *
>

As I wrote in
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0042.html
I agree with you that "Node text" is questionable and am wondering whether
it is
really useful for web developers who want to draw the composition by
themselves.

I also agree that caret can be renamed to selectedRange.  i.e. it is a
zero-width
position when user is composing and it can have width while user is
converting the composition.

I believe we would need sequence<Range> segments so apps can render
the segmented composition during conversion properly.  What do you think?


> * 7. The InputMethodContext Interface
>
> interface InputMethodContext {
>    readonly    attribute Composition<http://www.w3.org/TR/ime-api/#idl-def-Composition>
> composition<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-composition>
> ;
>                attribute boolean     enabled<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-enabled>
> ;
>    readonly    attribute DOMString   locale<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-locale>
> ;
>    void    confirmComposition<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-confirmComposition-void>();
>    void    setCaretRectangle<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-setCaretRectangle-void-Node-anchor-long-x-long-y-long-w-long-h>(
> Node anchor, long x, long y, long w, long h);
>    void    setExclusionRectangle<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-setExclusionRectangle-void-Node-anchor-long-x-long-y-long-w-long-h>(
> Node anchor, long x, long y, long w, long h);
>    boolean open<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-open-boolean>();
> };
>
> Feedback:
>
> 1. attribute boolean     enabled<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-enabled>
> ;
>
> Instead of using a boolean value to tell the system whether or not the IME
> should be enabled, I suggest to add a mechanism to tell the IME the
> supported input type of the current focused node, it may either be a
> DOMString attribute or a method like setInputType(DOMString type).
>
> The acceptable values of the input type can be a subset of the types
> defined for HTML Input element<http://www.w3.org/TR/html-markup/input.html#input>.
> So that the browser can enable/disable the IME or maybe switch to a
> specific IME according to the input type. For example, if the web app wants
> to implement a password input box by itself, it can specify the input type
> to password, then the browser will switch the current IME to a special
> one suitable for inputting password. Setting the input type to none or an
> empty value to disable the input method.
>
> *
>

The input types for input element is useful to determine whether to *turn
off* IME, but which one do you think
appropriate to turn on IME?  E.g. I think 'type=text' is neutral and the
user agent cannot guess the appropriate state.

So I think we still need an explicit way to turn on IME.

Also see comment for 4.open below.



> *
>
> 2. readonly    attribute DOMString   locale<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-locale>
> ;
>
> Having this attribute is good, but may not enough. We probably need a
> mechanism to notify the web app whenever the IMEs locale gets changed. For
> example, when the locale is changed from a LTR to a RTL one, the web app
> may want to adjust its text alignment and cursor position automatically.
>
> *
>

This is true, and I agree that the current locale information may be
insufficient for e.g. changing the
cursorposition upon changing input locale.  Probably another DOM event
should be added outside of
this spec's scope.

Fortunately or unfortunately, we already have the same locale in key, input
and composition events
so this spec also follows it.



> *
>
> 3. void    confirmComposition<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-confirmComposition-void>();
>
> I suggest to change this method to cancelComposition(), which asks the IME
> to cancel the current composition session by resetting its internal state
> without committing anything. The web app is responsible for converting the
> latest composition text into the final text. The reason is that,
> confirmComposition() may require a round-trip call between IME and the web
> app, which may be an asynchronous call. So if the IME wants to commit
> anything when this method gets called, the result may be sent to the web
> app asynchronously any time after calling confirmComposition() method. This
> will cause unexpected behavior if the web app wants to manipulate the text
> content immediately after calling confirmComposition().
>
> For example: assuming the current composition text is Hello world|, and
> the caret is at the end. If the web app decides to finish the composition
> and move the caret when the user clicks the composition text or any other
> place, the web app needs to call confirmComposition() method to ask the IME
> to finish the current composition session, but as the result may be sent
> back asynchronously after confirmComposition() method returns, the result
> may be inserted into a wrong place if the web app moves the caret
> immediately after calling confirmComposition().
>
>
> 4. boolean open<http://www.w3.org/TR/ime-api/#widl-InputMethodContext-open-boolean>();
> This method may not be necessary, as the User Agent should take care of
> opening/closing the IME according to the current input type when necessary.
>
> *
>

Okay, then how about having getInputType() and setInputType() method (or
inputType attribute)
instead of enabled and open()?   For non-input element,
setInputType('text') will turn on delivering
all input related events to the element while setInputType('none') will
disable any text input even
on an <input type=text> field (equivalent to 'disabled' attribute?).

*
> *
>
> --
>
> James Su |  Software Engineer | suzhe@google.com |  +8610 62504149
>

-- 
Takayoshi Kochi

Received on Tuesday, 23 April 2013 10:28:14 UTC