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

[Sander Tekelenburg]

At 02:05 +0000 UTC, on 2005/12/13, Ian Hickson wrote:

[...]

> Well, the menu feature is not being _designed_ for navigation, but I'm
> sure that authors would try to use it for navigation. There is a clear
> demand on Web sites today for menu-based navigation.

Exactly.

I think that's a good reason to try and see if the current LINK/navigation
problem can be solved through it.

Personally I wouldn't mind upgrading LINK to something that user-agents must
support :) But then still, until they all do, authors will have to continue
providing in-body navigational content.

[... Example markup...]

> This seems like a highly presentational idea

Yes, I agree it's not elegant.

The thing is that due to some user agents not supporting LINK, authors 'need'
to repeat the LINK's content in the BODY, wasting valuable screen space for
LINK-capable browsers. Ideally such meta information should be in the HEAD
section, but it seems that the only way to allow graceful fallback is to
offer this in the BODY and allow (or even encourage) advanced user-agents to
present it outside of the canvas. That was the thought behind my ugly
proposal above. But, see below.

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

>  or XBL, or a server-side transform
> mechanism.

As far as I can see a server-side solution would require browser-sniffing,
which is unreliable.

> It also would not degrade very gracefully -- UAs that support neither
> <link> nor <menu type="import"> would show nothing.

Sorry, I'm stupid. I had thought of how to handle that but I see that I
omitted 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.

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

So then what's a user-agent that does support both expected to do when it
encounters both? If it displays both the LINK elements and the in-body
navigation menu, there is no improvement whatsoever over the current
situation. The same data is repeated, wasting valuable screen space, with no
advantage to authoring LINK.

Of course a user-agent could try to be smart by recognising that the in-body
<nav><menu> content is the same as the LINK content and choose to render it
only once. But leaving this to such hacks isn't exactly ideal. (Opera does,
or at least used to do something like this. Nice for users, but not something
an author can rely upon.) It would be much stronger to be able to solve this
though a spec, so that authors won't be stimulated to go browser sniffing.

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 realise some of this is probably a bit vague still. I'm only sure about
the problem, not yet about the solution ;)]


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