- 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