Re: Link style sheets [was REL and REV]

Craig Hubley (craig@passport.ca)
Fri, 12 May 95 14:41:55 EDT

> Yes. Craig, would you point us to a summary (or post one) so we
> can reorient?

Just did. I have (since posting it) accepted Dan's suggestion that,
since we are not standardizing what is at the other end of the link,
the URL might as well be a plain "HTTP://..." file retrieval that
the browser/server combination can interpret in an idiosyncratic way
(or this file can contain a simple list of 'standard' behaviors to invoke).
If necessary a "linkas:..." or "lookuplinkbehavior:..." or "hotjava:..."
URL can be defined later, and will define how a browser looks up functions.

This is not as good as a standard function-distribution mechanism (which
I have been trying to outline under separate cover, to deal with field-
and form-level validation) but much better than letting every browser
look up and interpret link behavior in its own way, with its own tags...!

> I believe Craig is proposing that one point off to link specs
> somewhere outside the HTML doc. That's fine with me, but it seems
> overly complex, and it may be confusing for users if one party's
> ABC-NEXT is different from another DEF-NEXT (they're both NEXT,

That's why you need a way to specify the default prefix, so that
ABC-NEXT can be distinguished from DEF-NEXT.

> so why should they differ?), or if I can redefine behavior

There are at least 3 definitions of 'NEXT':
1. the 'next' page in the author's intended sequence, (if any!)
2. the location, in the current page, just below the portion currently
visible in the browser's text pane
4. (after going 'back' to a previous page), the one I had gone to 'next'

> (TERRY-NEXT means PREV, for the document indicated by REV---

I have not discussed REV. To my knowledge SCO has not implemented it (?).

> Back to defining the semantics. These are semantics of browser
> behavior. I can't make my browser do something it can't do. What
> I really want is access to the browser's API, in which NEXT,
> PREV, and so on are standardized---outside HTML. Try thinking

YES. Absolutely. So how does HTML call out to an external function ?
Right now, there is no standard facility, and there are dozens of
places where there are hardcoded lists of attributes where a common
callout mechanism might be used (ACTION="function:...") ? This is like
the CGI-BIN mechanism except that the functionality can be shared across
servers and has the same name wherever it appears.

> So I think an I-D on functionality of browsers is in order, in
> which the behaviors they share in common are given standardized

There is a very clear list of functions that HTML requires that a
browser have implemented internally (e.g. show/work a radio-box-style
selection widget, show/work a pushbutton, 'goto' a given URL, etc.).

> labels. HTMLers could then use those labels as values for REL
> and REV, and for well behaved browsers they might even get
> results. Other behavior can be experimented with, then, too,
> without having to limit the values of REL and REV in the DTD.

As long as this list of function name space is clearly marked
as its own name space, so that I can say REL="function:next" and
ACTION="function:next" and know that I am calling the same function.

> There may also be value in pointing off to link specs, but
> that may just be a different issue.

It is. Access to functions implemented *inside the browser* ought
to be a priority. Access to those shared externally will be a logical
extension.

-- 
Craig Hubley                Business that runs on knowledge
Craig Hubley & Associates   needs software that runs on the net
mailto:craig@hubley.com     416-778-6136    416-778-1965 FAX
Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5