Re: Proposal for Keyboard Shortcuts for HTML5

Hi Rob,

Thanks for the feedback.

On Sep 21, 2007, at 9:00 PM, Robert Burns wrote:

> Hi Maciej,
>
> On Sep 20, 2007, at 6:03 AM, Maciej Stachowiak wrote:

>> I have a proposal that I believe could provide a better solution:
>>
>> HTML5 introduces a new <command> element which allows commands to  
>> be defined in an abstract way that can be shared by multiple UI  
>> elements. It has a label attribute which can provide a label that  
>> can work reasonably well in a standalone context. It also defines  
>> ways that some other elements can act as commands.
>
> I think the Wiki proposal addresses much more of the shortcomings of  
> accesskey:[1]
>
> It's is not really clear what use case the command element  
> addresses. I think it has significant overlap with 'select',,  
> 'datalist',  and 'menu'. I don't think we should be adding so many  
> elements to the document conformance without thinking about the  
> severe overlap in their semantics and trying to make better sense  
> out of it. As for the proposed 'shortcutkey' attribute it might make  
> sense to add it to 'option', 'li' and others.

Just to be clear, command isn't something new that I'm proposing.  
HTML5 already proposes a command element, which represents an action  
that can be bound to UI controls. Many UI toolkits have a similar  
concept. I don't see how it has any overlap with 'select', 'datalist'  
or 'menu'; in fact, it is used to define the items in a menu. 'option'  
is different from 'command' because it defines a data item, not an  
action. Similarly, 'li' defines a list item, not an action.

>> I propose that the command element be given a new attribute,  
>> shortcutkey. The value is either empty or a space-separated list of  
>> characters. If the value is empty, the UA can assign any shortcut  
>> key combination it wants. If a list is provided, the UA should use  
>> that as a list of suggestions from most preferred to least  
>> preferred for a key that should be assigned, in possible  
>> combination with one or modifier keys. If none of the suggestions  
>> is available, the UA should assign a keyboard shortcut as if the  
>> value were empty.
>
> I think NCNames would be more appropriate for this. If we're going  
> to address the short-comings of accesskey, why not address as many  
> as we can.

Having names for keys that do not have an obvious single-character  
representation (like delete, arrow keys, home, end, function keys,  
etc) seems like a useful idea. However, I think that keys which  
normally type a character should get that character as an identifier.  
Thus, adding names for more additional keys could be a compatible  
extension to my proposal.

>> For traditional desktop UAs that they add a menu to their menu bar  
>> or a toolbar, with a name like "Commands", "Shortcuts", "Page  
>> Shortcuts" or similar, which includes the commands with their  
>> labels and the keyboard shortcuts assigned by the UA. Check or  
>> radio commands could create check or radio menu items.
>
> Again, I'm not sure why we need another separate element to create  
> menus, checkboxes and radio buttons (I guess the command element  
> also overlaps with the input element).

It's not new to my proposal, and is the same element used to define  
menu items in the current draft.

>> For mobile devices with only a numeric keypad available, they could  
>> assign 0-9, * and # to shortcuts in some order and optionally  
>> display a list of shortcuts with labels below the bottom of the page.
>
> Again, I think the NCName works better for this than using a  
> character data type.

I think it's fine to use a space-separated string of key names.

>> For devices with only touchscreen input and a virtual keyboard, it  
>> may make sense to have no interface at all for keyboard shortcuts  
>> since using a virtual keyboard is unlikely to be faster or easier  
>> than interacting with the page directly.
>>
>>
>> Example:
>>
>> A web mail client could include the following in the markup to  
>> support a keyboard shortcut for "compose new message":
>>
>> <command label="Compose New Message" shortcutkey="n 1">
>
> From this example, its not clear what the command element brings to  
> the situation. If compose new message were attached to a hyperlink,  
> then doesn't the hyperlink already define the command?

I think it would be ok to also support shorcutkey on <a> and <input>  
(these are also considered command-defining elements in addition to  
<command> in the current draft, see here: <http://www.whatwg.org/specs/web-apps/current-work/#commands 
 >.

>> This would request a combination with N or 1 in that preference  
>> order, which might be mapped to Cmd-Shift-N on the Mac browsers,  
>> (since Cmd-N is likely to be taken by the browser for New Window),  
>> Ctrl-Alt-N on Windows browsers, N on mobile devices with a full  
>> keyboard, and 1 on mobile devices with only a numeric keypad.
>>
>> If a Mac Browser were to have the suggested Page Shortcuts Menu, it  
>> might display "Compose New Message ^%N", where ^ and % are my  
>> representations of the up-arrow and cloverleaf characters that  
>> would actually be used to avoid sending non-ASCII email to the list.
>
> This is less related to the shortcut key proposal, but if authors  
> are looking to create a menu of shortcuts wouldn't the datalist or  
> select elements be a more appropriate place fro this attribute. That  
> would give authors complete control over the structure of their  
> shortcut menus and still allow the assignment of a shortcut key.

I considered suggesting a designated <menu> for this, but it seems  
like automatically gathering the commands with shortcuts defined is  
important, otherwise other keyboard shortcuts will remain  
undiscoverable.

>> Notes:
>>
>> - This is much closer than accesskey="" to the way keyboard  
>> shortcuts work in native desktop applications, a proven and  
>> effective model.
>
> Native desktop applications also allow the specification of modifier  
> keys. Also, I think we need to take into account the broad  
> environments that web applications have to run in and the wiki  
> proposal better addresses that.

The problem is that specifying the exact modifiers is more likely to  
be inappropriate for platforms other than the author's, and is more  
likely to conflict with UA bindings. I'm assuming that page-specific  
keyboard shortcuts are never allowed to override global keyboard  
shortcuts defined by the UA, and when a key is requested the UA will  
try to pick a set of modifiers to avoid colliding with existing  
shortcuts.

>> - The proposed model provides mode device-independence and  
>> discoverability than accesskey does, either as implemented today or  
>> in the best possible case in my opinion.
>
> If it still uses a character data type rather than a NCName, I think  
> its subject to many of the same limitations of the current accesskey  
> (and XHTML2's access@key).

I don't think the ability to specify a base key that doesn't generate  
a character is particularly essential, but I agree it would be an  
improvement. Still, the syntax should not be NCName because many  
useful characters are not allowed in NCNames. A space-separated list  
of tokens allows normal keys to be identified in a straightforward  
way, while still allowing for the possibility of multi-character  
identifiers for special keys.

Regards,
Maciej

Received on Saturday, 22 September 2007 05:40:12 UTC