Re: Proposal: extending LINK for more general controls

   From: murray.altheim@nttc.edu (Murray Altheim)

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

ALT would be OK.

---

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

Well, this is an instance where the author is providing an input
structure (controls the user can select) as well as an output structure.
Again, naming the controls (both the full name and the mnemonic), for
controls other than the pre-defined set, is something that *cannot* be
done mechanically by the browser.

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

Note that part of my proposal was to allow LINKs with the CONTROL
relationship in the body, specifically so that controls with bounded
scope (rather than document scope) could be provided.

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

My proposal was specifically to define a standard set and also allow for
a document-defined set that would have a distinguished, hierarchical
namespace.

I support your suggestion that authors be allowed to provide either text
or IMG forms for the pre-defined LINK controls, as well as for
document-specified controls.

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

I don't think this is a 2.0 issue, unless pre-defined relationships were
going to go into 2.0.

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