Re: Proposal: extending LINK for more general controls

From: murray.altheim@nttc.edu (Murray Altheim)
Date: Fri, 25 Aug 95 10:52:02 EDT

Scott Preece <preece@predator.urbana.mcd.mot.com> writes:
>   From: Bert Bos <bert@let.rug.nl>
>|
>| ACCEL and ABBREV are problematic. You don't know if the browser allows
>| accellerators, or, if it does, what key strokes are already taken
>| up. Besides, it has nothing to do with document structure, it's a
>| style issue (though a rather difficult one). I think I would prefer if
>| the browser reserved some keystrokes for the controls of known type
>| (REL=parent, REL=next, etc.) and simply numbered the rest 1, 2, 3,...
>---
>
>That's why I said the browser would be allowed to require a prefix
>before the author-specified accelerator.  The problem is that the
>browser has no way, in general, to generate meaningful mnemonics for the
>document-supplied controls.  So it's useful to let the author indicate
>mnemonics that make sense for the document and allow the browser to do
>something sensible with those mnemonics.  So, I *do* think it's an issue
>of document structure and not simply of style.  The document author is
>explicitly specifying the structure of a set of controls supporting the
>document; this is inherently an author-side activity.
>
>For example, if the browser
>provided a menu "Document Controls" which it used as the root for a set
>of cascading menus corresponding to the paths in the document-specified
>controls, and if the browser used escape-D as a prefix for controls
>located in the document menu, then if the author provided a Search
>control with the mnemonic "S", the browser could respond to escape-D-s
>by going to that control.
>
>Another browser might put the document controls in a floating pallette,
>using the mnemonics to label little buttons.
>
>A test-based browser might use the mnemonics to identify entries in a
>textual list of options.
>
>The browser is *not* required to provide the mnemonics, it is simply
>informed that they are a set of short identifiers for the
>document-supplied controls that made mnemonic sense to the author.

This sounds like a case for the Consistency Police (No, not me. I look
terrible in navy polyester). Why not follow the lead already out there on
IMG and use ALT? You could certainly use MNEMONIC or LABEL as well.

I don't know how this is a issue of document structure, however one looks
at it. Your message would seem to indicate that it's almost entirely an
issue of browser implementation: you mention browsers in each paragraph but
not once mention structural relationships. Your point seems to rest on:

>So it's useful to let the author indicate
>mnemonics that make sense for the document and allow the browser to do
>something sensible with those mnemonics.

LINKs are not part of the structure of the currently displayed document,
they  indicate a hyperlink relationship of an external resource to the
current document. The mnemonic identifiers for those links merely supply
the UA with a label for that relationship. Note that LINKs exist entirely
in the document HEAD and are not displayed _as part of the document_ at
all. Proposed uses include a button bar or separate windows; again browser
issues.

I like Bert's idea of *recommending* a standard set for the half dozen
respected relationships. Then it would make sense to specify an optional
attribute to allow document authors to create their own button labels
(which would override the defaults). I would think limiting the number of
characters in the mnemonic would be prudent. I could even imagine
specifying an IMG for the button.

But for the purposes of finalizing 2.0 I think most of this extended
discussion could be easily left for 2.x and 3.0. I'm trying to concentrate
on the 2.0 draft.

Murray

__________________________________________________________________
      Murray M. Altheim, Information Systems Analyst
      National Technology Transfer Center, Wheeling, West Virginia
      email: murray.altheim@nttc.edu
      www:   http://ogopogo.nttc.edu/people/maltheim/maltheim.html




Follow-ups