W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

RE: User Intentions Explainer (was: List of Intentions)

From: Cynthia Shelly <cyns@microsoft.com>
Date: Fri, 8 Aug 2014 20:42:36 +0000
To: Ben Peters <Ben.Peters@microsoft.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>, Julie Parent <jparent@gmail.com>, "public-indie-ui@w3.org" <public-indie-ui@w3.org>, public-webapps <public-webapps@w3.org>
Message-ID: <bb46e543ea7142dc8d979e304b323b51@BLUPR03MB166.namprd03.prod.outlook.com>
This is a really solid list.  Thank you for pulling it together, so we can start towards a harmonized set of user events.

From: Ben Peters [mailto:Ben.Peters@microsoft.com]
Sent: Monday, August 4, 2014 7:28 PM
To: public-editing-tf@w3.org; Julie Parent; public-indie-ui@w3.org; public-webapps
Subject: User Intentions Explainer (was: List of Intentions)

Cross-posted​: Editing TF, IndieUI TF, WebApps WG

In order to solve the broad issue of User Intentions, we have compiled below a list of User Intentions derived from all of the sources of intention-style events that I am aware of. I agree with Julie that some of the events below are not in scope for Editing at this time. However, they are in scope for IndieUI, and I think that we have an important opportunity here to bring all concepts of "Intentions" together in a single explainer document so that 1) web developers can have a coherent picture of how to understand User Intentions and 2) the specs that concern User Intentions do not overlap. To that end, I propose that we create a new User Intentions Explainer document, borrowing from the work of the Editing Explainer and IndieUI to give an overview of how all of the following Intention Events work together in a high-level non-normative form:

Clipboard API
HTML5 Drag and Drop
Selection API (beforeSelectionChange)
DOM Events (beforeInput)

Each of these specs solves some aspect of User Intentions, and they should be coherent. For instance, we need to solve how beforeInput does not overlap Clipboard and DnD, and consider moving some parts of IndieUI that apply to input (undo/redo) to beforeInput.

Further, I propose that we fine-tune the Editing Explainer, making it clear that there are two problems we're trying to solve in that space- Editing Intentions and Extensible Web Editing. From there we can begin to create normative specs for solving these two Editing problems.

The end result of this would be a high-level explainer for all known User Intention specs, and a high-level explainer for Editing. Then we can solve each individual problem more granularly while maintaining coherence. Thoughts?

From: Julie Parent <jparent@google.com<mailto:jparent@google.com>>
> This is a great list, and I agree it is the right starting point.
> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters <Ben.Peters@microsoft.com<mailto:Ben.Peters@microsoft.com>> wrote:
>> We now have a good list of use cases on the Explainer[1]. I believe the next step is to come up with the Intentions that we need to allow sites and frameworks to respond to. After that, we can determine which current or new spec each Intention is covered by. Please let me know what you think of this list and if you agree it covers our use cases. The last several are borrowed from IndieUI[2], which we could use to cover those cases if we believe that is best.
>> * Focus/place caret
>> * Move caret
>> * Start selection (eg mouse down to select)
>> * Update selection (eg mouse move during selection)
>> * Finish selection (eg mouse up after selecting)
>> * Modify selection (extend selection after it's finished. Might be covered by update/finish)
>> * Insert text
>> * Insert content / insert HTML
>> * Delete content
>> * Delete forward
>> * Delete backward
>> * Insert newline
> Do we need newline as a special case? Wouldn't this be covered by insert text/content/HTML?
>> * Undo
>> * Redo
>> * Paste
>> * Copy
>> * Cut
>> * Drag start/over/stop
>> * Drop
>> * Scroll/pan
>> * Activate / Invoke
>> * Expand
>> * Collapse
>> * Dismiss
>> * Media next/previous/start/stop/pause
>> * Rotate
>> * Zoom
>> * Value change
> Is this the set from indie-ui?  I think we should make a decision if we are trying to cover these cases or not, as they do not make sense in the context of rich text editing and might be out of scope.  It would help to have a list of arguments for/against merging with indie-ui?
>> Ben
>> [1] http://w3c.github.io/editing-explainer/commands-explainer.html

>> [2] http://www.w3.org/TR/indie-ui-events/

Received on Friday, 8 August 2014 20:43:27 UTC

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