[whatwg] Proposal: Input Method Editor API
Hironori Bono (坊野 博典)
hbono at google.com
Mon Jan 10 21:47:52 PST 2011
Thank you for sending your use cases and feedbacks.
On Sun, Jan 9, 2011 at 10:57 AM, Ryosuke Niwa <ryosuke.niwa at gmail.com> wrote:
> 2011/1/8 Ian Hickson <ian at hixie.ch>
>> I understand that it might be helpful for pages to contribute data to
>> IMEs, e.g. so that an IME doing text prediction can offer predictions
>> based on words the site knows the user might type (e.g. names from the
>> user's contacts list on the site). However, what's the use case for the
>> page writing its own IME from scratch?
> Off the top of my head,
> Users may not have sufficient privileges to install an IME - If I'm going to an internet cafe in the U.S., I wouldn't expect computers to have East Asian IMEs installed. Web page that requires Chinese, Japanese, Korean, etc... can provide suitable IMEs so that users can use it.
> Not all IMEs are free - web page could provide an IME when the client doesn't have one
> Some IMEs are better than others - web page supposedly can provide a better IME.
Even though my use case are almost the same, I think of another use
case: writing an IME used for automated compliance tests.
Unfortunately, it is not so easy to test this IME API on a platform
that does not have IMEs installed. (Neither is it easy to test
composition events I have added to the "DOM 3 Event" specification.) I
would like to provide a reference IME written with this API so
developers can implement this API on such platforms.
Nevertheless, in my honest opinion, we can implement IMEs without new
API proposed by my document except some edge cases, such as rendering
styled text (used by IME text) in a <textarea> element. In fact, many
such as virtual keyboard APIs of Google,
So, I'm happy to remove APIs for IME developers from this proposal
because I do not have any intention of adding burdens onto browser
E-mail: hbono at google.com
More information about the whatwg