[css3-ui] 'key-equivalent' comments

Following are substantive comments on the 'key-equivalent' property and 
its definition in section 8.2.1 of the Working Draft of "CSS3 Basic 
User Interface Module", dated 3 July 2003 
(<http://www.w3.org/TR/2003/WD-css3-ui-20030703#key-equivalent>). I 
preemptively acknowledge the deadline for comments of 31 July 2003. To 
a large degree and for private reasons my tardiness was unavoidable. I 
humbly request that www-style readers, especially Tantek, consider my 
comments.


"Value: none | (<key-press-combination> )+ | <system-key-equivalent> | 
list-item-marker | inherit"

"(<key-press-combination> )+
"One or more <key-press-combination>s separated by spaces."

According to the CSS3 syntax draft [SYN], square brackets represent 
grouping. Parentheses are not mentioned in the syntax draft. However, 
we already have a precedent, the form attr(<attribute>), where the 
parentheses are literal. Rather than replace the parentheses in the 
'key-equivalent' definition with brackets, simply remove them:

<key-press-combination>+


"<key-press-combination> = <key> ('-' <key>)*"

Here square brackets should replace the parentheses to indicate 
grouping in the established CSS property-definition notation.

The use of the hyphen-minus ("-", U+002D, informally "dash") as a 
separator character raises problems. This use prevents the inclusion of 
a hyphen-minus in key names, so we get, for example, 'phoneend' instead 
of 'phone-end'. And how do we represent the hyphen-minus as a key in 
its own right, rather than as a separator? Do we escape it, as in what 
follows?

cmd-\-;

That requires parsers to distinguish between forms that are equivalent 
in all other cases. To address this problem, we could introduce a 
keyword for the hyphen-minus, something like 'dash':

cmd-dash;

We also have the issue of distinguishing special keys (cmd, opt, ctrl, 
and so on) from "normal" keys (A, B, C, and so on). The current 
approach, "Each [normal-key] character must be specified in uppercase 
or as an escaped character", is fragile and likely to be ignored by 
authors. And function keys (F1..F15) are typically identified with 
upper-case "F", yes? Let's make use of the lexical types available in 
CSS and define a normal key specification as a string:

<key> = space | <normal-key> | <special-key> | attr(<attribute>)
<normal-key> = <string>
...

(Are there keyboards which yield more than one character per keystroke? 
The string syntax would have an advantage in clearly representing those 
keys.)


The <system-key-equivalent> and 'list-item-marker' values should be 
allowed like <key-press-combination>. For example, it should be legal 
to declare

key-equivalent: system-cancel cmd-\.;

This provides a useful backup when a user agent's system has no 
convention for the <system-key-equivalent>.

In fact, we should allow <system-key-equivalent> and 'list-item-marker' 
like <key>. This allowance would require a revision of the use of 
hyphen-minus as a separator. Imagine for a moment that the new 
separator is a plus sign; it should be legal to declare

key-equivalent: shift+system-save;

Tantek rejected the plus sign based on the legacy of the hyphen-minus 
(also called "dash") [KSPS]. I acknowledge and respect that legacy. The 
convention of human-interface literature, however, is not a universal 
convention in deployed applications or in casual usage. Even Apple, 
whose human-interface guidelines Tantek cited, does not use the 
hyphen-minus as a separator. (Mac OS 9 and Mac OS X don't use a 
separator at all.) Anecdotally, I can attest that the plus sign as a 
separator is common. I was just using Microsoft Excel 2001 for Mac OS; 
during an operation it displayed "Press command+. to cancel". (The 
words are paraphrased, but the plus sign is transcribed directly.)

There are several factors to consider. How well does the new syntax fit 
with existing practice from outside of CSS? How well does the new 
syntax fit with existing and emerging CSS? How easy is interpreting the 
new syntax? How easy is misinterpreting the new syntax?

The plus sign fits well with some existing practice from outside of CSS 
and fits poorly with some other existing practice. The plus sign fits 
perfectly with existing and emerging CSS. It is quite easy to interpret 
the plus sign. It is difficult to misinterpret the plus sign.

Given these factors, the plus sign is a good choice.

Using a plus sign (or anything other than hyphen-minus) allows the 
hyphen-minus in key names. So:
accesskey becomes access-key,
namemenu becomes name-menu,
volumeup becomes volume-up
volumedown becomes volume-down
phoneend becomes phone-end
phonesend becomes phone-send
phoneaccept becomes phone-accept
todo becomes to-do.

Another syntax that avoids the hyphen-minus as separator is to 
parenthesize key press combinations:

Value: none | <key-press-combination>+ | inherit

<key-press-combination> = <key> | (<key>+)

This yields declarations like the following.

key-equivalent: system-cancel (cmd ".");
key-equivalent: (shift system-save);
key-equivalent: space;
key-equivalent: (opt down) space pgdn;

I previously suggested a syntax [UIC] using commas as separators 
between <key-press-combination> and space between <key>:

Value: none | <key-press-combination> [, <key-press-combination>]+ | 
inherit

<key-press-combination> = <key>+

This yields declarations like the following.

key-equivalent: system-cancel, cmd ".";
key-equivalent: shift system-save;
key-equivalent: space;
key-equivalent: opt down, space, pgdn;

Maybe the best syntax of all uses commas as separators between 
<key-press-combination> and plus sign between <key>:

Value: none | <key-press-combination> [, <key-press-combination>]+ | 
inherit

<key-press-combination> = <key> ['+' <key>]*

This yields declarations like the following.

key-equivalent: system-cancel, cmd + ".";
key-equivalent: shift + system-save;
key-equivalent: space;
key-equivalent: opt + down, space, pgdn;


A summary of suggested changes follows.

Value: none | <key-press-combination>+ | inherit

<key-press-combination> = <key> ['+' <key>]*
<key> = space | <normal-key> | <special-key> | attr(<attribute>)
         | <system-key> | list-item-marker
<normal-key> = <string>
<special-key> = <modifier-key> | <function-key> | <navigation-key>
         | <edit-key> | <misc-key> | <volume-control-key>
         | <phone-key> | <application-key>
<modifier-key> = access-key | <cmd-key> | <opt-key> | <ctrl-key>
         | <shift-key> | <alt-key> | <win-key> | <meta-key> | fn | fcn | 
caps
<cmd-key> = cmd | rcmd | lcmd
<opt-key> = opt | ropt | lopt
<ctrl-key> = ctrl | rctrl | lctrl
<shift-key> = shift | rshift | lshift
<alt-key> = alt | ralt | lalt
<win-key> = win | rwin | lwin
<meta-key> = meta | rmeta | lmeta
<function-key> = F1 | F2 | F3 | F4 | F5 | F6 | F7 | F8 | F9
         | F10 | F11 | F12 | F13 | F14 | F15
<navigation-key> = tab | esc | enter | return | menu | help
         | name-menu | rcl | snd | <arrow-key> | <page-key>
<arrow-key> = up | down | left | right
<page-key> = home | end | pgup | pgdn
<edit-key> = bs | del | ins | undo | cut | copy | paste | clr | sto
<misc-key> = prtsc | sysrq | scrlock | pause | brk | numlock | pwr
<volume-control-key> = volume-up | volume-down
<phone-key> = phone-end | phone-send | phone-accept
<application-key> = memo | to-do | calendar | mail | address
<attribute> = <identifier>
<system-key> = system-new | system-open | system-close
                 | system-save | system-print
         | system-quit | system-terminate-operation
         | system-undo | system-redo
         | system-cut | system-copy | system-paste
                 | system-clear | system-duplicate
         | system-select-all | system-find | system-find-again
                 | system-ok | system-cancel | system-apply



- - - References - - -

[SYN]
L. David Baron (editor).
"Value", section 10.1 in "CSS3 module: Syntax".
13 August 2003.
W3C Working Draft.
<http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#property-def-value>.

[KSPS]
Tantek Çelik.
"Re: [css3-ui] Last? Call".
11 July 2003.
Message to <mailto:www-style@w3.org>.
<mid:BB344AF4.2AACC%25tantek@cs.stanford.edu> /
<http://lists.w3.org/Archives/Public/www-style/2003Jul/0137.html>.

"User interface / human interface literature has used the dash '-' as 
the separator character in this context consistently throughout history 
and therefore we have adopted the same industry convention rather than 
invent a new one."

[UIC]
Etan Wexler.
"WD-css3-ui-20020802 comments".
7 October 2002.
Message to <mailto:www-style@w3.org>.
<mid:comments-WD-css3-ui-20020802@d20021007.etan.wexler> /
<http://lists.w3.org/Archives/Public/www-style/2002Oct/0013.html>.

Received on Tuesday, 23 September 2003 08:51:17 UTC