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

At 01:07 +0000 UTC, on 2005/12/20, Ian Hickson wrote:

> On Thu, 15 Dec 2005, Alexey Feldgendler wrote:

[...]

>> Currently, we have <link> which works great in browsers which understand it.
>
> Which is roughly none of them.

Depends on how you look at it. My perception is that roughly all browsers
support LINK, except Safari and WinIE.

Mozilla, Opera, iCab and lynx all support LINK. Firefox requires a
third-party plug-in, as does WinIE. Of course WinIE is the main issue. If
WinIE 7 would support LINK natively, suddenly the LINK landscape would look
very different. I doubt Safari would stay behind then.

Thus again it is an issue of Microsoft's relative monopoly in the browser
world. But I don't see many people arguing to declare CSS dead just because
IE's CSS support sucks. So why should we look that way at LINK?

[...]

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

My impression is that this is slowly changing, as more and more sites are
generated by automated Web publishing systems (CMSs, blogs, etc.) which (can)
insert this type of thing automatically. Given that, it would seem logical to
me for Firefox and Safari to add native LINK support now. Those two factors
(Web publishing systems generating LINKs, and Firefox & Safari having native
support) might well push Microsoft to do the same in IE7.

[...]

>> Why? Everyone puts CSS and JS in external files -- just to avoid
>> repeating the same text on all or most pages of the site.
>
> It's not the "external file" aspect that's the problem, it's the
> abstraction of having the site description at all.

Agreed. But again, automated publishing systems seem to be solving that.

[...]

>> And, well, everyone puts links to top-level sections of the site on
>> every page, which is actually repetition.
>
> Server-side includes are often used to fix this

Maybe I'm misunderstanding what you mean, but it seems to me that the only
way server-side includes can help with this in in the sense of authors not
having to define the same content twice. The user-agent will still *receive*
it twice, resulting in LINK capable browsers wasting space by repeating the
content in-body. I can't speak for Alexey, but *that* is the repetition
problem I am referring to.

> -- maybe we should
> consider ways to address this need rather than <link>, come to think of
> it. Especially in conjunction with <a rel="">, this could indirectly solve
> your problem.

FWIW, my aim is to get at a place where "navigation menus" can be authored in
such a way that user-agents won't have to receive it twice and can (if they
want) display it outside of the canvas in a way that works the same across
sites, thus making navigation more recognisable and therefore easier. If that
can be achieved without LINK that's perfectly fine with me. It's not LINK
itself that I care about.


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

Received on Tuesday, 20 December 2005 07:13:43 UTC