Re: Keyboard control extensions to HTML

alex@activevoice.com wrote:
> 
> 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.

Indeed! And that is *the whole point* of HTML. It doesn't provide
a user interface which is "the same for every user, and depends
on whatever document viewed", but a user interface which is
"defined by the *user* taking her wishes and needs into account".
Usually, this means the user gets a consistant interface, no matter
which document is viewed, and it's the user which defines the
interface. 

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

Cool, isn't? "In many user interfaces, the user can press F1".
Why do you think there are many user interfaces using F1? To
give the user a consistant interface. It is not F1 now, and h
on the next program, and a mouse click on another. But what
happens if the user doesn't have a F1 key? Or has F1 mapped to
close the window? Or even doesn't have a keyboard?

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

I would remove any browser that allows an author to remap my keyboard!
*I* decide how the keys are bound, not someone else! Far, far, far
better would be:
<LINK REL = "help" HREF = "http-to-help">
and have to user define how to get help. F1, h or clicking on the
help button that pops up on the browser when loading a page with help.
BTW, I already have a button labelled "Help" on my keyboard, why
would I want to use F1?

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

Cool. So, if I want to type in my name (which I have mapped to AltX key)
I suddenly submit the form? Or maybe someone *wants* to include
AltX in an element.


[ Snip ]

> 
> 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 browser function: it should do what *I* want, and
what I always want it to do, I don't want to have to learn my
browser on every new document I load.


Abigail

Received on Wednesday, 10 July 1996 12:36:03 UTC