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

[Ian Hickson]

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


> But then still, until they all do, authors will have to continue 
> providing in-body navigational content.

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 think that's why it hasn't really taken off.


> > -- that is, something that would be better addressed using CSS
> 
> Agreed, except that I don't see how :) Can you elaborate? Is this a 
> proposal for something like display:link or display:meta?

No proposal yet, but yeah, something like that.


> > Here's an alternative proposal to do the same thing:
> >
> >  <nav>
> >   <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>
> >   </menu>
> >  </nav>
> 
> Yes. This includes exactly what I omitted, but in a much nicer way even 
> :) I hadn't thought of the possibility to use REL for this.

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


> > The UA can still take the link types out and make the toolbar, if it 
> > wants to do so, as the semantics are still there.
> 
> Agreed. This seems more elegant than what I suggested.
> 
> However, assuming LINK won't be deprecated, authors would probably have 
> to then chose between
> - using this construction instead of LINK elements, thus essentially 
> deprecating LINK, or
> - using this construction *and* repeating their content in LINK 
> elements, for user-agents that don't support <nav><menu type="commands" 
> label="Navigation">.

Maybe we should deprecate <link> for this kind of thing.


> Therefore: what if the spec would state that in such situations the 
> value of the REL attribute would be authorative for such a comparison? 
> That, if a LINK's REL value equals that of an A's REL value (provided 
> the anchor is embeded in <nav><menu type="commands" 
> label="Navigation">), a user-agent may choose to not render the conten 
> inline, but through a meta mechanism such as the LINKs Toolbar that some 
> browsers offer?

I think you're trying to solve a problem that doesn't exist. Authors like 
having the links in their content area. We're not going to convince them 
to remove them. IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'