Re: CommandEvent for user intentions

This looks good! I doubt it makes sense to program a complex website now
and not touch it when speech or some new technology becomes available, just
become no complex site seems to work if let untouched for more than three
months, but the overall idea is good. Also,it seems this is the only way to
get around the right-click context menu. Until now one, it is my
understanding, one can only remove the right click menu entirely (including
the options for spell checking), or have the entire menu available.


On Fri, May 2, 2014 at 2:43 AM, Ben Peters <Ben.Peters@microsoft.com> wrote:

> 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
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com