- 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