- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 15 Dec 2005 02:21:58 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 December 2005 18:21:58 UTC