- From: Masayuki Nakano <masayuki@d-toybox.com>
- Date: Tue, 21 Sep 2010 23:07:40 +0900
- To: www-international@w3.org
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. 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. 3. Isn't useful text property of CompositionClause? I think that composition string renderers want to get each text of each clause. 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. 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. 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? 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. 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. 9. InputMethodManager::showCandidateWindow() isn't needed. See #5, I don't think this method isn't needed. 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(). 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... 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. 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 ;-) -- Masayuki Nakano <masayuki@d-toybox.com> Manager, Internationalization, Mozilla Japan.
Received on Tuesday, 21 September 2010 14:08:16 UTC