W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

CommandEvent for user intentions

From: Ben Peters <Ben.Peters@microsoft.com>
Date: Fri, 2 May 2014 00:43:35 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <744d5b3fd8c54b508f3cf4f4f44c5295@BLUPR03MB437.namprd03.prod.outlook.com>
In addition to the mail I just sent about contentEditable=minimal, I have been discussing a new concept to allow script to respond to users intentions, rather than their direct actions like KeyboardEvents. I'm calling this idea CommandEvent for now. My thoughts are below, and also on GitHub [1] along with a code sample [2]. I would love some feedback on this.

**Problem**
There are several different ways users can indicate that they are trying to perform a given action. For instance, a user may press control-a (or command-a) on an English keyboard to indicate that they would like to select all of the content in the current context. They may also use a Select-all item in a context menu for this. In other languages, the keyboard shortcut may vary. There may also be gestures for these intentions on various platforms. Today, it is very difficult for a website to detect a user's intention. They can intercept keyboard events but not other actions like context menu items, and they must handle keyboard localization themselves.

Further, the meaning of a keyboard shortcut or gesture may change from application to application. For example, in Sublime there are a large number of keyboard shortcuts that don't necessarily match the system-default behavior. Sublime's shortcuts can even be customized by the user.

All of this means that sites must determine what a user is intending using keyboard shortcuts, gestures, context menus, and mouse events separately.

**Proposal**
Instead, we should allow sites to respond to user intensions via a new Event. For the sake of discussion, this event is called CommandEvent. 

interface CommandEvent : Event {
    readonly attribute DOMString commandType;
}

By default, a browser will fire a CommandEvent for well-known keyboard shortcuts. For instance, control-a on an English Windows browser, select-all in a context menu, or a select-all gesture would each result in a CommandEvent of type select-all. If a site would like to override Select-All behavior, it would listen for this event, perform its own behavior, and preventDefault(). If default action is not prevented, normal browser behavior would continue.

Further, if a site would like to have a different behavior for control-a, the author can create a simple handler for this keyboard event that fires a different command (explained below in the Relationship to execCommand section) and preventDefault(). A browser context menu item called 'select-all' would not be affected, and would continue to fire the CommandEvent of type select-all.

**Relationship to execCommand**
document.execCommand is used today to invoke a well-known set of browser commands like select-all, bold, etc. To accommodate the near-infinite variability of web sites, this proposal also extends execCommand(command) to fire a CommandEvent of type command. If it is handled and preventDefault() is called, the browser would take no action. If the default is not prevented, the browser would perform the associated action, if one exists.

Note: some believe that execCommand is not a good interface, partially because the second argument is almost never used. If some other function were used here, that would be fine too.

Check out this CommandEvent sample for a possible use of this functionality.

**Summary**
The end result of this proposal is that sites can respond to all possible ways to detect a user's input. If a new style of input becomes available (perhaps Speech), any site that uses CommmandEvent would just work with any CommandEvent that the browser sends for the new input type (perhaps speaking "select all text" fires a CommandEvent with type select-all). Any localized keyboard shortcuts would send the appropriate CommandEvent, so site authors wouldn't need to worry about that aspect of localization. And sites have the ability to trigger a CommandEvent for their own unique functionality, enabling a single solution to responding to any user intention.

-Ben

[1] https://github.com/w3c/editing-explainer/wiki/CommandEvent
[2] https://github.com/w3c/editing-explainer/wiki/CommandEvent-sample
Received on Friday, 2 May 2014 00:44:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC