The <link> element first appeared in HTML 2.0 and, at that time, it was already a way to implement a Site Navigation toolbar to aid navigation. Still today, many text browsers implement <link rel="..."> that way.
W3C Quality Assurance tip for webmasters:
Use <link>s in your document
How Link Relations Are Implemented
(that page seems to ignore the Firefox add-on
Link Widgets 1.5
Subotnik: The 'link'-Element in (X)HTML
Also Konqueror 3.3 can install a Site Navigation toolbar, according to
I searched for duplicate and I didn't find anything.
Safari 3.0.2 build 522.13.1 here.
Yeah, there's no duplicate because this bug pre‐dates bugzilla, and until His Steveness says there can be a nav bar, it's not likely that <link> elements will be supported. (My non‐official opinion)
Opera 7+, Mozilla 1.x, Seamonkey 1.x, Icab 2+, Lynx, Links (and a number of other browsers via add-on extension) can render a Site Navigation toolbar.
Dive Into Accessibility
30 days to a more accessible web site
Providing additional navigation aids
What's important, IMO, is to offer the user the choice to render a Site Navigation toolbar, just like Seamonkey 1.x does it via a preference:
o Show always
o Show only as needed
o Hide always
giving the user control, flexibility, choice.
<link rel="..."> is defined in the HTML 5 latest WD, at section 4.12.3:
I use Konqueror 4.2.4 (rellinks plugin PPA - document relations plugin - must be downloaded and installed) and enjoy the Site Navigation toolbar.
Not an AX bug. Reassigning component.