[whatwg] Seperation of Content and Interface
mpt at myrealbox.com
Mon Jul 12 23:06:41 PDT 2004
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),
> The Firefox situation really annoys me. The PTBs running the
> Firefox show seem to thing that this feature is better as an
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
> > 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
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
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?
More information about the whatwg