Re: Keyboard control extensions to HTML

Arnoud (galactus@stack.urc.tue.nl)
Wed, 10 Jul 1996 11:05:16 +0200


From: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet)
To: www-html@w3.org
Subject: Re: Keyboard control extensions to HTML
Date: Wed, 10 Jul 1996 11:05:16 +0200
Message-ID: <MJ34x4uYOhKT089yn@stack.urc.tue.nl>

-----BEGIN PGP SIGNED MESSAGE-----

In article <1e3122c0@activevoice.com>,
alex@activevoice.com wrote:
> 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

Well, not all browsers support keyboards, and those keyboards may not
always have an F1 key. So why not simply define a "help" link, which
the browser maps to the commonly used help key/button on that system?

<LINK REV="help" HREF="help.html">

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

What if the Alt-X key is mapped to something else? On NCSA Telnet, for
example, Alt-X means "close the current session". If I were using your
client over a telnet connection, I wouldn't be able to use these keys
to submit the form.

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

Oh joy. So now the HTML authors get to mess with my keyboard as well?
I don't *want* you to remap keys that are already used by the browser.
When I press Alt-P, I expect to go back in my history and nothing else.

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

My main objection is that an HTML author cannot know what keys are
available for his document. He might override common keys on some
other platform, or define keys which are not even available.

> 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

Why? What has the server to do with my keyboard?

It seems more sensible to me that the extensions you propose focus
more on *purpose* rather than explicit keys. The LINK element already
has several proposed uses (see the old HTML 3 draft), and the REL and
REV attributes listed in there can also be applied to A right now.
We could even extend this to having REL and REV on *all* tags, so
you can do almost everything you propose, withour risking doing nasty
things with a keyboard.

Galactus

- -- 
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: <http://www.stack.urc.tue.nl/~galactus/remailers/>


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850

iQCVAgUBMeN1KzyeOyxBaho1AQHZ9gQAk02B9km0zgqPlQfb6jVUbAUeVaMJim7T
oE08yKg4RHmYm5nGoLJIghztCjt0GnwE4iSziy+ARZ5MiqwLClA+gLzJzBCFRw0W
PQakdG0r/KpM8HoQhfcNXG3HnsEWKg0L4cRfsnE6ZEswSMPghJIYlwN8RPtT9I8z
PSQQh64EM9U=
=b26w
-----END PGP SIGNATURE-----