Re: Proposal: Input Method Editor API

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, 8 October 2010 08:57:56 UTC