Re: Update of the IME API spec working draft [call for comments]

Hi all,

The updated IME API spec is now published as a second working draft at:
http://www.w3.org/TR/ime-api/ (Apr 04, 2013)

Thanks to Arthur for helping this published.
We are open to any feedback and comments.

In particular, I'd like to get feedback for some things:

1. Is composition dictionary sufficient/useful?

   The intention of the existence of this structure is to give more
information for composition text
   which is already available via D3E composition events.  The previous
version had some style
   information for the text, and after its publication the previous author
simplified it to have just
   "Node text" and "Range caret" following the feedback.

   A typical use case for this is to use it for drawing composition text
yourself, but for that case
   I suppose using Node and Range object sounds too generic.  If a web
application just
   want to use a simple [start, end) positions of caret for text, deriving
it from Node and Range
   object needs unnecessarily complex Javascript code to get these numbers.

   For Japanese use cases, we think plain composition text and vector of
[start, end) of char index in the text
   for each segment, and which segment is being converted - are probably
enough  (but to be honest,
   I am not sure there applies for Chinese, Korean and other languages).

   If the Node object contains style information that the user agent would
be using for drawing the text,
   it would be nice because the app can just put the node in DOM then it
would look identical
   as it is drawn by the user agent, but extracting e.g. segment
information from it would be very hard,
   as such style information is inevitably implementation dependent and
cannot be standardized.

2. Is "Caret" an appropriate name for APIs?

   The term "caret" is used in this API (in composition dicrionary and
setCaretRectangle() method) to mean
   some range in the composition text, but usually it is used for
zero-width vertical bar
   which indicates the position in the text that typed characters are
inserted.
   Probably we should have a better name for it.

On Tue, Mar 19, 2013 at 6:40 PM, Takayoshi Kochi (河内 隆仁)
<kochi@google.com>wrote:

> Hi all,
>
> It's been a while since the last update for the IME API spec, but we
> restarted the work on this.
> I (Takayoshi Kochi) have taken over this authorship from the previous
> author (Hironori Bono)
> for updating the spec.
>
> If you are interested, please take a look at the current working draft:
> https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html
> (and log https://dvcs.w3.org/hg/ime-api/log)
>
> Any comments are welcome.
>
> Here are highlights of the changes since the last draft:
>
> * Removed Javascript IME from the spec.
>   (no compelling use case for this)
> * Added an API to hint IME UI positioning (setExclusionRectangle()).
>   (e.g. when showing autocomplete suggestions, IME UI may interfere with
> it)
> * Updated example Javascript code.
> * InputMethodContext interface changes
>     * Simplified 'enabled' attribute
>     * Simplified 'setOpenState()' to just 'open()' (as we don't have to
> turn off system IME
>       for Javascript IME)
>     * Clarified what 'locale' attribute is expected, instead of 'source'
> which may sound like
>       User-Agent of IME.
>
> Thanks in advance,
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi