Re: Proposal: Input Method Editor API

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.

Received on Thursday, 7 October 2010 05:19:58 UTC