[whatwg] Seperation of Content and Interface

[Matthew Raymond]

Matthew Thomas wrote:
>>    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. 

    Defaults are not the same thing as a lack of ability to style 
something. In fact, some UAs may actually use stylesheets for the defaults.

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

    Not necessarily, and you're assuming that the method of navigations 
the webmaster would want to use is entirely supported by the browser.

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

    Something like that may actually lead to heavier use of <link> for 
navigation. Would that allow background images as well? Perhaps icons?

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

    Okay, there's a difference between saying "I don't like this one 
thing they did with Firefox" and "Firefox sucks". Let's not start 
arguments about which browser is better. It only undermines what we're 
trying to do here. Also, I recall indicating that I was speaking off topic.

>>    People shouldn't have to have UI they don't want.
> 
> UI? We're talking about parts of a Web page here.

    According to what you said before, we're talking about a bar with a 
fixed, largely unstyled UI that is always visible regardless of the 
contents web page. That sounds like browser UI to me.

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

    An <a href> element may not even show up in a web page, and it 
logically follows that if that's the case, you should see hyperlinks 
created by them. Similarly, if <link> elements that apply to buttons in 
a site navigations bar are not present, the user should not be forced to 
have a site navigations bar present. Furthermore, <a> elements are 
common on the web. The use of <link> for navigation is not, so most of 
the time the site navigations bar would go unused.

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

 From the HTML 4.01 spec:

    "Although LINK has no content, it conveys relationship information 
that may be rendered by user agents in a variety of ways (e.g., a 
tool-bar with a drop-down menu of links)."

    Notice the use of the word "may". That means that rendering <link> 
is optional. Also notice that the user agent has a choice of how to 
render or use the relationships defined by <link>. That means that even 
if a UA supports HTML 4.01 completely, you have no way of knowing how or 
if this information will be displayed.

    By contrast, only styling can disable an <a> element.

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

    Whereas you'd have them forced to have two navigation bars, one in 
the web page, and one as part of the browser that doesn't even work 
because the web page doesn't have any relevant <link> elements.

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

    I sort of see your point, although I think you're confusing author 
benefits with user benefits. Consistency is good, but it can be taken to 
an extreme. For instance, <link> does not allow for nested menus for 
site navigation, nor does it allow the incorporation of a search bar. 
Fixed UI schemes are not always best for site navigation.

 > Why surround their
> fully customized navigation bar with <navigation></navigation>, for 
> example, when they could use the shorter <div id="nav"></div> instead?

    Considering I have no idea how this <navigation> element will be 
implemented, I cannot answer that with any degree of accuracy. Perhaps 
we should wait until someone actually describes a new element before we 
start attacking it.