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

Wed Jul 14 08:51:36 PDT 2004

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

    Here's what you said: "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."

    Sounds like a straight-up insult to me.

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

    True enough. If UAs are rejecting markup, knowing why would help 
prevent the introducing of new markup that will go unused.

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

    I think you're misrepresenting the issue. Part of the problem is 
control. Custom navigational bars in the web page give a great deal more 
control over layout and styling, and I think it is this control that 
encourages webmasters not to use <link>. The browser companies are 
simply responding to this fact. It is possible that some standardization 
of layout and greater styling control for <link> elements might help, 
but I'm uncertain of this.

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

    I was just thinking that is would be nice if you could style the 
background for the toolbar as well as the buttons. That way, when the 
site navigation bar is in use, it looks like an extension the web page. 
That may encourages web authors to use <link>. Perhaps this could be 
done using CSS with the <head> element.

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

    Agreed, so perhaps we should start creating some guidelines for 
<link> when implementing its relationships as a toolbar.

    Menus are good too, but the problem is that users of a simpler mind 
won't notice them. Non-techies don't necessarily like to explore the 
features of their software.

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

    I'm not seeing your point. If a webmaster can't rely on a fully 
HTML-compliant user agent to support something, why should they use it 
in the place of another HTML-based solution that always works in a fully 
HTML-compliant UA?

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

    I would presume that the MSIE "shim" could implement a toolbar or 
menu of some sort, but that's Dean Edwards' department.

> *   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">?

    These are really implementation concerns. They're only valuable here 
in the sense of browser limitations preventing a feature from being 
implemented.