[whatwg] Seperation of Content and Interface

Matthew Thomas 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),
> <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 

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

More information about the whatwg mailing list