Re: [editing] Changing Default Intentions

On Jun 17, 2014, at 6:08 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:
> 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
>                
> }

This design might pose an issue in WebKit if the intention is supposed to return the corresponding editing behavior on getting because we wouldn't know it for a given key event until the default event handler is called.

Maybe we can add a method instead? e.g. event.setExecCommand();

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

execCommand not triggering command event seems like a promising approach.  I think we really need a concrete list of use cases here though.  It's hard to design & evaluate proposals without having a list of concrete use cases against which we're evaluating proposals.

- R. Niwa