[whatwg] (no subject)

Mon Dec 19 16:55:48 PST 2005

On Wed, 14 Dec 2005 mpt at myrealbox.com wrote:
> 
> On 14 Dec, 2005, at 1:55 PM, Sander Tekelenburg wrote:
> > ...
> > Personally I wouldn't mind upgrading LINK to something that
> > user-agents must support :) But then still, until they all do, authors
> > will have to continue providing in-body navigational content.
> > ...
> > The thing is that due to some user agents not supporting LINK, authors
> > 'need' to repeat the LINK's content in the BODY, wasting valuable
> > screen space for LINK-capable browsers.
> 
> And that is the vicious cycle that means <link> navigation will never be 
> viable. As long as *any* widely-used browser does not implement it 
> reliably, Web authors will have to duplicate <link>s with navigation in 
> the <body> (unless they UA-sniff, which will usually be too much 
> trouble). As long as sites using <link> navigation have to duplicate it 
> in the <body>, most of them won't bother, making it a low priority for 
> browser vendors. And as long as sites using <link> navigation have to 
> duplicate it in the <body>, browser vendors will have an incentive *not* 
> to support it reliably, because if they do, <link>ed sites will have 
> confusingly redundant navigation when viewed in that browser.

Indeed.

> That could perhaps be worked around by surrounding fallback navigation 
> with a <nolink> element, to be presented by browsers that didn't support 
> <link> (analagous to <noframes>). But there are other problems, such as 
> the vast majority of authors not *wanting* to entrust their navigation 
> to a one-presentation-fits-all navigation bar. See Google Directory, 
> IMDb, and Ask MetaFilter for examples of vastly differing navigation 
> requirements that would suffer from being made consistent with each 
> other. And see OS X's Expose, OmniWeb's thumbnails, and Firefox's Tab 
> Sidebar extension for examples of features that benefit from Web sites 
> being visually inconsistent with each other. Sometimes consistency is 
> not a good thing.

And that too. :-)

> As Ian alluded to, it's been ten years, two months, and 22 days since 
> the codification of <link>, and there is still no browser other than 
> Lynx that supports <link> navigation reliably enough for authors to be 
> able to rely on it. (iCab and Opera don't count, because their toolbars 
> can be turned off. The Firefox extension has the same problem, only 
> moreso.) You and I both tried to get <link> navigation off the ground, 
> in our separate ways,

Much as I did. See bugzilla bug 2800. (I filed that nearly six years ago.)

> but -- like Ian -- I really think it's a lost cause now. Let it go. :-)

Glad you agree!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'