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

Re: Extra notes on composition events

From: Doug Schepers <schepers@w3.org>
Date: Mon, 10 Aug 2009 06:49:20 -0400
Message-ID: <4A7FFB30.8020207@w3.org>
To: Daniel Danilatos <daniel@danilatos.com>
CC: www-dom@w3.org
Hi, Daniel-

Thanks!  I'm now back from my conference travels, and will be 
integrating this in the next couple days.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Daniel Danilatos wrote (on 8/7/09 7:37 AM):
> 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 Monday, 10 August 2009 10:49:31 GMT

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