[whatwg] (no subject)

Wed Dec 14 16:07:35 PST 2005

967bfc5e6ee406c@[192.168.0.104]>
Mime-Version: 1.0 (Apple Message framework v623)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <6a7f17cdcf1ff6c81bf2bfa260b36c17 at myrealbox.com>
Content-Transfer-Encoding: quoted-printable
From: Matthew Paul Thomas <mpt at myrealbox.com>
Subject: <link> navigation (Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted)
Date: Wed, 14 Dec 2005 22:07:26 -0200
To: WHAT WG List <whatwg at whatwg.org>
X-Mailer: Apple Mail (2.623)

On 14 Dec, 2005, at 1:55 PM, Sander Tekelenburg wrote:
> ...
> Personally I wouldn't mind upgrading LINK to something that=20
> user-agents must support :) But then still, until they all do, authors=20=

> will have to continue providing in-body navigational content.
> ...
> The thing is that due to some user agents not supporting LINK, authors=20=

> 'need' to repeat the LINK's content in the BODY, wasting valuable=20
> screen space for LINK-capable browsers.

And that is the vicious cycle that means <link> navigation will never=20
be viable. As long as *any* widely-used browser does not implement it=20
reliably, Web authors will have to duplicate <link>s with navigation in=20=

the <body> (unless they UA-sniff, which will usually be too much=20
trouble). As long as sites using <link> navigation have to duplicate it=20=

in the <body>, most of them won't bother, making it a low priority for=20=

browser vendors. And as long as sites using <link> navigation have to=20
duplicate it in the <body>, browser vendors will have an incentive=20
*not* to support it reliably, because if they do, <link>ed sites will=20
have confusingly redundant navigation when viewed in that browser.

That could perhaps be worked around by surrounding fallback navigation=20=

with a <nolink> element, to be presented by browsers that didn't=20
support <link> (analagous to <noframes>). But there are other problems,=20=

such as the vast majority of authors not *wanting* to entrust their=20
navigation to a one-presentation-fits-all navigation bar. See Google=20
Directory, IMDb, and Ask MetaFilter for examples of vastly differing=20
navigation requirements that would suffer from being made consistent=20
with each other. And see OS X's Expos=E9, OmniWeb's thumbnails, and=20
Firefox's Tab Sidebar extension for examples of features that benefit=20
from Web sites being visually inconsistent with each other. Sometimes=20
consistency is not a good thing.

As Ian alluded to, it's been ten years, two months, and 22 days since=20
the codification of <link>, and there is still no browser other than=20
Lynx that supports <link> navigation reliably enough for authors to be=20=

able to rely on it. (iCab and Opera don't count, because their toolbars=20=

can be turned off. The Firefox extension has the same problem, only=20
moreso.) You and I both tried to get <link> navigation off the ground,=20=

in our separate ways, but -- like Ian -- I really think it's a lost=20
cause now. Let it go. :-)

--=20
Matthew Paul Thomas
http://mpt.net.nz/=