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

Re: [editing] Changing Default Intentions

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 20 Jun 2014 20:28:33 -0700
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <E04134D7-5B28-453E-A528-41A3E22A3B05@apple.com>
To: Ben Peters <Ben.Peters@microsoft.com>

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
Received on Saturday, 21 June 2014 03:29:20 UTC

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