I agree completely. Note how my list of *suggested* rel/rev values
was very short. Consensus on reasonable values is important. ;-)
> >
> > * 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.
Yes, exactly. The stylesheets concepts seem suitably distinct from
REL/REV that it would be useful to formally separate them. Then we
can get back to REL/REV as document-document relations, as distinct from
document-stylesheet ones.
For example <A REL=stylesheet...> ... makes sense in some contexts:
the use you describe above seems plausible. But -- this is
distinctly different from the idea of linking to a stylesheet that
is to be *used* as a document stylesheet.
My idea of stylesheets is: if the document author has
designed them to be used in a particular way, this should be reflected
in how they can be loaded into the browser (thus my 'overload/replace'
thoughts.
This does *not* mean that I think the author should be able override the
browsers preferences -- as you say, the browser should always have the
final word (unless, of course, your name is Mozilla....)
> >
> > 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.
Yes. Or perhaps better, as hints to the browser as to desirable consequences
(which, again, can be overridden by the browser).
> >
> > 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.
Yes I agree.
> >
> > 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.
Agreed. I used the tileing as a simple example to illustrate the
point. Clearly text or non-text, screen-reader or braille (or
??) browsers would have to do this differently.
>
> 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.
That's also possible, although if the meaning of a REL is generic,
it would be best for the browser to override the TITLE value with
some local customization.
>
> > 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.
This is a good point. I would then consider (as I mentioned above)
ACT values should be considered as hints, which can be overridden
or ignnored by the browser.
> >
> > 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.
Everybody loves those X- things. There must be a reason.
> >
> > 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