Re: [whatwg] Proposal: Input Method Editor API

Just post my feedback here. They are just my humble opinion that may not be
reasonable or correct.

Regards
James Su


0. Name of the API I suggest not to use term “Input Method Editor”, which is
a Windows specific term. We can just call it “Input Method API”, or maybe
“Text Input Controller API”.

1. interface Composition a) Better to use selection range instead of caret
position. Actually, the CompositionCaret interface already represents a
selection range.

b) Typo: CompositionAttribute should be CompositionClause

c) text in CompositionClause is not necessary, as we already have text in
Composition.

d) Each CompositionClause object should represent a range in the text, so
having an end or length attribute would be necessary. But because there
should no gap between two clauses, An length would be enough for each
clause, so a clause always starts from the end position of the previous
clause.

e) selected attribute of CompositionClause may not be necessary if we have
selection range in Composition.

f) Better to add an attribute to indicate the status of a CompositionClause,
such as “input”, “converted”, etc.

g) Better NOT to support text and background color in CompostionClause. The
Web App should be responsible for choosing proper colors according to the
clause status.

So a better Composition definition might look like:

interface Composition {
  readonly attribute DOMString text;
  readonly attribute CompositionSelection selection;
  readonly attribute CompositionClauseList clauses;
};

interface CompositionSelection {
  readonly attribute int location;
  readonly attribute int length;
};

interface CompositionClause {
  readonly attribute int length;
  readonly attribute DOMString type;
};

2. interface InputMethodContext a) I’m not sure if the source attribute is
useful for Web Apps.

b) boolean setEnable(in boolean enable);

You proposal says:
The setEnable() method

Controls the state of the IME associated with this context. The enable
parameter
represents whether a user agent activates this IME when the given node gains
the input focus. When this value is true, a user agent activates an IME when
this node gains the input focus and sends composition events to the given
nodeeven though the node is not an editable one, such as a <canvas> element..
This function returns true when the user agent successfully activates (or
deactivates) the IME. Otherwise it returns false.

IMO, it’s inappropriate to activate/deactivate user’s input method from a
web app, which would be very intrusive to the user. Instead, I’d prefer to
have an attribute indicating the type of input content supported by the
node, just like HTML5 input tag’s type attribute. We may also have an
attribute to give a hint about the desired input language of this node. So
that the UA can decide an appropriate behavior when the node gets input
focus.

c) hasComposition()
It may not be necessary, as the web app can determine it by checking the
value of composition attribute.

d) setComposition() and confirmComposition() methods
First, it’s not clear that how these two methods interactive with
composition{start|update|end} and textInput DOM events, and how it affects
the content of the DOM node (it could be any node, not just canvas).

According to HTML DOM Event
Specification<http://www.w3.org/TR/DOM-Level-3-Events/#trusted-events>,
events which are generated by the user agent, either as a result of user
interaction, or as a direct result of changes to the DOM, are trusted
events, all other events are untrusted events. And the most important thing
is: Most untrusted events should not trigger default
actions<http://www.w3.org/TR/DOM-Level-3-Events/#glossary-default-action>,
with the exception of
click<http://www.w3.org/TR/DOM-Level-3-Events/#event-type-click>or
DOMActivate<http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMActivate>events.

So apparently these two methods would break this rule if they synthesize
those composition and text input related events and change the content of
the DOM node by triggering the events’ default actions.

Second, it’s not clear that how these two methods interactive with native
input methods. For example: what’s the expected behavior if the web app
calls setComposition() to change the composition text while the user is
composing something with a native input method? Would the native input
method accept the new composition text set by the web app or not?

3. interface InputMethodManager This interface may not be necessary as all
of its functionalities can be covered by the InputMethodContext interface.

4. Issues to be investigated a) We need to investigate if this proposal is
feasible for Pepper API
b) We need to investigate if this proposal can provide a better interaction
model between native and JavaScript input methods.
c) Security consideration. As this proposal tries to add API for Web App to
control the behavior of UA and native input method, we need to think about
the security problem carefully.
d) IMHO, adding extra interface and methods may not fit very well with
existing HTML DOM Event model. We probably need to investigate if it’s
feasible to support these features by extending existing DOM events or
adding some new events.

