W3C home > Mailing lists > Public > www-international@w3.org > October to December 2010

Re: Proposal: Input Method Editor API

From: 坊野 博典 <hbono@google.com>
Date: Fri, 15 Oct 2010 15:28:30 +0900
Message-ID: <AANLkTinoSA=Gr3PWFokQvh_Ti4_7YPn0VjNkPZMOYgBS@mail.gmail.com>
To: www-international@w3.org
Cc: Masayuki Nakano <masayuki@d-toybox.com>
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.
>>
>
Received on Friday, 15 October 2010 06:29:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 October 2010 06:29:04 GMT