- From: ?? ?? <hbono@google.com>
- Date: Wed, 22 Sep 2010 15:25:44 +0900
- To: Masayuki Nakano <masayuki@d-toybox.com>
- Cc: www-international@w3.org
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