W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: Breadcrumbs (and some ideas on how to)

From: Charles McCathieNevile <charles@sidar.org>
Date: Wed, 04 Aug 2004 03:48:22 +0300
To: "Dennison, Sharon" <Sharon.Dennison@ato.gov.au>, w3c-wai-ig@w3.org
Cc: "Dan Brickley" <danbri@w3.org>
Message-ID: <opsb6pywnvw5l938@widsith.local>

On Wed, 4 Aug 2004 11:10:10 +1000, Dennison, Sharon  
<Sharon.Dennison@ato.gov.au> wrote:

> DP >sheesh, Why not just show us only the content of the page we are on
> and we wouldn't need to know where we've been or where we need to go
> next.<

> While this statement makes good sense when viewing content which you
> have navigated to youself, breadcrumbs prove particularly useful when
> users have been linked through to lower level pages of a site when
> coming from another site or search engine page.

As an example, consider being on a random page in the W3C website  
(something I believe many people on this list have done). It is sometimes  
more or less impossible to get from there to anywhere useful except  
perhaps the W3C home page. So getting to a related place might take 4 or  
five steps - a relatively large cognitive load.

One way to do this that would allow user agents to figure out the best  
treatment for their users is t use the link element. Unfortunately there  
aren't a lot of helpful things. You could take one of two paths:

Use HTML as specified -

<link rev="section" href="myparent" title="immmediate parent document of  
this one" />
<link rev="subsection" href="myGparent" title="grandparent document of  
this one" />
<link rel="start" href="home" title="home page for this breadcrumb trail"  

This gives you a structure like

  Home .... > grandparent > parent > here

limiting the number of elements in the trail is probably not a bad thing.  
Plus they can be shown by the user agent in an unobtrusive but easily  
activated way (see what Opera, Mozilla, iCab, etc do with link elements).  
On the other hand, this is my interpretation of the meaning of the values  
defined when specified as part of the (not widely used) rev attribute. I  
believe it is correct, but I haven't spent hours pondering the logic.

Note that you could put the rev attributes onto ordinary a elements in the  
page, too, and they should work the same. (In practice I am not so  
confident they will...)

The alternative is to use the profile attribute to define more link types:

Authors may wish to define additional link types not described in this  
specification. If they do so, they should use a profile to cite the  
conventions used to define the link types. Please see the profile  
attribute of the HEAD element for more details.
]] - http://www.w3.org/TR/REC-html40/types.html#type-links

If you are doing this then it makes sense to look at defining types which  
can be used for real site description - Dan Brickley's work on site  
mapping from many years ago is probably a good start if only I could find  
a reference to it...

The drawback is that you need a way of explaining to other systems what  
your values mean. (In my opinion that means you want to describe your  
vocabulary in RDF, since if you don't believe developers will read the  
spec you need something that can merge information across different  
vocabularies automatically, and if you do believe it then it makes sense  
to use the existing and widely read HTML spec...)



Charles McCathieNevile     charles@sidar.org
Fundación Sidar             http://www.sidar.org
Received on Tuesday, 3 August 2004 21:49:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:29 UTC