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

[Ian Hickson]

On Mon, 9 Jan 2006, Sander Tekelenburg wrote:
> At 01:21 +0000 UTC, on 2006-01-09, Ian Hickson wrote:
> >>
> >> I constantly see friends, family, clients, strangers, colleagues 
> >> struggle to figure out how to navigate through sites they don't know 
> >> yet.
> >
> > Well sure, I struggle through such sites myself. The problem would not 
> > be aleviated by having a single point for site navigation, because the 
> > problem is just that the sites have poor structure. It doesn't matter 
> > how you _present_ the structure, if the structure itself is broken.
> 
> True, that can also be a cause. But imagine for a moment a situation 
> where at least the majority of browsers in use would have a nice NAV 
> display:meta implementation, making it *visible* to people how they can 
> organize the data they publish. Wouldn't that work as a guide, helping 
> those who are not that well-organized realize how to publish their 
> content in a more organised manner?

No, not really, IMHO. Sites already have a big area where they can see 
their site, yet they make sites that are ugly and slow and unusable. Why 
would a tree (or other navigation representation) be any different?


> They might well think "Ah, I can do like that other site: make a contact 
> and a help page and tag 'm with display:meta to put them in that 
> navigation thingy. I can even make "sections" that way to different 
> parts of my site. k3wl."

Why would they care? We haven't seen any evidence to suggest they would. 


> That's how it works with most things: some technique becomes available 
> in a nice and obvious form and suddenly people start using it.

Usually, there's at least a rumbling of desire before it's made available. 
For navigation toolbars, there's been basically nothing. Browsers have 
implemented them, shipped them, then removed them because nobody cared.


> >> > [display:meta] could be interesting if (and it's a big if!) you 
> >> > could convince browsers to implement it.
> >>
> >> I imagine it would be a logical step for Opera and Safari to take, 
> >> given their activity in the hand-held/small screen market where 
> >> something like this would probably be very useful.
> >
> > Well go and convince them and when you have some implementations we 
> > can add it to the spec. :-)
> 
> My impression was that representatives of most browsers subscribe to 
> this list. So I'm assuming they've already heard me. Maybe they're 
> silently laughing at the nonsense I'm talking. Maybe they're already 
> enthusiastically implementing it. I've no idea.

I'm guessing not the latter, since it's been more than 18 months and we 
haven't seen anything new in this space.


> Anyway, I don't think we want to go back to the days where a browser 
> defines its own new standards which other browsers are then forced to 
> copy, faults included because by then too many authors/users are relying 
> on that specific implementation. Makes more sense to me to all of us try 
> to agree on something we think could work, and only then start work on 
> (experimental) implementations and a spec.

Experimental implementations and spec work should happen in parallel, 
otherwise we end up with standards that are theoretically perfect and 
practically useless.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'