Re: [editing] Changing Default Intentions

For overriding keyboard shortcut, how about exposing browser's key binding
map as API rather than handling keyboard event?
Example:
window.keymap['Ctrl+B'] = function() { document.execCommand('backcolor'); }

window.keymap also contains "accesskey". So, editor library can notify or
avoid overriding page defined shortcut
// This can be done by document.querySelectorAll(*[accesskey]) though.

-yosi



On Wed, Jun 18, 2014 at 10:08 AM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

>  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
>