Re: Proposal: extending LINK for more general controls
| From: |
Bert Bos <bert@let.rug.nl> |
| Date: |
Thu, 24 Aug 95 16:02:53 EDT |
Scott Preece writes:
|| From: Bert Bos <bert@let.rug.nl>
||
|| This is a suggestion for a change of terminology in HTML and for a
|| slightly different interpretation of the LINK element. In short: the
|| term `hyperlink' should be used more in accordance with existing
|| hyperlink literature and the LINK element should consistently result
|| in a button in a toolbar, independently of any REL attributes.
|---
|
|I'd like some clarification from the authors on exactly how this notion
|of using LINK to generate controls is supposed to work. Is the idea
|that the author can specify *any* REL value and the user agent should
|create a control (in whatever place it chooses to put document-generated
|controls), or is the notion that a user agent would have a pre-defined
|set of "common" relationships (like "home", "up", "back", etc.) for
|which it had standard control placements that a document could bind to?
Both, actually. There already seems to be consensus on this much:
there will be a set of reserved link types (including top, parent,
child, first, next, previous, made/author, and a few others) but any
user-defined name is acceptable as well. Murray Maloney has been
working on a such a (non-exclusive) list of predefined names.
|If the intention is the first case, then there is a usability problem in
|that there is no way to specify shortcuts for the document-provided
|controls, which most user interface people think is pretty important.
|Either the user agent would have to synthesize abbreviations (so the
|user would have to check to see what it came up with each time) or it
|would have to provide a prefix to be followed by an abbreviation
|specified by the document (in an attribute of LINK). And there's no way
|to allow the controls to mesh attactively with the built-in controls (no
|way to say which menu to add an item to), since the author doesn't know
|what built-in control organization will be present.
|
|The pre-defined set of relationships approach allows attractive
|integration of document-supplied controls with built-in controls, but it
|limits the scope of the facility.
|
|The draft specifies a set of relatioships reserved for the toolbar,
|which implies the latter interpretation, but it doesn't say whether
|those are the only links that can end up in the toolbar or not.
|
|Here's a proposal for extending this facility slightly:
|
|1. clarify that the set of relationships mentioned in the toolbar entity
|definition are only ones a user agent should integrate into its builtin
|control structure, and
|
|2. provide a new relationship "Control" to allow a document to export a
|more complex set of document-specific controls; LINKs with REL=CONTROL
|would take the attributes TITLE (to specify the displayed title of the
|control), HREF (the URI to be invoked when the control is activated),
|POSITION (a slash-separated hierarchical "path" locating the control
|in a hierarchy of document-provided controls - the user agent could
|choose to render the hierarchy in a variety of ways, so long as all
|controls with the same path are made visible simultaneously), ABBREV (a
|keyboard shortcut applicable when the control is visible and "active"),
|and ACCEL (a keyboard shortcut applicable following a user-agent-defined
|prefix for document-provided controls), and
|
|3. allow the LINK element with the CONTROL relationship or one of the
|toolbar relationships to appear in the BODY element, with two specific
|semantics: if the CLASS attribute is present the control is only
|available when the cursor is in a division naming that class or when all
|the currently displayed material is in such a division; if the new
|VISIBLE attribute is present, the control is only available when the
|point in the text at which the LINK appears is visible (if CLASS is also
|specified, *both* conditions must be met); the user agent would have the
|option of displaying the control only when it was available or could
|always display it, but use a "deactivated" rendering when it was
|inapplicable). This would allow the author to define a control with a
|semantic that was common to the whole document, but whose value changed
|with the presented context (like a MORE_INFORMATION control). If neither
|CLASS nor VISIBLE is specified, the default is the current division.
|
|I am not wedded to the use of REL=CONTROL as the specifier; I would
|actually prefer to remove this functionality from the LINK element,
|preserving it for expressing non-toolbar relationships with other
|documents, and add a new element named CONTROL for this purpose, but I
|know a lot of the work group are opposed to element proliferation...
Funny, I proposed exactly the opposite (which is also the same, in a
way...): reserve LINK for hyperlinks (to be presented as menu-items,
buttons, etc. in a typical graphical browser), and find some other
means for `non-toolbar' (rather `non-hyperlink') relations. I
suggested processing instructions and/or a separate file, since it's
usually inconvenient to have this info in an element.
|Examples:
|
|1. <LINK REL=UP HREF="...">
|would tell the user agent to bind the indicated URI to whatever
|builtin control it provides to offer the "up" function
|
|2. <LINK REL=UP HREF="..." CLASS=TABLE1>
|would tell the user agent that while it was displaying the indicated
|division of the document, it should bind its UP control to the
|given URI
|
|3. <LINK REL=CONTROL TITLE="Search" POSITION=Services HREF="...">
| <LINK REL=CONTROL TITLE="Explain" POSITION=Services HREF="...">
|would tell the user agent that to provide two controls, labeled
|"Search" and "Explain, presented together, whose actions are the
|indicated URIs
|
|4. <BODY> ...
| <DIV CLASS=Product.abc123>
| <LINK REL=CONTROL TITLE="Order" HREF="...">
| </DIV>
| <DIV CLASS=Product.def456>
| <LINK REL=CONTROL TITLE="Order" HREF="...">
| </DIV> ...
| </BODY>
|would tell the user agent that when the user is reading the description
|of product abc123 the Order control should do one thing, when she is
|reading the description of def456, it should do something else.
|
|For some user agent styles of presentation, using position is clearly
|ambiguous (it would not be, for instance, if the UA did pagination and
|always presented only material from a single division, or if the
|document controls were bound to a button-induced popup menu that
|inherently identified a particular location); the user agent could
|disambiguate by, for instance, offering the possible interpretations for
|the user to choose from or by temporarily rendering the borders of the
|divisions on the window and allowing the user to click in one.
|
|This proposal stems from some work I did once in designing a hypertext
|system that was never built; it provides services that significantly
|enhanced the utility of the system for the particular application I was
|aiming at. I think it's generally useful.
The ideas are very interesting, though I have to think about your
point 3: buttons that depend on a particular part of the document
being visible. I can think of a couple of applications, but for all of
those I think it's better that a style sheet rule specifies that a
particular link should behave as a `synchronizer link' (i.e., try to
keep the source visible if the target is, and vice versa). This
requires browsers with two or more panes, but you can already see the
start of that in Panorama.
POSITION can maybe be handled by REL itself, by using a dot or
allowing NAMES instead of NAME:
REL="services.search" or REL="services search"
REL="services.explain" or REL="services explain"
I strongly support the use of TITLE.
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,...
Bert
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN
Follow-ups