W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Extra notes on composition events

From: Daniel Danilatos <daniel@danilatos.com>
Date: Fri, 7 Aug 2009 21:37:27 +1000
Message-ID: <b2cb92d0908070437w7a6321b0j5e3b652adefa97a5@mail.gmail.com>
To: www-dom@w3.org
Hi guys,

Here are the promised additional points / suggested requirements
regarding composition events. These have come out of a few discussions
with Chrome engineers. It's still rough, so feedback is welcome.

(Here, I use "user agent" to refer to the implementor of the DOM spec,
e.g. a browser, and "application" to refer to the listener of DOM
events, e.g. a javascript application in a browser).

== Selection ==

 * Composition state should not be initialised until after the
compositionstart event returns from the application
 * During a compositionstart event, the application may make arbitrary
modifications to the DOM and to the selection
 * When the event returns, the composition will begin wherever in the
DOM the selection now happens to be

== Reconversion ==

Some IME APIs support reconversion. One use case of reconversion is
for the user to select some already committed text, and cause it to
re-enter composition mode, to be further modified.

 * If the user has indicated that they wish to reconvert a selection,
so that the composition state will start with a non empty composition
string, the range of text to be re-composed must be passed as part of
the compositionstart event, as a DOM range (Probably
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html)
 * The application may modify this mutable range object, (as well as the user's
selection and the DOM itself, as described earlier).
 * After the composition start event returns, the user agent must
delete the contents of the range. (by doing it after, so that the
application has a chance to change the range, prepare itself for the
deletion, etc. It could even do the deletion itself, then set the
range to be empty, so that the user agent does not touch the DOM for
this). The user agent will then insert text matching the initial
desired composition state where the user's selection now happens to
be.
 * The composition will then begin where the selection happens to be.
 * This method allows applications to specify where the composition
will occur, to control the reconversion of their content, but still
gives control to the IME over what the initial composition state will
be.

== Document locking ==

Some IME APIs support the ability for the IME application to request
the document be locked. Currently I'm only aware of Microsoft TSF
being able to do this. Before user agent support this feature, we need
to clearly define an API so as not to interfere with applications
using the DOM. Suggestions welcome. Some vague ideas:

 * Forbid locking (simplest)
 * Negotiate locking with application (via some API). The application
must honour its promise (user agent can throw exceptions)
 * Some kind of copy and merge strategy (interesting, but can it be
made to work?)
 * Just throw exceptions if the application tries to modify a locked
document (very undesirable)
Received on Friday, 7 August 2009 11:38:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT