Re: [IME] Preparing some feedback
On Thu, May 2, 2013 at 9:44 AM, Takayoshi Kochi (河内 隆仁) wrote: > Before getting into details, is it appropriate to discuss CSS properties > (ime-*) and HTML attribute (inputmode) here? > > At least, I think I should not incorporate CSS/HTML spec into the IME API > spec, as they are already in the separate specs > and duplication will make lots of issues. Discussing at least the effects of the features might be appropriate. I.e. HTML/CSS defining syntax, and you defining behavior. E.g. Fullscreen defers to HTML for the definition of the allowfullscreen attribute, but the effects of that attribute (through the allow fullscreen flag) are defined in the Fullscreen API Standard. -- http://annevankesteren.nl/
Re: [IME] Preparing some feedback
sure 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:kenjibah...@google.com] > *Sent:* Tuesday, April 02, 2013 4:32 PM > *To:* Travis Leithead > *Cc:* hb...@google.com; ko...@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 > > 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
Re: [IME] Preparing some feedback
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:kenjibah...@google.com] > *Sent:* Tuesday, April 02, 2013 4:32 PM > *To:* Travis Leithead > *Cc:* hb...@google.com; ko...@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 > > 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
RE: [IME] Preparing some feedback
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 Nodetext;
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 DOMStringcompositionText;
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.
sequencegetCompositionAlternatives ();
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:kenjibah...@google.com]
Sent: Tuesday, April 02, 2013 4:32 PM
To: Travis Leithead
Cc: hb...@google.com; ko...@google.com; public-web
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 > 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
[IME] Preparing some feedback
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
