Re: Proposal: extending LINK for more general controls
||Bert Bos <firstname.lastname@example.org>
||Fri, 25 Aug 95 10:55:44 EDT
Scott Preece writes:
| From: Bert Bos <email@example.com>
|| 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.
OK, so the browser is not required to use menmonics, but if it does,
it might as well try to use the ones supplied by the author. I can see
how that could enhance the usability of a document. E.g., it expresses
somewhat how important the author thinks a link is.
There is still the problem that two documents may use different
mnemonics for essentially the same controls. Do we just have to wait
for conventions to arise?
And, of course, an author normally wants a collection of documents to
use the same mnemonics, so maybe this is better handled with a style
sheet after all?
We must be careful that we don't add too many attributes. These things
are only useful if many authors take the trouble to fill them in. LINK
- REV (which I think is identical to REL, but not everyone agrees)
- URN (which is probably not going to be needed)
- METHODS (not used currently, but that might change)
Scott Preece suggests:
- POSITION (though I think this can be covered by REL)
- ACCEL (maybe ACCEL and ABBREV can be the same?)
- CLASS (better: IFCLASS)
My intuition says that the last two should be handled differently,
such as with synchronized panes in a multi-pane browser, under the
control of a style sheet, since it's presentational, not structural
|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.
Bert Bos Alfa-informatica
<firstname.lastname@example.org> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN