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

[editing] Changing Default Intentions

From: Ben Peters <Ben.Peters@microsoft.com>
Date: Wed, 18 Jun 2014 01:08:57 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <59eaf3124a514161a5e7ee3726ddfc75@BLUPR03MB437.namprd03.prod.outlook.com>
I think the issue of using execCommand and the issue of re-entrant Command events can be solved at the same time. To that end I have updated the image [1] in the commands explainer document to better facilitate conversation, and presented some new ideas below.


Previous Design (for context):
We had said that in order to change a default behavior for a keyboard shortcut, a site would intercept that shortcut's keyboard event, call preventDefault, and then call execCommand() with the new intention. For instance, to change control+b from bold to back-color, a site or framework could do this:

function handleKeydown(evt) {
if (evt.key == "b" && evt.ctrlKey) {
                document.execCommand('backcolor', false, 'blue'); // causes command event type backcolor
                evt.preventDefault; //stops default command event type bold
}

Declaring user intentions:
Instead of execCommand, we could find another way to declare user intentions (shown in the image [1] upper right). To change a keyboard shortcut we could have a new property, say KeyboardEvent.intention. It could be initialized if a CommandEvent would normally fire, like bold on control+b. And it could be modified like this:

function handleKeydown(evt) {
if (evt.key == "b" && evt.ctrlKey) {
                evt.intention='backcolor'; // causes command event type backcolor and stops default command event type bold

}

For buttons we could do the following, which would cause a CommandEvent to fire when the button is activated.

<input type="button" command="bold" value="b">

Another option would be a series of methods like those suggested previously [2], such as window.clipboard.copy causing a copy IntentionEvent (ClipboardEvent) and document.getSelection().modify causing a BeforeSelectionChange Intention event.


Using execCommand to actually execute a command:
This means execCommand is available for other uses. Since it's a legacy API that doesn't have the best shape, perhaps it is best to tie it to the legacy behavior. So the image [1] now shows that execCommand (lower right) would cause the browser to actually perform the command, not fire a CommandEvent. In effect, execCommand('bold') is the default behavior for CommandEvent type bold in contentEditable="true". In contentEditable="minimal" or equivalent, CommandEvent type bold has no default. If a site wishes to use the built-in bold, they can call execCommand('bold') in the CommandEvent, thereby restoring contentEditable="true" behavior for that specific command.

This further solves the problem of re-entrant commands. execCommand doesn't fire CommandEvents, so calling execCommand inside CommandEvent is fine.

Thoughts?

[1] http://w3c.github.io/editing-explainer/commands-explainer.html#overview
[2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0601.html

Ben
Received on Wednesday, 18 June 2014 01:09:28 UTC

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