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

[Alexey Feldgendler]

On Tue, 20 Dec 2005 07:07:29 +0600, Ian Hickson <ian at hixie.ch> wrote:

>> Absolute navigation includes links to fixed pages, the same on all pages
>> of the site. Usually these are links to top-level sections and
>> subsections thereof. Following an absolute link is like skipping to a
>> fixed vertex in a graph, or resolving an absolute pathname on a
>> filesystem. The absolute navigation is somewhat covered with the <link>
>> mechanism (rel="toc", for example), but it's not enough because the
>> fixed nodes referenced by absolute navigation is rarely described with
>> specific roles like "TOC"; more often, these are just top-level sections
>> of the site.

> Like <link rel="section" title="Products" ...>?

Sort of that. But this can't be used to express a structure of nested  
sections. (We need that to build a good menu in the browser's UI.)

>> Currently, we have <link> which works great in browsers which  
>> understand it.

> Which is roughly none of them.

Recent versions of Mozilla and Opera do. AFAIK Safari does, too. Of  
course, the total marketshare of all these is less than IE's, but I think  
IE7 will support <link>, too. BTW, I've enabled the links toolbar in  
Opera, and I can instantly see when a site offers <link> navigation.  
Actually, many sites do, and most often these are sites which use some CMS.

>> For those who don't, authors usually duplicate relative navigation in
>> the page body. For absolute navigation, though, they have no choice
>> because there is no appropriate mechanism similar to <link> to instruct
>> browsers to include absolute navigation somewhere in its UI outside the
>> viewport.

> Realistically speaking, authors don't use <link> anyway, though, as mpt
> pointed out.

Authors don't, CMS do. If IE7 starts supporting <link>, evem more CMS will  
use it.

> It's less abstract as far as the authors are concerned, because to them
> there is a direct relationship between the document.write() and what they
> see on their screen, as opposed to an indirect one that depends on the UA
> implementor's idea of navigation.

Yes! I think that's the point, that's why I skipped quotation of most text  
above this.

"Draw it by hand in the viewport" or "Let the browser show it to the  
user". It's the same old story. Authors tend to describe every aspect of  
visualization in their CSS. Why? Because different browsers have different  
default rules, and the author wants the page to look the same in all  
browsers. The author wants it so much that he would never trust the  
browser to draw a menu without having full control about the fonts,  
colors, sizes etc. And it would miss the entire point of having a site's  
menu integrated into the browser's UI: the browser should show the site's  
menu items just like it shows its own menu items, so they seem  
intergrated. The browser's menu isn't an extension of the viewport.


-- Opera M2 9.0 TP1 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station at SW-Soft, Inc. [ICQ: 115226275]  
<alexey at feldgendler.ru>