Re: Link style sheets

Craig Hubley (
Sun, 14 May 95 08:46:25 EDT

> > Terry Allen ( said:
> >
> > <!-- <LINK HREF="..."> Address of link destination -->
> > <!-- <LINK URN="..."> Lasting name of destination -->
> > <!-- <LINK REL=...> Relationship to destination -->
> > <!-- <LINK REV=...> Relationship of destination to this -->
> > <!-- <LINK TITLE="..."> Title of destination (advisory) -->
> > <!-- <LINK METHODS="..."> Operations allowed (advisory) -->

Ian Graham writes:
> This is prettly what I suggested in my last letter -- split the problem
> in two: REL/REV to define the relationships, and METHODS (I called it
> ACT, but what the hey) to define the operations that can/might be
> implemented by the browser.

Good, definitely helps to split the function name and 'relationship' names.
That way you can call the relationship "Next Page" and the function "next",
call the relationship "cites" and the function "goto" (the default), the
relationship "sidebar" and the function "footnote", the relationship "au
gratin" and the function "addcheese" (consistent with our previous example).

SCO's next, previous, etc, *are* the operations implemented by the browser.
I left REL as the function name simply to stay compatible with SCO's current
usage, and Tim's original scheme. In your scheme they're actually METHODS
that happen to provide reasonable (in English) default relationship names.

METHODS is OK, but since ACTION=... is how forms designate processing, I'd
like to request that we use the ACTION attribute, consistently across tags,
to store names of functions that get invoked when someone activates the tag.

This seems like a small thing but if an author knows that in every tag that
might potentially invoke a nonstandard behavior he will find the attribute
ACTION... debugging gets a little simpler.

> > given the above, one can already point to a style sheet for links with
> > <LINK HREF="..." REL="linkstylesheet"> where "linkstylesheet"
> > would need to be standardized. But that's the rub. And Craig's
> > proposal rests on standardizing a syntax within attribute values,
> > one which can't be checked by SGML parsing.

True. But then SGML parsing can't verify URI validity, or correct syntax
of cgi-bin script names, and those are not problems.

> I agree completely, and said something similar in a previous letter.
> Stylesheets are very different from LINKed resources. Stylesheets
> define a document's presentation, and are really a 'part' of the document\
> itself. LINK, on the other hand, can define things like related

So the fact that a 'glossary' entry is presented as a sidebar to the text,
while a 'footnote' is presented as a small floating window, is defined in
the stylesheet ?

> indexes, glossaries, documents, and so on, which has nothing to do
> with stylesheets. The two concepts mix badly, which might explain
> some of the problems we've been having.

The fact that a glossary, index, table of contents, next page, etc., exist
is defined by the style. How they are to be presented is a question up to
the author as much as possible, and up to the browser's limitations after

> > In HTML, it is appropriate to agree on common values for the
> > core functions already implemented. Let's do that for REL, and
> > if we want to point to something that explains link semantics,
> > define a new element.

As long as it's clear that 'next' is an abbreviation for 'html3/next'
when it appears in an HTML3 document, and that this designates a fn
that is implemented in the browser, and that any other value is legal
and behavior will default to 'goto', and that browser implementors,
especially those that include a mechanism to patch in functions/applets
defined elsewhere, are requested to preface proprietary link names with
some consistent name such as 'hotjavacoollinks3.3/waycoollinktransition',
I can live with this.

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