[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
ian at hixie.ch
Mon Dec 19 17:07:29 PST 2005
On Thu, 15 Dec 2005, Alexey Feldgendler wrote:
> In my opinion, there are two kinds of systematic navigation usually
> included on the pages of a site. I'll refer to them as "relative" and
> Relative navigation includes links to pages which bear a specific fixed
> relation to the current page. For example, it's common for a page to
> include a link to the "next" page. Following a relative link is like
> moving to an adjacent vertex in a graph, or resolving a relative
> pathname on a filesystem. The relative navigation is pretty decently
> covered with the <link> mechanism because there's not many possible
This is also covered by <a rel="">, by the way. (Indeed, <a rel> is
arguably better, since then UAs can highlight the link when you hit the
shortcut key for "next", which is considered good UI, iirc.)
> Absolute navigation includes links to fixed pages, the same on all pages
> of the site. Usually these are links to top-level sections and
> subsections thereof. Following an absolute link is like skipping to a
> fixed vertex in a graph, or resolving an absolute pathname on a
> filesystem. The absolute navigation is somewhat covered with the <link>
> mechanism (rel="toc", for example), but it's not enough because the
> fixed nodes referenced by absolute navigation is rarely described with
> specific roles like "TOC"; more often, these are just top-level sections
> of the site.
Like <link rel="section" title="Products" ...>?
> Currently, we have <link> which works great in browsers which understand it.
Which is roughly none of them.
> For those who don't, authors usually duplicate relative navigation in
> the page body. For absolute navigation, though, they have no choice
> because there is no appropriate mechanism similar to <link> to instruct
> browsers to include absolute navigation somewhere in its UI outside the
Realistically speaking, authors don't use <link> anyway, though, as mpt
> > My theory is that there is an inverse relationship between the level
> > of abstraction involved and the level of interest from authors. Site
> > maps in external files are a kind of abstraction beyond most authors.
> Why? Everyone puts CSS and JS in external files -- just to avoid
> repeating the same text on all or most pages of the site.
It's not the "external file" aspect that's the problem, it's the
abstraction of having the site description at all.
(CSS, by the way, is not used by "everyone". There are significant parts
of the Web that don't use CSS, or that use it at most in style=""
attributes, thus completely missing the point of CSS.)
> And, well, everyone puts links to top-level sections of the site on
> every page, which is actually repetition.
Server-side includes are often used to fix this -- maybe we should
consider ways to address this need rather than <link>, come to think of
it. Especially in conjunction with <a rel="">, this could indirectly solve
> Also many authors put links to subsections of the top-level sections,
> which is even more repetition. To avoid the repetition, some use
> external JS to generate the menus, with JS arrays actually describing
> the site map. It's an ad-hoc solution to the same problem (how to not
> write the site map on every page), it's effectively the same level of
> abstraction, and it's just worse because it's not semantic, requires
> programmatic evaluation of JS, and is not standardized.
It's less abstract as far as the authors are concerned, because to them
there is a direct relationship between the document.write() and what they
see on their screen, as opposed to an indirect one that depends on the UA
implementor's idea of navigation.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg