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:[email protected]] Sent: Tuesday, April 02, 2013 4:32 PM To: Travis Leithead Cc: [email protected]; [email protected]; 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 <[email protected]<mailto:[email protected]>> 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
