Re: CommandEvent for user intentions

Have you seen the recent post about the rich text editor that Medium uses?
 It is a somewhat cheeky essay, including a mathematical proof, about how
contentEditable is broken.  The conclusion is that in order to move
forward, we need to treat contentEditable as an API, rather than as a
standalone component that tries to do everything itself.  It discusses the
idea of an "edit intent API", which is very in line with this proposal for
CommandEvents. https://medium.com/medium-eng/122d8a40e480


On Wed, May 21, 2014 at 11:51 AM, Ben Peters <Ben.Peters@microsoft.com>wrote:

> Great to hear! I’m working on an explainer document that will be more
> descriptive than the short wiki docs I wrote a couple weeks ago. My
> thoughts on your questions should be made clearer there. I’ll update this
> thread by the end of the week with more details, and my initial thoughts
> are below.
>
> > 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?
>
> I see this as being more than just well-known keyboard shortcuts. I would
> like web developers to be able to extend it for their own purposes.
>
> > 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).
>
> This is a great idea! I'll include it in my spec.
>
> > 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?
>
> My current thought is that Selection events should be used for selection,
> and CommandEvent for things that would be in a toolbar or context menu. I
> think the design should make it easy to create and style toolbars based on
> the available commands and their state. Input events don't cover everything
> that would be in a toolbar, and they fire for things that already have
> events for user intentions (like Clipboard Events).
>