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

RE: CommandEvent for user intentions

From: Ben Peters <Ben.Peters@microsoft.com>
Date: Thu, 22 May 2014 23:04:33 +0000
To: Piotr Koszuliński <p.koszulinski@cksource.com>
CC: Julie Parent <jparent@gmail.com>, Johannes Wilm <johannes@fiduswriter.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <f4f85b47b7e246a09d0abf37180649f9@BY2PR03MB444.namprd03.prod.outlook.com>
On Thu, May 22, 2014 at 4:02 AM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:
> I wrote a longer reply in the contentEditable=minimal thread, which touches some aspects of command events. Actually, before some stable point about cE=minimal is reached I feel that it may be hard to design command events in a way that both are interoperable. Command events should be an extension to cE=minimal making it possible to create advanced solutions on top of it. Therefore, it may be beneficial to discuss both of them in one thread.
> But for now, here are some additional thoughts which I haven't included in the email about cE=minimal.
> 1. It should be possible to modify selection and DOM in a command event listener, but leave the action to the browser. Browser should perform the action on the updated selection and DOM. Example - I want to transform "* " to a list when user types additional character. So I would listen to keyboard event, check if two previous characters are "* ", replace them with a list and place selection inside <li>. But I want browser to perform character insertion so I don't have to handle undo manager, scrolling to show caret, etc. There are of course other ways to achieve the same, but this seems to be the cleanest.

Yes this is an important concept. In CommandEvent, you should be able to modify the behavior and then not call preventDefault. This will allow the browser to perform the action with new data.

> 2. It's not totally necessary, but it would be nice if command event would also carry an information about its future result. For example command fired for up-arrow key could carry a range with the proposed position of caret. So if I don't agree with browser implementation, because for example it enters a non-editable region, I can check that and handle this specific case by myself. Since there's no easy JavaScript solution for handling up/down arrow keys such information would allow us to focus only on these specific behaviours we don't like.

Great idea! I'll include this in my draft Explainer doc, which is coming later today.
Received on Thursday, 22 May 2014 23:05:09 UTC

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