Re: Proposal: Input Method Editor API

Greetings Nakano-san,

In principal, this document is just for starting a discussion and I do
not stick to it at all. I'm happy to change it if it provides more
benefits to web-application developers. (On the other hand, it is not
a good idea to make this spec less useful for them.) So, it would be
definitely helpful to give me the benefits for web-application
developers when requesting me a change.

On Tue, Sep 21, 2010 at 11:07 PM, Masayuki Nakano <masayuki@d-toybox.com> wrote:
> Hi, Bono-san.
>
>> I would like to publish a document that describes the details of my
>> proposal to the URL below:
>>
>> https://docs.google.com/fileview?id=0B8eVDHQ9_22-YWEyMGNmZjUtMWYxNy00YjI3LTlhYmQtNzA1YjlmYzViMzI0&hl=en&authkey=CNXmwLAM
>>
>> Would it be possible to give me your thoughts?
>
> I have some objections:
>
> 1. Is "end" better than "length" for CompositionCaret and CompositionClause?
>
> I guess that "length" is more useful and simplizes implementation of Web
> applications.

Even though this document uses "end" instead of "length" just because
String.substring() uses it, I do not stick to it.
By the way, as you wrote below, when the CompositionCaret (or
CompositionClause) interface has a DOMString attribute "text", this
attribute also has a "length" attribute. Therefore, I think it is
redundant to add a "length" attribute to the CompositionCaret
interface.

> 2. The default values textColor, backgroundColor and lineColor of CompositionClause.
>
> I think that the default values of textColor and lineColor should be
> currentColor rather than black and white. If the <canvas> editor uses
> non-system color for the text and background, black and white aren't useful.
>  Similarly, backgroundColor's default value should be transparent.

Thank you for noticing this. I will update my document.

> 3. Isn't useful text property of CompositionClause?
>
> I think that composition string renderers want to get each text of each
> clause.

Even though I'm happy to add this "text" attribute, I'm wondering if
we need the "length" attribute as written above.

> 4. lineStyle of CompositionClause should have more styles.
>
> You defined only "none", "solid", "dotted" and "squiggle". But I think there
> should be "dashed". Furthermore, there should be a property which suggests
> whether the line is bold or not.
>
> I think that we should be usable all values which will be defined in
> text-decoration of CSS3 text module.

I'm personally wondering if we really need all values defined in
text-decoration because it includes some values that may not be useful
for IME text; such as blink, overline, and line-through. Nevertheless,
if web developers need them, I'm happy to add them.

> 5. Are Candidate related interfaces and methods needed?
>
> We're not accessible the candidate list (and its items) on non-Windows
> platform, so, I don't think that should be usable for Web application
> developers.

Right, this interface is only for Windows now. (We may be accessible a
candidate list if we implement a JavaScript IME, though.)
Anyway, it is a good idea to remove the Candidate interfaces and
methods because they are overkill for the initial spec.

> 6. How do we do when InputMethodManager::setEnable(node, false) is called
> during composition?
>
> I think that the composition should be discarded (or committed), but we
> *cannot* discard the composition forcibly on Linux. So, when another IME
> usable editor gets focus, should we start the last composition?

In my honest opinion, I do not have clear answers for this question.
(Another option is just adding a return value to the function and
return false on platforms that cannot discard the composition.) I just
would like to hear opinions of web-application developers to find the
happiest solution for them.

> 7. InputMethodManager::setEnable() shouldn't be a method of <canvas>?
>
> I think that there is no needs which web application developers can render
> composition string themselves on non-<canvas> element.
>
> And if this is called for enabling, the element must be changed as
> focusable.

In my personal opinion, all IME-related interfaces should be in this
spec. (It is harder for web-application developer to practice learn
IME interfaces if they are scattered among more specs.)

> 8. InputMethodManager::showCompositionWindow isn't needed.
>
> I need to work very very hard for Gecko if we need to render composition
> string on all elements but I think nobody wants such function.
>
> I think that when InputMethodManager::setEnable(node, true) is called, the
> web application must render the composition string themselves. And browsers
> shouldn't render the composition string. And it's enough.

OK. I will delete it.

> 9. InputMethodManager::showCandidateWindow() isn't needed.
>
> See #5, I don't think this method isn't needed.

Ditto. I will delete it.

> 10. InputMethodManager::setCaretRecctangle() is...
>
> With TSF and Cocoa (Mac), IME can know position of any characters anytime.
> So, they may want to know non-caret position's character rect.
>
> I think that Web application should listen the query by callback function.
> Then, browser for Win32-IMM and Linux can call the callback function when
> they need to call ImmSetCandidateWindow() or
> gtk_im_context_set_cursor_location().

I'm wondering what happens if this callback function (written by
web-application developers, right?) takes long time. If a user agent
needs to wait until this callback function returns, it may make some
user-agents junky.

> Furthermore, IMEs want more information, e.g., selection range, selected
> text, all text in the focused editor, a character index which is rendered at
> a point, etc... So, many callback functions are needed...

I realize the current interface is not perfect. On the other hand, I
also realize adding more callbacks (or interfaces) puts more burden
onto web-application developers. (I intentionally avoided adding many
interfaces so web-application developers can use them easily.) Is it
possible to give me advantages of your idea fro the point of
web-application developers? I'm happy to add them if they provide more
advantages than the disadvantages of your idea.

> Finally, web application needs a method which notifies to IME when the
> layout in editor is changed. E.g., when editor is scrolled, position of
> candidate window should be updated.

Sorry, I cannot figure out this comment. I assume this rectangle is a
local coordinate (such as a rectangle in a <canvas> element) and a
user-agent is responsible to convert it to the screen coordinate if it
needs to send it to a system IME. Therefore, when a user agent scrolls
a web page, it converts the given local rectangle to the screen
rectangle again and sends it to the system. Is it possible to correct
me if I'm something wrong?

> 11. InputMethodManager should be renamed.
>
> InputMethodManager isn't good name because it's a term of IME system of
> Windows. It's usually called IMM ;-)

I do not stick to this name. I'm happy to change it if there is better name.

Regards,

Hironori Bono
E-mail: hbono@google.com

Received on Wednesday, 22 September 2010 06:26:47 UTC