- From: <alex@activevoice.com>
- Date: Tue, 9 Jul 1996 19:21:54 -0700
- To: www-html@w3.org
Subject: HTML extensions for keyboard control.
Under contract for a client, I have written a specialized
browser, This browser runs in a low-memory, keyboard-only
environment. It provides the user interface for a complex
computer system. The project had a very tight schedule.
Therefore, anything built was built very quickly.
A large part of this browser's job is to show FORM's and TABLE's
to the user and to send his input back to the host system. The
host system is connected to the browser through HTTP as if
through the internet, but, in fact, the server and browser are
linked together as one program.
Now, HTML and the Web have developed along several lines, none of
which seem aimed toward being used as a general purpose computer
system user interface. So this browser's use raises questions
that don't seem to be addressed yet in HTML.
For instance, what about context sensitive help? In many user
interfaces, the user can press F1 and get some explanation of the
field that his cursor is on. Such mechanisms are not defined in
the HTML world. It seems to me that this "F1" function is a
particular instance of a general problem. And so, what follows
below is a description of HTML extensions that allow for
keystroke control and single-key zaps to URL's, to FORM elements,
and to do other operations.
I would welcome suggestions for improvments or alternatives to
these extensions.
There are a couple of new tags, KEYBOARD and KEYSTROKE, and new
attributes, KEY and ISKEYOP:
<!-- Glom a bunch of keystrokes together. -->
<KEYBOARD ID="Keyboard Name-ID" >
<KEYSTROKE KEY="F1" HREF ="#local-name" >
<KEYSTROKE KEY="F2" HREF ="http://somewhere.htm" >
<KEYSTROKE KEY="F3" ISKEYOP="http://elsewhere.htm" >
</KEYBOARD>
Though KEYBOARD is a container for KEYSTROKE's, KEYSTROKE's do
not necessarily need to be contained inside the KEYBOARD element.
More on that subject below. And, below, an example of ISKEYOP
use will make clear why ISKEYOP, though mostly synonymous with
HREF (ACTION?), needs to exist.
There is a new attribute that may be put into any element tag.
KEYS="#Keyboard-ID"
This attribute would enable the given keyboard within the scope
of the element containing the attribute. The referenced
KEYBOARD, itself, may be located anywhere in the HTML "page."
Finally, in normal HTML, recall that a URL starting with one '#'
means: move the "focus" to the element with the given NAME or ID.
(And insure that it is on-screen, of course.) This browser
understands a URL that starts with two '#' characters ("##url")
to mean: find the element with the given NAME or ID and do it.
Presumably, (in unenhanced HTML) the element is a A, FORM,
INPUT:SUBMIT, CHECKBOX, RADIO, SUBMIT, or RESET.
Aside from its use in KEYSTROKE, the KEY attribute may be used
like this:
<FORM KEY=AltX ... >
While the user's focus (cursor) is on an element in the FORM, the
AltX key would "push" the submit button for the FORM.
Also, the KEY attribute may be used like this:
<DIV KEY=AltP ISKEYOP=http://somewhere.htm >
.
.
.
</DIV>
In this case, the attribute ISKEYOP could just as well be HREF
(ACTION?), but consider this example:
<A HREF=foo.htm
KEY= CtrlD ISKEYOP=bar.htm
>
Click here to go to foo.
Or press Control D to go to bar.
</A>
ISKEYOP is used to resolve the KEY's target when HREF is already
used for something else in the element.
To define a key that moves the user's "focus" to a UI/FORM
element, you might do something like this:
<KEYBOARD ID=xxx>
<KEYSTROKE KEY=AltS HREF=#submit-button" >
</KEYBOARD>
<FORM KEYS=#xxx ... >
<INPUT TYPE=SUBMIT ID="submit-button" >
.
.
.
</FORM>
To define a key that "pushes" the SUBMIT button, you would do
something like this (note the double hash, '##' in front of the
HREF URL):
<KEYBOARD ID=xxx >
<KEYSTROKE KEY=AltS HREF=##submit-button" >
</KEYBOARD>
<FORM KEYS=#xxx ... >
<INPUT TYPE=SUBMIT ID="submit-button" >
.
.
.
</FORM>
Or, as we find simpler in practice:
<FORM KEYS=#xxx ... >
<KEYSTROKE KEY=AltS HREF=##submit-button" >
<INPUT TYPE=SUBMIT ID="submit-button" >
.
.
.
</FORM>
Here are more examples of these HTML extensions:
<HTML KEYS=#GlobalKeys >
<HEAD>
<KEYBOARD ID=GlobalKeys >
<KEYSTROKE KEY=F1 HREF="help/toc.html" >
<KEYSTROKE KEY=UpArrow HREF="#LocalLabel" >
<KEYSTROKE KEY=RightClick HREF="who-knows" >
<!-- It seems better to allow the browser/system
to define the actual key names by function.
Here, for example, the browser's "help"
key is made to "click" on "help/toc.html".
-->
<KEYSTROKE KEY=Help HREF="help/toc.html" >
</KEYBOARD>
<KEYBOARD ID=pwkeys>
<!-- This example might be used for debugging.
When an element enables this keyboard, ALT P won't
do the html_back operation (which is what this
browser does with ALT P, by default) but rather
will do this KEYSTROKE's HREF.
"HREF=operation://..." is an example of how
this browser's abilities are exposed to HTML
as a URL. Many "operation://" functions are
very handy in pratice. -->
<KEYSTROKE KEY=AltP
HREF="operation://ShowPasswordInClear"
>
</KEYBOARD>
<KEYBOARD ID=WordStarDiamond >
<KEYSTROKE KEY=CtrlE HREF=UpArrow >
<KEYSTROKE KEY=CtrlX HREF=DownArrow >
<KEYSTROKE KEY=CtrlD HREF=RightArrow >
<KEYSTROKE KEY=CtrlS HREF=LeftArrow >
</KEYBOARD>
</HEAD>
<!-- Some of us have well-trained left hands! -->
<BODY KEYS=#WordStarDiamond >
<!-- Alt T does the double-# trick to execute the
NAME'ed / ID'ed element. -->
<KEYSTROKE KEY=AltT HREF=##timbucktoo >
<!-- Alt A does the HREF directly.
The "scope" of both of these keys is whichever
is first:
The next KEYSTROKE defining the same key.
Or:
The enclosing element (in this case BODY)
is ended.
-->
<KEYSTROKE KEY=AltA HREF="http://timbucktoo.com" >
<A NAME=timbucktoo
HREF="http://timbucktoo.com"
>
Press ALT T or ALT A to take the train to Kalamazoo.
</A>
</BODY>
</HTML>
With regard to browser function: the browser matches the user's
keystrokes against its list of given keystrokes from the inside
out. That is, first against KEY-ISKEYOP's and referencing KEYS's
in the element that has the "focus". Then, similarly, all the
way to the top, against parent element and older sibling
KEYSTROKE's.
With regard to KEY names: they must be case-disambiguated in
order to distinguish, for example, "A" from "a". We may assume
that they
include all HTML character entity names with or without the '&'
and ';' baggage. (e.g. KEY="tilde" or KEY="˜"). Other key
names encouraged by the syntax of KEY are:
"Comma" #44 ASCII comma.
"DoubleQuote" #34 ASCII double quote.
"SingleQuote" #39 ASCII single quote.
In practice, the browser also translates a large table of PC
key names (e.g. AltT, CtrlA, F10, UpArrow, etc.), mouse
"keystrokes" (e.g. LeftClick, MouseLeftUp, etc.), and translates
an extremely large table of program "operations" - as in
"operation://name_of_operation", or simply "name_of_operation".
Though more than fully implemented and successfully working, this
whole proposal is kind of half-baked. First, in this description,
I have probably left out some details, and certainly have not
gotten in to other, related abilities that are in this browser.
Some things that are not mentioned above:
1) What about macro keys? How might a KEYSTROKE : KEY call out
several other "keys," instead of mapping directly to one HREF?
This subject has been raised before in this mail-list in the
question of multiple HREF URL's.
2) Personally, I keep KEY's and KEYS's out of <P> and <BR>.
Keyboard extensions give lots of opportunity for horrendous HTML
to be written. Subscribers to this mail-list know that bad HTML
is endemic. There is no reason to add to it.
3) Might keystrokes want to be element-type specific?
e.g. the key, '?', when the focus is on any <A> in the page
might pop-up a particular HREF or menu.
4) Multiple keystrokes are often particular-element specific.
That is, the keystrokes are only active inside a particular
(small) element. For instance:
<KEYBOARD>
<KEYSTROKE KEY=UpArrow HREF="#what's really north" >
<KEYSTROKE KEY=DownArrow HREF="#what's really south" >
<A HREF="#somewhere" >
Click here to go somewhere.
Press Up Arrow to go north.
Press Down Arrow to go south.
</A>
</KEYBOARD>
That's tedious to write. Unfortunately, I can think of no
reasonable
alternative that allows multiple keys and HREF's inside one tag.
This example, by the way, hints at how KEYSTROKE, etc. may be
used to solve arrow-key navigation logic problems. But then,
arrow key navigation is another, rather interesting problem.
5) The tag, KEYBOARD, is not really needed. The no-op tag, SPAN,
would work just as well. And, in practice, FORM followed by the
relavent KEYSTROKEs works fine. But KEYBOARD adds nice
information to the HTML text and, in my opinion, new tags are
extremely cheap and should not be discouraged any more than we
might discourage teenagers from coining new words. Also,
server-side include files that contain instances of KEYBOARD's
can make administration and maintenance easier.
6) Consider that explicite navigation help is given for a UI
element. That is, the program's arrow-key navigation logic may
think that it is a wise idea to move from anchor 3 to anchor 2
when the user presses up-arrow, but the form designer knows that
the program is wrong. So the HTML will be given something like
this:
<KEYSTROKE KEY=uparrow HREF=#anchor1 >
<A NAME=anchor3 HREF=dada >
Press Up-Arrow to move to anchor 1.
</A>
Now, what happens when the anchor spans multiple lines like this
(please turn your internal error checker off):
<PRE>
Some nice, wide text .... <A ... >ta da
la la
de da de da
</A>
</PRE>
I figure, "tough. The page designer deserves the results." If
the anchor is known to span lines and where, he can use multiple
identically-targetted anchors. If not, live with it. But maybe
there is a better way?
7) If you stare at this proposal, you will be blinded by the
glaring security and usability issues. We are all aware of
dangers inherent in remapping a user's keyboard on the fly. In
particular, for the application this browser is used for, the
HREF's can be pretty darned smart.
Too smart.
Program "operations" include logging out, turning on and off the
screen saver, turning on and off various debugging tools and
dumps, running regression test keyboard script files, etc. etc.
As long as this browser is hard-wired to the server, being too
smart is not a problem. Down the road, though, it will talk to
the server through the Internet. Which means that it can talk to
other, malicious servers. What horrors that raises! To this I
wave my hands and mumble something about reverse authorization.
That is, for the KEYBOARD and KEY mechanisms to have any effect,
the server would need to send, in its HTTP response, some proof
that it is able to control the user's keyboard. Of course, one
wrinkle in this thinking is that it's not the keyboard
enhancements that are at the core of the security problem, but
rather the browser's extended HREF interpretations. Oh well,
maybe my customer will contract me in the future to fix it ;-)
...
Thank you for your attention. To this browser, we have added
HTML extensions for the "FOCUS" and for better control of FORM
data: when to forget the data, when to automatically send it,
etc. And
I've given some thought to pop-up menus and the like. If others
are interested in these things, or are building "browsers" for
similar applications, please let me know.
B. Alex Robinson
P.O. Box 911
Maple Valley, WA 98038
(206) 441-4700 x183
(206) 432-3532
arobinson@avoice.com
71535.1673@compuserve.com
-eom-
Received on Tuesday, 9 July 1996 22:10:53 UTC