Re: Proposal: extending LINK for more general controls

   From: Bert Bos <bert@let.rug.nl>
|
| 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?
---

Well, yes.  That's what the pre-defined relationships are - cases where
conventions are already obvious.  Presumably, further experience will
show up additional common relationships.  Some of the relationships I
would expect to use, however, are quite document-specific and would not
be likely to turn into conventions.

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

I guess, thinking about it some more, that it would be acceptable to
have the mnemonic specified by a stylesheet (presumably the stylesheet
would associate the mnemonic with a particular LINK relationship).
It means adding some new properties to the stylesheet model.  You'd
probably want to add a "Controls model" to the stylesheet model and use
it to allow controlling things like placement, captioning, and
interaction of the user agent's controls (all of them - not just the
document-supplied ones) when displaying a document.

---
|
| 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
| already has:
---

It's not just a matter of number - if the attributes provide ways to do
certain things, people wanting to do those things will use those
attributes.

---
|
|   - REL
|   - REV (which I think is identical to REL, but not everyone agrees)
|   - URN (which is probably not going to be needed)
|   - TITLE
|   - METHODS (not used currently, but that might change)
|   - HREF
|
| Scott Preece suggests:
|
|   - POSITION (though I think this can be covered by REL)
---

I agree - I suggest formalizing the notion of hierarchically named
relationships, creating a pre-defined first-level name "control",  and
renaming the proposed pre-defined relationships to begin with that name
(so the pre-defined relationship "up" would be renamed "controls.up").
The pre-defined set should also include an value  ("controls.docprivate")
reserved for the root of a tree of controls specific to the document
(neither future versions of the standard nor vendor extensions would
ever pre-empt a name with that prefix) and a similarly protected root
for a tree of user-defined controls ("controls.private"), which the
user's stylesheet could instantiate.  This latter tree would allow the
user's stylesheet to define "super-hotlists" for common actions.

|   - ABBREV
|   - ACCEL (maybe ACCEL and ABBREV can be the same?)
---

The user interface world distinguishes between mnemonics that are
presented on a menu (and are only selectable when the menu is visible)
and mnemonics that are active all the time.  For instance, if you use
Netscape on UNIX, the entries on each menu have a distinguished letter
that you can use to select that item when the menu is open; some of the
entries also have ALT-letter sequences that can cause that action at any
time.  It's an important distinction.

---
|
| and even
|
|   - VISIBLE
|   - 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
| info.
---

I'm not sure why you suggest changing IFCLASS to CLASS - I meant it to
select a division of the document (as exposed by the CLASS attribute of
the DIV element).

I'd have to think about the synchronized panes idea.  Here's an example
of what I had in mind for CLASS - tagging specified text with multiple
hyperlinks of different kinds (for instance, tagging a reference to a
product with multiple links pointing to an order form, a detailed
description, a parts list, a product manager, etc.) and providing
multiple controls the reader can use to popup a list of those different
links with a convenient control (like the right mouse button or a
toolbar button).  VISIBLE would allow a similar capability, but showing
an aggregate list for all the items on screen (a glossary button, for
instance, offering links to definitions of all the defined terms
currently visible).

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com