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

We got comments from Ojan at blink-dev@chromium.org:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/sxuEbPN6pPY/uL7jElv_y1cJ

I'm trying to continue discussion o public-webapps@, so the context would
not be lost.
Thanks Ojan for the comments, for the opportunity to start discussion of
the spec!


   - It's weird to have the enabled property be writable when there's an
   open method and it sounds like sometimes enabling can fail. What are the
   circumstances where it can fail? How about s/open/enable?

For example, if no IME is installed on the system and cannot be activated,
open() method can fail.
But whether you have any IME in your system, you can try setting 'true' to
.enabled.  If enabling fails,
enabled will remain false.

   - Can "caret" ever be a non-collapsed range? If not, then we should
   expose a new Position object that is just a Node and an offset?

Yes, I believe "caret" should be zero-width position.

   - Why is "text" a Node? Why not have CompositionDictionary have the same
   accessors as CompositionEvents (i.e. data and locale as DOMStrings)? What
   makes it so that the node in question only contains the composition text
   and not other text?

As this API is designed to be used in conjunction with CompositionEvents, I
think we don't have to duplicate
the way to access the same thing.
On the other hand, we already have access to composition text (in plain
text) via CompositionEvents.
What we want to add is the lost information for drawing composition text
(which will be in either composition
or conversion mode):
- caret position (to draw vertical bar indicating character insertion point)
- clauses list (usually for Japanese, long composition text can be divided
into several segments (clauses) and
  user agent (or script code) should indicate where the segmentation points
are, e.g. breaking underline at segmentation
  points)
- focused clause - during conversion mode, if the composition text is
segmented into several clauses,
  one of the clauses will have focus and be a target of conversion)

For the latter two, we have to add "List<Clause> clauses" where Clause = {
start, length } and an index.

   - Why is there setCaretRectangle and setExclusionRectangle?

setCaretRectangle() is for specifying the position where IME will put its
UI (suggestion or candidate window etc.) and
setExclusionRectangle() is for giving a hint where IME had better not put
any UI on the specified area but sometimes
IME inevitably has to put its UI overlapping/interfering underlying
application's UI due to constraints of e.g. candidate
window size, possible position and screen size. See attached screenshot.

   - "When a Web application draws composition text, it must call
   preventDefault() in compositionupdate handler so that the user agent will
   not draw the text." This is only true in an editable region, right? I'm not
   really sure this text is useful or belongs in this spec.

Yes, preventDefault() makes sense only for editable elements (input,
textarea, contenteditable) and may not
make sense for something else (e.g. canvas).  I think it makes sense for
mentioning preventDefault() here
because it clarifies the default expected behavior.

   - Do we need a method getInputContext? Can this just be an inputContext
   property?

As it sounds to me, the method creates the InputMethodContext only when
invoked, while the property
always have the context for each HTMLElement.  Implementation-wise, we can
just create the
object only when the property is accessed so not much difference, but the
method may sound natural IMHO.



On Fri, Apr 5, 2013 at 7:16 PM, Takayoshi Kochi (河内 隆仁) <kochi@google.com>wrote:

> 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
>



-- 
Takayoshi Kochi