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
that.
> > 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 mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5