Re: [IME] Preparing some feedback

Hi Travis,

Thanks for the detailed spec and comments!
I'll read it through and will post comments on them.


On Thu, Apr 25, 2013 at 3:41 AM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  Kenji, et al.:****
>
> ** **
>
> We appreciate the work you�ve put into this IME API spec so far and hope
> that this feedback will help further improve it! Jianfeng Lin, another
> program manager from the IE team put the following feedback together, as
> well as drafted the proposal, which I�ve uploaded to the mercurial server
> for easy viewing at:
> https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html.
> The proposal contains API designs that are the result of various feedback
> from several different teams inside of Microsoft including use cases from
> Microsoft Japan team, and designs from the folks who work on the in-box
> Windows IMEs and the IME integration layer inside Internet Explorer.****
>
> ** **
>
> Thanks for taking the time to review,****
>
> -Travis****
>
> ** **
>
> Some Points of feedback:****
>
> ** **
>
> Composition Dictionary****
>
> ** **
>
> dictionary Composition {****
>
>     readonly attribute Node    text;****
>
>     readonly attribute Range   caret;****
>
> };****
>
> ** **
>
> We can see exposing IME clauses as child nodes of �text� node, and making
> them real DOM nodes with styles being useful for a JS-based IME as the IME
> needs to tell the web application how to render the composition, but if JS
> IME is not a goal, is there any other scenarios that will benefit from
> this? If not, how about a simple design that expose the text being composed
> as DOMString?****
>
> ** **
>
> For �caret� attribute, if it�s for enabling JS-based IME, then exposing
> the caret ranges of IME clauses is helpful, but if it�s not for JS IME, is
> there any other usage? We understand that web applications want to know
> about the whole string of the tentative composition, but we are not sure in
> which case they want to know how the whole tentative composition string is
> divided into several parts. Another issue is that the range type only tells
> the start and end offsets of the composition from its immediate parent. Web
> application usually wants to know the offset from the beginning of the text
> field so that it could combine the composition alternate with the text
> before it to create a full text string. But the beginning of the text field
> can be up in the parent tree if it�s a contentEditable element and requires
> JavaScript code to trace up in the parent tree to get the right offset. **
> **
>
> ** **
>
> So instead of a dictionary type for composition, we suggest this directly
> under InputMethodContext interface. Please let us know if you have
> scenarios that need to be the other way.****
>
> ** **
>
>     readonly attribute DOMString    compositionText;****
>
>     readonly attribute unsigned long   compositionStartOffset;****
>
>     readonly attribute unsigned long   compositionEndOffset;****
>
> ** **
>
> Beyond that, we also propose exposing the composition alternatives. For
> example a search engine can use the current non-committed alternatives to
> fine tune the real-time search suggestion list.****
>
> ** **
>
>     sequence <DOMString>   getCompositionAlternatives ();****
>
> ** **
>
> For the following in your proposal, is there any usage scenario besides
> enabling IME on non-editable elements like canvas? ****
>
> ** **
>
>      attribute boolean   enabled;****
>
>      void   setCaretRectangle (Node anchor, long x, long y, long w, long
> h); ****
>
>      boolean   open ();****
>
> ** **
>
> As we raised in the following discussion threads before, we don�t think
> using canvas to create an editor is the right way to go. Please let�s
> discuss about issues you are trying to solve and find out a better solution.
> ****
>
> http://lists.w3.org/Archives/Public/public-html/2011Nov/0210 ****
>
> http://lists.w3.org/Archives/Public/public-html/2011Dec/0157.html ****
>
> http://lists.w3.org/Archives/Public/public-canvas-api/2012JanMar/0029.html
> ****
>
> ** **
>
> For the following function****
>
> ** **
>
>      void   setExclusionRectangle (Node anchor, long x, long y, long w,
> long h); ****
>
> ** **
>
> We recommend replacing with this ****
>
> ** **
>
>      ClientRect   getCandidateWindowClientRect ();****
>
> ** **
>
> Because although setExclusionRectangle can ensure that the IME candidate
> window doesn't overlap with some specific UI that the web application
> doesn't want to be occluded (e.g. search suggestion list), it doesn�t seem
> to be able to ensure that the two UIs layout in a desirable way. For
> example, if the web application wants to render a search suggestion list
> that docks below the IME candidate window and aligns nicely without gap, it
> can't do so with setExclusionRectangle()  because it doesn't know where is
> the candidate window, how tall it is below the text field, and whether it
> is horizontally shifted to follow the caret position. Therefore we are
> proposing getCandidateWindowClientRect together with a group of CSS
> properties to give more flexibility for the UI design.****
>
> ** **
>
> We also propose several new APIs in InputMethodContext, CSS properties and
> attributes to provide more information and more control around IME. Please
> refer to the HTML version of our proposal for more detail. ****
>
> ** **
>
> -Jianfeng Lin****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Kenji Baheux [mailto:kenjibaheux@google.com]
> *Sent:* Tuesday, April 02, 2013 4:32 PM
> *To:* Travis Leithead
> *Cc:* hbono@google.com; kochi@google.com; public-webapps
>
> *Subject:* Re: [IME] Preparing some feedback****
>
> ** **
>
> Thanks Travis.****
>
> ** **
>
> We are eager to hear your feedback.****
>
> The spec was down scoped to exclude Javascript based IME because we could
> not find any compelling use case but we would be happy to reconsider if you
> do.****
>
> ** **
>
> 2013/3/30 Travis Leithead <travis.leithead@microsoft.com>****
>
> Thanks for submitting these updates to the Input Method Editor API. I've
> had an opportunity to review them and would like to offer some feedback for
> the spec.
>
> On the IE team, we have also been working on building an IME-related API,
> but one geared specifically toward working with the operating system's IME
> (vs. a JavaScript-implemented IME). Long term, we think that it makes sense
> to have an IME API Spec that supports both system and JavaScript-based IME
> scenarios. We would like to work with you to land on a unified design that
> includes the right set of API for working with both system and
> JavaScript-based IMEs. We'll write up a proposal to start the discussion.
>
> Thanks,
> Travis****
>
>
>
> ****
>
> ** **
>
> --
> Kenji BAHEUX****
>
> Product Manager - Chrome****
>
> Google Japan****
>



-- 
Takayoshi Kochi