5. Conclusion This proposal still has many outstanding issues, IMHO, before
pushing it into standarization process, we may need more review feedback
from as many as Web app, UA and input method develoeprs as possible.


在 2010年11月9日 上午3:31，Hironori Bono (坊野 博典) <hbono@google.com>写道：

> Greetings,
>
> I'm Hironori Bono, a software engineer of Google. In the
> w3c-international ML, we have been discussing to write a proposal that
> adds an IME API to HTML5. This proposal is not only for web
> applications to control a system IME but also to write an IME in
> JavaScript. Even though this proposal is still an infant phase, I
> would like to post it to whatwg to hear comments from HTML experts.
> Would it be possible to read the following document and give me your
> comments?
>
>
> https://docs.google.com/fileview?id=0B8eVDHQ9_22-MzJhMTg2YmItNWU3NC00NzJmLThlMTAtYmU1ZTBlZWJhNzM0&hl=en&authkey=CLLHkFw
>
> Thank you for your interest in advance.
>
> Regards,
>
> Hironori Bono
> E-mail: hbono@google.com
>
> On Fri, Oct 15, 2010 at 3:28 PM, Hironori Bono (坊野 博典) <hbono@google.com>
> wrote:
> > Greetings,
> >
> > I have updated my proposal to add the InputMethodContext interface.
> > Also I have added a simple example of an IME that uses this API. It is
> > definitely helpful to give me your feedbacks to the updated one. (It
> > may be better to send this proposal also to whatwg?)
> >
> >
> https://docs.google.com/fileview?id=0B8eVDHQ9_22-Y2M2N2YwNzMtMTNmNS00OTc5LTg0OTUtNjdiNzE3OTdlNjFl&hl=en&authkey=CIPh1qEF
> >
> > Regards,
> >
> > Hironori Bono
> > E-mail: hbono@google.com
> >
> > On Fri, Oct 8, 2010 at 5:57 PM, Hironori Bono (坊野 博典) <hbono@google.com>
> wrote:
> >> Nakano-san,
> >>
> >> Thank you for your response.
> >> I will update the proposal to use the InputContext interface.
> >>
> >> Regards,
> >>
> >> Hironori Bono
> >> E-mail: hbono@google.com
> >>
> >> On Thu, Oct 7, 2010 at 8:52 PM, Masayuki Nakano <masayuki@d-toybox.com>
> wrote:
> >>> Of course, we can do it :-)
> >>>
> >>> On 2010/10/07 18:41, Hironori Bono (坊野 博典) wrote:
> >>>> Nakano-san,
> >>>>
> >>>> Thank you so much for your feedback.
> >>>> I have once thought a similar idea of adding an InputContext()
> >>>> function to an Element interface and retrieve the input context from
> >>>> an element as listed in the following snippet.
> >>>>
> >>>>   var element = document.getElementById('test');
> >>>>   var context = element.getInputContext(); // or
> >>>> element.getContext('input-method');
> >>>>   context.setComposition(composition);
> >>>>   context.confirmComposition();
> >>>>
> >>>> Nevertheless, I'm not sure we can implement such interface on all
> >>>> major user-agents. (I think we can implement this idea on WebKit.)
> >>>> Would it be possible to give me whether we can implement such
> >>>> InputContext interface on Firefox?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hironori Bono
> >>>> E-mail: hbono@google.com
> >>>>
> >>>> On Thu, Oct 7, 2010 at 2:19 PM, Masayuki Nakano<masayuki@d-toybox.com>
>  wrote:
> >>>>>
> >>>>> Sorry for the delay.
> >>>>>
> >>>>> The text-decoration-style property is updated in the latest working
> draft.
> >>>>>
> >>>>> The dot-dash and dot-dot-dash are dropped, they aren't also needed by
> IME composition rendering. So, you can drop these values from your proposal.
> >>>>>
> >>>>> I have some concern. On Win/Mac/Linux, if web browsers hoped, they
> could implement multiple IME context for every editors. So,
> InputMethodManager isn't useful on such browsers.
> >>>>>
> >>>>> So, I think that all editable elements should have
> "InputMethodContext" property and it should have composition, setEnable()
> and etc. Then, your proposal doesn't make any limitation of implementation
> of browsers.
> >>>>>
> >>>>>> void setEnable(in Node node, in boolean enable);
> >>>>>
> >>>>> The result should be boolean. On the current proposal, web developers
> cannot check whether it succeeded or not.
> >>>>>
> >>>>>> The setOpenState() method
> >>>>>> [NOTE:
> >>>>>> do we need to notice this event to JavaScript IMEs? If so, what is
> the best option?]
> >>>>>
> >>>>> Yes, I think so. I think that there should be an interface for
> Javascript IME. When it's registered to a context, web browser should
> disables native IME.
> >>>>>
> >>>>>> The hasComposition() method
> >>>>>> Returns true when the hosting user-agent is composing text. [NOTE:
> this function is
> >>>>>> just copied from the one of WebKit to hear opinions of developers of
> JavaScript-based
> >>>>>> IMEs.]
> >>>>>
> >>>>> I think that JS-IME developers doesn't need to know whether there is
> a native composition or not. When JS-IME is enabled, web browsers should
> kill native IME on the context.
> >>>>>
> >>>>>> The setComposition() method
> >>>>>> Updates the composition information of the hosting user-agent.
> >>>>>> When a JavaScript-based IME starts a composition, it MUST call this
> function with the
> >>>>>> appropriate composition information. When a JavaScript-based IME
> cancels an ongoing
> >>>>>> composition, it MUST call this function wiith a composition object
> whose text is empty.
> >>>>>> [NOTE: this function is just copied from the one of WebKit to hear
> opinions of developers
> >>>>>> of JavaScript-based IMEs.]
> >>>>>
> >>>>> So, I think that this is go away to another interface which is for
> JS-IME.
> >>>>>
> >>>>>> The confirmComposition() method
> >>>>>> Finishes the ongoing composition of the hosting user-agent. [NOTE:
> this function is
> >>>>>> just copied from the one of WebKit to hear opinions of developers of
> JavaScript-based
> >>>>>> IMEs.]
> >>>>>
> >>>>> When JS-IME is registered, this should be done automatically, I
> think. But for web developers, I think this method is needed.
> >>>>>
> >>>>> On 2010/09/27 12:46, Hironori Bono (坊野 博典) wrote:
> >>>>>>
> >>>>>> Greetings,
> >>>>>>
> >>>>>> Thank you so much for all of your feedbacks. I have published an
> >>>>>> updated proposal to the URL below:
> >>>>>>
> http://docs.google.com/fileview?id=0B8eVDHQ9_22-ZWJmNzE2YzYtNTYwNC00ZDM3LThkODgtZjc5ODI1Zjg4ZDhm&hl=en&authkey=CMPx4qQG
> >>>>>>
> >>>>>> This proposal does not only apply your comments (such as removing
> the
> >>>>>> Candidate interface), but also added some experimental functions
> that
> >>>>>> allows web-application developers to change the composition data
> owned
> >>>>>> by user agents, i.e. functions that help developers implement IMEs..
> >>>>>> (These functions are just copied from the IME functions of WebKit.
> >>>>>> Therefore, it is definitely helpful to give me your feedbacks.)
> >>>>>> Even though I thought I have applied all of your comments, I might
> >>>>>> forget applying some. Please feel free to shoot me if I forgot
> >>>>>> applying your comments.
> >>>>>>
> >>>>>> Thank you again for your interest in advance.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Hironori Bono
> >>>>>> E-mail: hbono@google.com
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Masayuki Nakano<masayuki@d-toybox.com>
> >>>>> Manager, Internationalization, Mozilla Japan.
> >>>
> >>>
> >>> --
> >>> Masayuki Nakano <masayuki@d-toybox.com>
> >>> Manager, Internationalization, Mozilla Japan.
> >>>
> >>
> >
>