- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: Tue, 16 Jun 2009 11:56:56 +0900
- To: Daniel Danilatos <daniel@danilatos.com>
- CC: Olli Pettay <Olli.Pettay@helsinki.fi>, Doug Schepers <schepers@w3.org>, www-dom@w3.org, hbono@chromium.org, mnakano@mozilla-japan.org
On 2009/06/15 13:52, Daniel Danilatos wrote: > IME API > > * Control the IME Candidate window (get/set position, ability to prevent > it from showing up at all, etc) Applications cannot control the candidate window position via TSF, probably. However, if browsers implement to render the candidate window themselves, we can. But gecko doesn't have such plan. Because most users don't happy. The candidate window should have native looks of the IME. And also we cannot control it on Cocoa, probably. Cocoa applications should implement |firstRectForCharacterRange| of NSTextInput protocol. And IMEs can decide the candidate window position by its result. > * Query the current IME state (mostly possible anyway using > compositionstart/end events) Gecko has such property if the context can use XPConnect (e.g., from add-ons, not web contents). It can check whether it's between compostionstart and compositionend or not. > * A way for js apps to define input context: E.g. Is this input field > for a person's name, for an address, etc? I think it also useful for autocomplete feature of browsers. I think that it should not be an API, it should be an attr of the editor element. > IMEs can use this information > to provide better suggestions. The TSF api allows properties to be > specified on text, perhaps some of this should be exposed in HTML? > Thoughts welcome. Does TSF have the feature? Which interface and method support it? -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Tuesday, 16 June 2009 05:39:27 UTC