[editor] Give webapps developers power to build a DOM-based editor

For simple editing, <input> or <textarea> works, and contenteditable attribute is widely used for building a rich text editor. But when more minute control than contenteditable provides is required, a developer may go so far as to build a DOM-based editor without using contenteditable. There are several projects such as ACE editor which is widely used for popular services like Cloud9 or gist.github.com, and CodeMirror, which is also widely used. Most building blocks for building such an editor like key events, composition events, and drawing arbitrary text are provided. But once IME is involved, for example, a webapp cannot draw composition text itself or control how composition text is drawn by the hosting user agent until the text is committed. It would be nice if webapps had an ability to draw composition text as native applications do as on-the-spot conversion.

Requirement: Developers of DOM-based editor should have a way to interact with and control the system IME to retrieve information about clauses of the composition text and prevent a user agent from drawing composition text.

[suggest] Prevent system IME from interfering with “suggest” features

A user goes to a Web-based search engine and starts typing in Japanese, and with each keypress, the search engine starts giving a drop-down list of auto-completion suggestions. At the same time, the user’s system IME has been invoked (by the user, in order for the user to type in Japanese) and also starts providing completion candidates for what the user has typed in—shown in a separate candidate window. But that candidate window appears over (in terms of Z-index) the drop-down list of auto-completion suggestions the Web-based search engine is displaying, making it impossible for the user to actually select any of the suggestions provided by the search engine.

Requirement: Web developers should have a way to prevent a system IME from interfering with text input in their Web applications and from obscuring parts of their Web applications from which users are intended to make selections from suggestions based on what they type.

[games] Prevent system IME from interfering with games

A user who is playing a Web-based game might inadvertently press a key combination that would suddenly cause an system IME to be invoked and then also possibly cause an IME candidate window to appear in the midst of that game. That wouldn’t be what the user would expect.

Requirement: Developers of Web-based game should have a way prevent the system IME from being invoked during a game.

This use case in similar to the use case for providing the proposed Screen Orientation Lock API, or even the Pointer Lock API, in that game developer should have a way to “lock” (out) the system IME behavior while the user is playing the game.

[ime-interact] Get information back and forth from installed IMEs

Native applications running on devices are able to interact with the system IME in useful ways, and are able to get information back and forth from them. Other third-party runtime environments also provide APIs for applications to interact with a system IME and user agents in useful ways. For example, ActionScript® 3.0 for the Adobe® Flash® Platform provides a flash.system.IME interface with methods that let you “directly manipulate the operating system’s inp method editor (IME) in the Flash runtime application that is running on a client computer. You can determine whether an IME is installed, whether or not the IME is currently enabled, and which IME is enabled. You can disable or enable the IME in the application, and you can perform other limited functions, depending on the operating system.”

Requirement: Web applications should be able to get information back and forth from system IMEs and to otherwise interact with system IMEs—in a similar way to the ways in which native applications and third-party runtime applications can interact with system IMEs, including capabilities such as the following:

• indicate to the user whether the Web application renders composition text by itself, or needs to ask user agents to render it
• determine the place where user agents render composition text
• detect whether the user agent renders candidate windows by themselves
• determine the place where user agents render candidate windows