ISSUE-9: text editing events, potentially including rich text editing

text editing

text editing events, potentially including rich text editing

IndieUI: Events (Future Release)
Raised by:
Dominic Mazzoni
Opened on:
We wish to explore rich text editing requirements for IndieUI and determine what features might go in 1.0, what might go to a later version, and what might be addressed by ARIA.
Related Actions Items:
No related actions
Related emails:
  1. ARIA in CSS (Was: [user-context] What are the use cases for exposing screen reader or magnifier version info?) (from on 2013-02-04)
  2. Re: IndieUI brainstorming (from on 2013-01-09)
  3. Telecon Minutes for 9 January (from on 2013-01-09)
  4. ISSUE-9: Rich text editing (from on 2013-01-09)

Related notes:

[MichaelC]: relates to PFWG-ISSUE-92

9 Jan 2013, 18:45:03

[MichaelC]: relates to

9 Jan 2013, 18:45:43

Rather than rich text editing (which is a big can of worms), I propose we only consider "cursor movement events" for now, and deal with the *rich* part later after rich text editing specs in ARIA and HTML5 are more mature.

In particular, I think that cursor movement events are useful for a wide range of apps, beyond those with rich text editors. Something as simple as a web form might listen for arrow keys in an attempt to move the user seamlessly between three fields of a U.S. phone number with area code, for example. In the spirit of Indie UI, we should make it possible to listen for higher-level events instead of arrow keys.

Note that these events differ depending on the native platform: on Mac OS X, for example, option-rightarrow moves to the end of the current word, while on Windows, control-rightarrow moves to the beginning of the next word. On mobile platforms, there might be gestures to control moving the cursor.

Perhaps these events could all be simply subtypes of a single "cursor movement" event.

* next character
* previous character
* beginning of current word
* end of current word
* beginning of next word
* end of previous word
* beginning of line
* end of line
* cursor up one line
* cursor down one line
* cursor up one page
* cursor down one page
* beginning of document/field
* end of document/field

Additionally, there should be a boolean field indicating whether this should extend a selection, corresponding to whether the shift key is held down.

I believe that this set of events would be sufficient for a web app to observe or intercept all cursor/selection movement within any editable text field, without ever listening to raw key events, and it would allow a mobile user agent to define alternative gestures to enable text editing that would work within any supported app.

Dominic Mazzoni, 9 Jan 2013, 19:42:57

Even if we don't go with the "rich" text editing, an API abstraction for document text contents and setting a selection range may be better here. If a UA/AT has to way for responses on all those events you listed, it will probably result in a severe lag when doing even the most basic text editing or even just text navigation.

James Craig, 9 Jan 2013, 23:04:54

Also the boolean you mention for shift selection is partially covered in markRequest. I think the current name is "fromLast" (open to other suggestions) for things like Shift+Click, and "retainMarks" for things like Option+Click (which, IIRC might be Shift+Alt+Click on Windows)

James Craig, 9 Jan 2013, 23:07:43

s/has to way for responses/has to *wait* for responses/

James Craig, 9 Jan 2013, 23:09:07

One more thing that appears to be lacking from the events above is how a user agent is supposed to determine where the current selection *is* on a custom textfield. IOW, even if these events were implemented, the caret position or selection may change, but the UA/AT would not know what to speak, b/c there is no interface to inspect the new selection after the change.

On standard edit fields like textarea and contenteditable, that inspection interface exists, but the events you propose are only necessary on custom edit fields where no such interface exists.

James Craig, 9 Jan 2013, 23:22:49

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 9.html,v 1.1 2016/04/04 15:09:44 ted Exp $