[whatwg] Seperation of Content and Interface

[Matthew Raymond]

Matthew Thomas wrote:
> Congratulations! You've just reinvented the LINK element, which has been 
> in every version of HTML since 2.0.

    Agreed. We should avoid creating new incarnations of old markup. 
Instead, we should either extend existing markup or advocate its use, 
except in situations where the existing markup is impossible to work with.

> 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. 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?)

> common LINKs would be in exactly the same pixel position on all pages,

    True, this would be good from a usability standpoint.

 > visual browsers could optionally ignore
> navigation when printing (no need for special print style sheets that 
> most sites can't be bothered with), screenreaders could optionally skip 
> or postpone navigation when reading (no need for special "skip 
> navigation" links that most sites can't be bothered with),

    Well, technically, if there were a new set of elements for 
navigational bars, they could do all of this.

 > and the Web would be much easier to use for everybody.

Possibly, assuming that the webmasters used it. Then again, my pages 
don't. [Note to self: Revise web pages to use <link> navigation.]

> 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. In the 
meanwhile, the only extension I know of that does this, Link Toolbar, 
doesn't work on Firefox 0.9 yet.

    I'm similarly annoyed by the way Firefox handles alternate 
stylesheets. You only even know they're available by looking for a tiny 
icon on the left-hand side of the statusbar, and there is no way to 
access this in the menu system. This, in my mind, is bad UI. If the 
statusbar is hidden, the user has no way of changing the stylesheet. I 
actually had to search the web on this feature to figure out that 
Firefox even supported alternate stylesheets at all!

    I understand the need for a quick and simple browser for the masses, 
but making it impossible or nearly impossible to use features of W3C 
recommendations directly undermines those recommendations.
</offtopic>

 > or allow it to be hidden (Opera, Mozilla, iCab),

    People shouldn't have to have UI they don't want. If you don't want 
to use a browser's site navigational bar, you should have to have it up 
all the time. In fact, Mozilla is quite consistent about this, since it 
allows you to hide everything but the menu. (Internet Explorer does the 
same thing, it just doesn't have a site navigational bar.) It even 
allows you to conditionally hide the site navigational bar when it can't 
be used.

    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.

 > both of which make it useless. Authors can't rely on it
> (unless they UA-sniff for Lynx), so they still have to insert navigation 
> in the page text, so we're all worse off, whether we're sighted or not.
> 
> I don't think renaming <link> to <navigation> will help.

    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.