Re: Keyboard control extensions to HTML

Thanks to everyone who responded to my original message.


1)

Several responses were of this sort:

    "I don't *want* you to remap keys that are already used by
the browser."

I agree, of course.  In fact I don't want a general purpose brows
er running on my PC to let the HTML remap keys *not* used by the
browser!  Well, maaaaybe, with the possible exception of
pre-defined "logical" keys - like HTML_ITEM_HELP or some-such.  

But if the "browser's" screen is on a hand-held, combination micr
owave-oven-and-foot-massager bought at the local Electronics-R-Us
, then remapping the keypad makes a lot of sense.  On such a
device, the KEYSTROKE KEY names would probably be the actual
"scan code" of the key-pad switches!


2)

Ouch! The suggestion that LINK might be used instead of KEYSTROKE
caught me un-awares.  So I read a copy of "draft-ietf-html-relrev
-00.txt" and found much of how-KEYSTROKE-can-be-used to be
considered in the proposals for LINK.  LINK, though, seems to be:

    1) at a bit higher level than KEYSTROKE - more concerned
about logical relationships and inter-page navigation than is
KEYSTROKE.  If I had implemented LINK in the browser, I
personally would be inclined to NAME a LINK and then to
<KEYSTROKE KEY=xxx HREF=##name> it.  (##name, again, has the
effect of "clicking" the NAME'd element.)

    2) page-wide in scope.  LINK, apparently, goes only under
<HEAD>.  Focus navigation keys and context-sensitive help keys,
for instance, need to be redefined differently all over the HTML.

    3) obfuscating.  For instance, if link were to be overloaded
to the extent of defining a special key's action while the user
is currently "focused" on one, particular OPTION, then it might
be hard to maintain the HTML "source" for a large "system" of
HTML.  If KEY were an attribute of LINK, that might not be so
true, though, 'eh?  (By the way, OPTION does not take an HREF
attribute!?! That seems limiting-for-no-reason.  My son, when he
was writing HTML test files, assumed that OPTION:HREF would work.
 Hmmmm.  Well, this is not to say that a 14 year old boy's expect
ations define what is "intuitive," but...)


3)

Dan, thanks for the mention of LABEL:ACCESSKEY. I like it a lot. 
From a HTML writer point of view:

<INPUT TYPE=RADIO .... NAME=i1>
  <LABEL ACCESSKEY=U HREF=#i1>
  Up the creek.

seems much nicer than:

<KEYSTROKE KEY=U HREF=##i1 >
<KEYSTROKE KEY=u HREF=##i1 >
<INPUT TYPE=RADIO .... NAME=i1>
<DOITKEY>U</DOITKEY>p the creek.

or some-such.  Of course, as a browser writer, I'ld rather build
the second!  For one thing, I wouldn't look forward to having a
list of expected characters, the ACCESSKEY's, to look for while
I'm rolling through the HTML.



4)

Java and style-sheets:

Are irrelavent for my particular task.

There are few Java interpreters that run in a PharLap286 Dos Exte
nder environment and that take a memory footprint of negative 100
K (which is how much more memory my browser takes than the
original design-target).

Style-sheets work out the same way.  The browser necessarily has
an HTML parser and data structures that handle the results of
that parser.  To add style-sheets adds code.  In fact, this
browser reads an .INI file at start-up to get system-wide
KEYSTROKE definitions.  And the web "server" does "include" files
(optionally, inside "if" logic) at page-load time.  So, the
bottom line is: if it can be written in HTML-eze, there is no
call for another language.


But, outside of this particular system:


Java, or rather, scripting, might be a way of implementing the
functions of KEYSTROKE:KEY inside a browser that the HTML author
does not control.  That all depends upon whether the browser's
script language(s) have the power to do what is needed. 
Certainly, at design-time on this particular system, "Java" was
the answer to a lot of hard questions that began, "Using
Netscape, how will we ...?"

But scripting languages will proliferate, and HTML will grow to
overlap them <OPINION> for the next couple hundred years, minimum
. </OPINION>

So whether scripting languages have the power to do KEYSTROKE:KEY
- and more - shouldn't stop KEYSTROKE:KEY from being part of
HTML.


Ditto for style sheets. <OPINION>Personally, I kind of chuckle at
the idea of style sheets.  Mark-up for HTML?  Or should I say,
"mark-up for the HTML mark-up language?"  But, as a C guy, I sure
like their look. HTML looks <FLAME> like a stodgy, bureaucratic
mainframer's idea of what will keep him oinking at the government
trough for the maximum amount of time</FLAME>
<NOFLAME>ugly</NOFLAME>. &smiley;
</OPINION>

So thank you all for the advice and comments.

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 Friday, 12 July 1996 21:17:51 UTC