- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 20 Dec 2005 00:55:48 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 19 December 2005 16:55:48 UTC