- From: 河内 隆仁 <kochi@google.com>
- Date: Fri, 6 Dec 2013 14:48:57 +0900
- To: public-webapps <public-webapps@w3.org>
- Message-ID: <CADP2=hoyW--k7CFsb7E5Ep-NqXAq4Xk61COTj2ED+=rby1m=dg@mail.gmail.com>
Hi all, Since the last working draft in August, IME API editor's draft has been changed significantly with the result of discussions at TPAC 2013. The biggest change is that I split the previous spec into 2 parts, streamlined main part and others, so the main part which has been mostly agreed on can make smoother progress on standardization track. See below for detailed changes. I would like to push this version to publish a new working draft. Here's the current cut of editor's draft: https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html (to be specific, https://dvcs.w3.org/hg/ime-api/raw-file/771d75e4e177/Overview.html) (and log https://dvcs.w3.org/hg/ime-api/log) Any comments are welcome. ===== Here are highlights of the changes since the last working draft (20130815): * Split the draft into main and annex To get the standardization process smoother, only core APIs are left in the main draft and the following parts are pushed to the annex for further discussions or refinements: - Drawing IME candidates in Javascript * CompositionEvent interface extension (segment information etc.) * setCaretRectangle() API - Delivering IME related events to non-editable elements - confirmComposition() (not used for overlapping UI usecase) - locale (further refinement required) * Example/use cases/best practices - Modified example1 code (suggest UI) to use the new candidatewindow events. - Fixed some ReSpec warnings (no visible change). * API [CORE] - Added oncandidatewindow{show,update,hide} events and getCandidateWindowClientRect(), as proposed by Microsoft [1], except * isCandidateWindowVisible() is omitted due to redundancy. * mentions about synchronousness are dropped due to consideration for implementability on non-Windows platform. (although this does not mean discouraging synchronous implementation.) - Added compositionStartOffset/compositionEndOffset to InputMethodContext, as proposed by Microsoft [1] [4]. [ANNEX] - Removed setExclusionRectangle in favor of using candidatewindow{show,update,hide} events. - Added enableEditingEvents()/disableEditingEvents(), for getting events delivered to non-editable elements. Removed a sentence about HTML5 inputmode attribute for getting events.[3] - Renamed selection{Start,end} to activeSegment{Start,End} as a result of the discussion at [4]. - Merge Composition interface into D3E CompositionEvent. This makes sense as whenever any content or state of composition changes, a CompositionEvent is fired, and it avoids any consistency issue between composition events and the content of Composition. [1] Microsoft proposal: https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html [2] Comment from James Su http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0361.html [3] Adding a method to deliver editing-related events to a DOM element https://www.w3.org/Bugs/Public/show_bug.cgi?id=23422 [4] Composition dictionary should be changed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22059 Thanks in advance, -- Takayoshi Kochi
Received on Friday, 6 December 2013 05:49:44 UTC