[whatwg] Menus, fallback, and backwards compatibility: ideas wanted

[Sander Tekelenburg]

At 02:21 +0000 UTC, on 2005/12/15, Ian Hickson wrote:

> On Wed, 14 Dec 2005, Sander Tekelenburg wrote:
>>
>> Personally I wouldn't mind upgrading LINK to something that user-agents
>> must support :)
>
> The spec can require whatever it likes, that won't in any way make
> browsers support things. :-)

Very true.

[...]

> One of the key concepts Tantek often pushes in the microformats forums is
> the idea that metadata should be visible. <link> violates this concept in
> most UAs today.

I can't follow that. (Btw, meta data doesn't have to be "visible", it has to
be *accessible*.) You seem to mean to say that there is something wrong with
LINK itself, while I think the problem is with implementations in
user-agents. The only reason LINK is not accessible in IE and Safari is that
those browsers don't make it accessible. If a user-agent does't make the
contents of HREF attributes accessible then they're not accessible. Same
thing.

It seems to me that the user-agents "violate" the concept, not LINK itself.

> I think that's why it hasn't really taken off.

I think it hasn't taken off because of stupid browser wars, which pushed
(pushes?) browser developers towards concentrating on quick and easy gimmicks
to lure users. LINK support will only lure users en masse when Web publishers
support it, which they don't do because as long as they have to still repeat
the same content in-body, there is little incentive.

[...]

> I think the fact that <a> supports rel="" gives us a way to drop <link>
> altogether, actually.

I assume you're only referring to these "navigation" relationships - not to
LINKs to Style Sheets, or to alternate content: <LINK
href="http://matthias.gutfeldt.ch/translation/LINK/" rel="alternate"
hreflang="de" lang="de" title="Deutsch: Das Link Element.">

[...]

> I think you're trying to solve a problem that doesn't exist.

What doesn't exist about the problem I describe at
<http://www.euronet.nl/~tekelenb/WWW/LINK/>? It is quite real. It could have
been solved by LINK, but given that user-agents concentrated on other things,
by now it requires a solution that involves not having to repeat the same
navigational content.

> Authors like
> having the links in their content area. We're not going to convince them
> to remove them. IMHO.

Right. (Not until user-agents make LINK accessible anyway). So defining a
mechanism that allows such markup and at the same time allows user-agents to
present it as meta data seems to be a route that could work. For the moment I
think I like your proposed HTML/CSS of:

<nav style="display:meta">
	<menu type="commands" label="Navigation">
		<a rel="home" href="index.html">Home</a>
		<a rel="contents" href="toc.html">TOC</a>
		<a rel="help" href="help.html">Help</a>
		<a rel="search" href="search.html">Search</a>
		<a rel="address" href="address">Contact</a>
		<a rel="section" href="support.html">Support</a>
		<a rel="section" href="downloads.html">Downloads</a>
		<a rel="section" href="drivers.html">Drivers</a>
		<a rel="section" href="updates.html">Updates</a>
		<a rel="section" href="forms.html">Forms</a>
		<a rel="section" href="archive.html">Archive</a>
		<a rel="section" href="feedback.html">Feedback</a>
	</menu>
</nav>

(Btw, a label="Navigation" probably isn't needed if this is already embedded
in <nav>.)

It would probably require either deprecating LINK (an idea I'm not fond of)
or specifying that when the document also contains <link rel="home" blah> it
should recognise that as repetition and should  therefore render this content
only once. (Which might not be ideal either, as it might slow down parsing.)


-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>