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

Re: CommandEvent for user intentions

From: Julie Parent <jparent@gmail.com>
Date: Wed, 21 May 2014 12:09:33 -0700
Message-ID: <CAF42kzE9SWJ6Ajgxm61pQhDdxYPwMVS1b7gJxV_BxyxTWpHMTw@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: Johannes Wilm <johannes@fiduswriter.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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).
Received on Wednesday, 21 May 2014 19:10:02 UTC

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