LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives


HTML-WG Archives

HTML-WG Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave HTML-WG
Reply | Post New Message
Search Archives


Subject: Re: Our Friends REL and REV
From: Ian Graham <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Thu, 11 May 95 17:41:54 EDT
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (202 lines)



> 
> Ian Graam writes:
> > 
> > Observations --
> > 
> > * I believe that We are attempting, through the REL/REV attributes, 
> >   to define at least two distinct things:
> >            -  the *meaning* of the relationship, and 
> >            -  the desired *implementation* should that relationship 
> >               be accessed.  
> >   By the latter I mean what happens if a link is accessed. For example,
> >   should the target (a footnote) be popped up as a sidewindow, 
> >   overloaded on the current document, or loaded in as a replacement
> >   stylesheet?
> 
> 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. 

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



Back to: Top of Message | Previous Page | Main HTML-WG Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager