[whatwg] Web Apps 1.0: Making <link> navigation palatable

[Matthew Thomas]

On 14 Jul, 2004, at 2:32 AM, Matthew Raymond wrote:
> ...
>> 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?

I said both "colors and background" so as to include non-plain-color 
backgrounds, yes. And most professional sites would, I think, reject 
the scheme outright if they couldn't use their logo for the link to 
their front page.

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

I did not say, and do not think, that Firefox sucks or that there is 
any better browser on Windows. But if Web Apps 1.0 is going to include 
"Elements for semantics commonly found in applications, such as 
<byline> ... <navigation>, etc" 
<http://whatwg.org/specs/web-apps/current-work/#requirements>, we 
*should* examine why UAs such as Firefox don't support the HTML that 
already exists for those two purposes, and why UAs such as Opera don't 
support it in a way authors can rely on. Otherwise we risk creating 
brand-new markup that suffers exactly the same fate.

Largely, I think these UAs don't support <link> reliably because their 
designers get stuck in the same logic you seem to have. They imagine 
the only practical implementation is a toolbar, and if it's a toolbar 
it must be hidable, and if it's hidable it should be off by default 
because it's only useful for a tiny minority of sites anyway, and hey, 
if hardly anybody uses it, why include it in the default build in the 
first place?

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

I did not say it should be always visible regardless of the contents of 
the Web page. On the contrary, I said it must be "reliably noticable". 
If it was visible even on pages that didn't have any <link>s, it would 
not be reliably noticable, because it would be inactive ~99.9 percent 
of the time, so people would get used to ignoring it.

This is easily demonstrated by trying the <link> toolbars in Mozilla, 
Opera, or iCab, in "Always On" or equivalent mode. They're useless 
unless you understand HTML -- in which case you can use the nerdiness 
of a page's design (e.g. W3C specs, useit.com, LaTeX2HTML output) as a 
hint that the page might be using <link>, and consciously scan the 
toolbar to confirm your suspicions. Otherwise, you eventually start 
ignoring the toolbar.

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

That's right; it must not be present in that case.

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

Since it wouldn't be rendered for pages that didn't use it, that 
wouldn't be a problem.

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

"May" does not mean "both must and must not, configurable by the user". 
For example, it's not compulsory for UAs to render <b> elements in 
bold, but that doesn't mean browsers need to provide UI to toggle such 
boldness.

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

That's right. Until all noticable UAs render (or can be tricked into 
rendering) <link> reliably, authors have to (a) serve non-<link> 
navigation to everyone, or (b) UA-sniff and serve non-<link> navigation 
to UAs that can't be relied on. But that situation seems to apply to 
most, if not all, of the stuff listed in the Web Apps 1.0 requirements.

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

No, it would not be "part of the browser"; as I said, "we're talking 
about parts of a Web page here". And parts of a Web page that don't 
exist usually aren't rendered.

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

True. The author benefits are indirect, in that easy-to-use sites tend 
to be more popular.

> 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.
> ...
> Perhaps we should wait until someone actually describes a new element 
> before we start attacking it.

Okay, so let's start. For Web Apps 1.0:

*   How can Internet Explorer be persuaded to render
     <link>s? (I realize that is only the first of many steps
     to implementing an MSIE shim. For example, <link>s with
     rel="stylesheet" or rel="icon" need to be excluded ...)

*   How can <link> be extended to allow for a possible
     search form in the navigation bar? <link
     rel="sitesearch" href="foo.cgi" method="GET"
     title="Search example.com">?

-- 
Matthew Thomas
http://mpt.net.nz/