Re: Feedback about W3C Input Method Editor API draft

Hi Takayoshi,
  Please see my comments inline.


2013/4/23 Takayoshi Kochi (河内 隆仁) <kochi@google.com>

> 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 doesn’t 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: I’m 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?
>
Agree. A sequence<Range> segments would be minimal requirement. And maybe
we should also consider to provide type information of each segment, i.e.
"converted", "convertible", "unconvertible", but it's optional.


>
>
>> * 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.
>
I think we need to consider two major scenarios here:
1. physical keyboard. In such case, the IME will be enabled automatically
by the User Agent when the current input type is one of a valid text input
types, i.e. 'text', 'password', 'number', 'email', 'url', 'search', 'tel'.
The IME will be disabled automatically for all other non-text input types.
But even the IME is enabled, it may not be activated, because its
activation is controlled by operating system. The user can
activate/deactivate the IME by using system hotkey or IME menu.

2. soft keyboard, e.g. on mobile devices. In such case, the User Agent may
have more complicated logic to determine whether the soft keyboard should
be shown or not. For example, in order to avoid unexpected UI flashing, the
User Agent may only want to show the soft keyboard when the user
touch/click the focused element again, and as soon as the soft keyboard is
shown, it won't be hidden until a non-text-input element is focused.

So I think for these two cases, the web app does not need to care about how
and when the IME/soft keyboard is shown or hidden.


>
> 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 IME’s 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.
>
Agree.


>
> 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?).
>

Maybe it's enough to have an inputType attribute? For an <input> element,
it can just be a reference to the element's type attribute, and has the
same restriction as the type attribute.


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