[whatwg] Menus, fallback, and backwards compatibility: ideas wanted
ian at hixie.ch
Wed Dec 14 18:21:58 PST 2005
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>
> > 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"
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg