- From: <Jukka.Korpela@hut.fi>
- Date: Thu, 9 Dec 1999 02:41:51 -0500 (EST)
- To: www-html@W3.org
On 8 Dec 1999 rev-bob@gotc.com wrote:
> > It is quite popular and very useful to show the hierarchy of the site on
> > the top of the pages. Something like this:
> >
> > corporation > company > department > project > product
> >
> > with links to appropiate places. It would be nice to represent this
> > hierarchy with link elements instead.
>
> Why?
If you ask me, I'd say: to allow user agents set up user interfaces which
are suitable for the particular user environment and uniform across
documents. The hierarchy issue is a bit tricky. But in the <link>
approach, it could be handled by rel values like "up", "up2", "up3", etc.
> HTML is at least supposed to be a *semantic* language
Exactly. And the relationship between, say, a document and its successor
in a logical sequence of documents or its "parent" in a logical hierarchy
is semantic, or structural.
> introducing new tags just to get around the unwillingness of some people
> to provide proper navigation is a really *bad* idea.
We aren't actually discussing _new_ tags right now but modifying the
definition of <link> to make it (more) useful.
Providing "proper navigation", in the form a set of links, or a
navigational pulldown menu, or push buttons, or whatever, is currently
a matter of providing some very specific constructs. Its structural side
is now largely hidden since it must be intimately coupled with its
implementation.
The modification of <link> syntax and semantics discussed here would not
prevent from providing "proper navigation" in the current sense. In fact,
it would still be recommendable to provide it, for an unpredictable period
of time (i.e. until practically all user agents support the modified
<link>). But the <link> element would let authors provide a _more
structural_ alternative too.
In addition to allowing browsers to set up better user interfaces, that
alternative would make it possible to process webs of documents
programmatically, e.g. constructing visual presentations ("site maps"
of one kind) of sites simply by drawing a labeled graph based on the
<link> elements. They would probably be very useful for advanced
indexing robots and search engines too. These benefits could be achieved
with <link> as currently defined, but the current definition does not
let authors specify <link> relations as an alternative to explicit
navigation elements in the document body.
> Everything you want to do with this "extension" can be done perfectly well with the
> existing A element - just use that and be done with it.
OK, where shall I put my A elements? Into a table at the beginning of
document? At the end? Into a navigation frame? A combination of them?
Something else? Haven't you ever found yourself wondering _where_ a page
has its "navigation tools"? On the other hand, isn't it nice that the
browser has a "Back" button in the same position, no matter what page
you are viewing?
And how is an automatic analyzer assumed to guess what the A elements of
mine really mean?
> > I have not thought very much about the syntax, it is the concept I am
> > concerned about. Any thought?
>
> Yeah - I think the very fact that we're discussing "let's make a new tag for navigation"
> speaks for itself. Ridiculous.
Considering what the Subject line says, and what the discussion is
about, I'd say we aren't.
--
Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Received on Thursday, 9 December 1999 02:42:35 UTC