I believe that some of Us are trying to define those two things.
I think that's a mug's game. I'd like to do the former and make
some suggestions as to the latter. I think that it is important
that browser developers have the opportunity to exercise some
creativity on implementation issues. Most important is to be
clear about the goals of using each REL/REV value.
>
> * The use and behaviour of REL/REV are different when they are in a
> LINK in the head, or in an Anchor in the body. Does an anchor
> element referencing a stylesheet (REL=stylesheet) make sense?
> I don't think so....
This may be a very good point. But we ought not jump to hasty
conclusions. An anchor that provides access to your or my
<A REL=stylesheet HREF...> stylesheet </A> might be presented
in a stylesheet editor -- yes, I know that mime types and file
extensions will buy me the same thing, but I was just trying
to make a point.
>
>
> Ideas --
>
> Stylesheets would appear sufficiently distinct from ordinarly
> links that they should be given their own HEAD element.
> LINK is generally used to define relationships to information bearing
> on a document's *content*, whereas a stylesheet talks about how
> it *looks*. I suggest a new HEAD element for stylesheets,
> for example:
>
> <STYLESHEET LOAD="overload|replace..." URL="...">
>
> where LOAD specifies what to do with the new stylesheet
> (overload the existing one (do not erase non-conflicting
> definitions), replace the stylesheet (delete non-conflicting
> defninitions in the old stylesheet) etc.
DANGER! DANGER! You are suggesting that the author of a document
on the WWW should have some authority over my stylesheet! That
is something up with which I cannot put.
As far as the general idea goes. Seems plausible. I'd like
to see some debate on this idea, but it does allow work
on REL/REV to procede without consideration to stylesheets.
>
> For REL/REV, I suggest creating two attributes reflecting the
> two characteristics mentioned above. This is similar to Craig's
> idea, but separates the meanings into two distinct names. As an
> example I put forward:
>
> REL - for the meaning of the relationship
> ACT - the desired implementation by a browser.
I read this as: The list of actions which the author has indicated
as desirable consequences of encountering this link or anchor.
>
> The REL and REV values could have the values that have been floating
> about (LocalHome, Next, Previous, Author, ToC (a.k.a. Contents), and
> so on, while ACT would specify a desired action by the browser.
> Some examples might be:
>
> replace (browser replaces current document by link)
> popup (browser creates a small popup window for the
> linked document)
> new (browser forks a copy of itself, into which it
> loads the new document)
> split (browser splits the screen in two, putting the
> linked document in half the screen)
Again, so long as we only consider these as suggestions
by the document provider. We can't expect lynx or other
non-graphical browsers (yes, there are others) to perform
some of these actions. Even so, I think that it would be
very helpful to catalog the list of typical actions that
user agents might perform -- if only to allow us to speak
in a common language.
>
> How would this work in practice? Consider first LINK elements.
> A client reads the LINK REL/REV values and, if it understands these
> values, associates a predefined menu icon or character string with
> the LINK (this can be locale() specific). It then tiles the window
> with the relevant LINK buttons. If it does not understand the
> REL attribute it tiles a button using the REL value as a label.
OK, as long as we understand that some browsers may not tile
or even use menus. It might simply present a pseudo-menu
at the top of the page -- and it might even scroll out of view
as the page is scrolled.
Rather than using the REL value for button labels, we might
want to consider the TITLE attribute value. This is not
being used very widely yet, but it has many potential uses.
More on that later.
>
> The browser is configured to have a collection of default actions
> is should implement when an understood REL/REV link is accessed.
> Thus is might know that a LINK REL="footnotes> link should be popped
> up as a small window.. If the browser does not understand the REL/REV
> it should execute a default action (such as overloading the current
> document with the linked one).
In fact, the spec should indicate that there are certain prefered
default actions for each defined keyword, but declare that
this is in fact an implementation-defined characteristic.
Then we could make it a requirement that all user agents
document the behaviour of all such implementation-defined
characteristics -- this is how the ANSI C spec is written.
>
> If the browser understands the ACT attribute values, it implements
> the browser action specified by the ACT attribute, overriding any
> default actions assumed by the browser. IF it does not understand
> the ACT attribute value, it uses its own default actions.
I'm still not convinced that the author's suggestion should
take precedence over the browser's or the user's. This is
a matter which the user must decide and instruct the user agent
to behave according to whatever protocol suits them.
>
> Experimental REL/REV and ACT values can be defined by the prefix
> X-. Practice has shown that this method rarely results in conflicts
> between namespaces.
I'm not sure why the X- is needed. I think this needs a bit
of discussion.
>
> Non HTML Applications of REL --
>
> Although it would be nice to say that REL/REV have universal
> applicability. Is it not likely that many relationships will only
> have meanings in certain contexts? For example, REL="Index"
> does not have an obvious in a VRML scene.
>
Thank you for spending the time to gather your thoughts on this.
This has certainly helped me focus my thoughts.
Murray