- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Tue, 13 Jul 2004 18:06:41 +1200
On 13 Jul, 2004, at 12:53 AM, Matthew Raymond wrote: > > Matthew Thomas wrote: > ... >> If UAs presented LINK navigation in a manner that was both reliably >> visible (i.e. couldn't be turned off, just like A HREF links) and >> reliably noticable (i.e. shared the same color scheme as the page, >> just like A HREF links), Web sites wouldn't need to insert navigation >> bars into Web page text, > > I'm not convinced that every navigational bar out there is > necessarily better done through links support. For one, it ignores the > possibility of UI innovation by webmasters. So does everything else that browsers do by default. TITLE in the title bar. Light-colored page background. Black serifed text. Blue underlined links. If authors don't like it they can (and do) use something else -- keeping in mind that the more they diverge from the user's preferences, the more annoying they'll be. > It also prevents webmasters from bringing their own style to the > navigational bar. > > (Thought: Can you style <link>? Will XBL work on the <link> element? > Would it be possible to create a custom navigational layout using > <link> alone?) UAs could allow authors to change the colors and background, so as to match the color scheme of the site. Anything else could be ignored to preserve consistency of position, just as (for example) Safari ignores most styling of form controls. > ... >> Unfortunately, the only UA that I know of that supports LINK >> navigation in such a fashion is Lynx. Other UAs either ignore it >> completely (Internet Explorer, Firefox, Safari), > > <offtopic> > The Firefox situation really annoys me. The PTBs running the > Firefox show seem to thing that this feature is better as an > extension. Firefox isn't noticably innovative in any respect (mere competence is enough for now), so I don't think that's really surprising enough to be annoyed about. > ... > > or allow it to be hidden (Opera, Mozilla, iCab), > > People shouldn't have to have UI they don't want. UI? We're talking about parts of a Web page here. Consider A HREF. No browser I know of lets you hide A HREF links (unless you're using a user style sheet). If UAs commmonly did allow that, Web authors would be unable to rely on A HREF, so they'd have to use something else instead (e.g. <button>s and/or scripts). As a result we'd suffer from inconsistency, lack of portability, and poorer addressability. Allowing you to hide LINK links is *exactly* as silly (unless you're printing). In any UA that allows that, Web authors are unable to rely on LINK, so they have to use something else instead (e.g. A HREFs and/or menus with scripts). As a result we suffer from inconsistency, overuse of paper, and poorer accessibility. > If you don't want to use a browser's site navigational bar, you should > have to have it up all the time. > ... > Taking options from users doesn't make the Internet better. It just > drives people away from browsers that won't let them do what they > want. > ... And into the arms of browsers that do let you hide sites' navigation bars. Oh wait, *there aren't any*. Because browsers can't tell where a site's navigation bar begins and ends, because the sites aren't using LINK, because the only browsers that display LINKs also let you hide them, so authors can't rely on it, so they don't use it. > ... > I think the idea is not so much a renaming, but rather creating a > framework for a navigational bar that is more feature rich. The real > question isn't whether <link> is appropriate for such new features so > much as whether there is a reasonable use case for the new features. I > don't know if there is or not. The more feature-rich it was, the less consistent it would be, so the less benefit there would be for authors using it. Why surround their fully customized navigation bar with <navigation></navigation>, for example, when they could use the shorter <div id="nav"></div> instead? -- Matthew Thomas http://mpt.net.nz/
Received on Monday, 12 July 2004 23:06:41 UTC