Re: CommandEvent for user intentions

I strongly agree that something like CommandEvents is necessary: a web
developer should be able to respond to the user’s intent, aka “selectAll”,
rather than enumerating, listening to, and responding to each and every
platform specific way that the intention to selectAll can be communicated.

How encompassing do you envision CommandEvents?  Would it only cover well
known keyboard shortcuts and actions like those currently used by
execCommand?

What about taking this further and providing better events in two distinct
areas: those involving selections (intents like selectAll, but also
selection modifications like caret movement by keyboard or gestures,
selection changes, etc) and those involving input (including
paste/drop/cut/formatting, but also basic text insertion via
keyboard/voice/etc).

I’m not sure an extra event type is necessary here though: why not use
beforeinput for the input events, and selectionchange for selection events?
 Ryosuke’s selection spec currently has a placeholder for selectionchange,
and seems like the right place and timing to work this in?


On Sun, May 11, 2014 at 3:41 PM, Johannes Wilm <johannes@fiduswriter.com>wrote:

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