[whatwg] The <link> element and "display: meta"

As a general rule, the 'display: meta' discussion belongs in the CSS 
group's mailing list, not in the WHATWG mailing list. Having said that:

On Mon, 9 Jan 2006, Sander Tekelenburg wrote:
> > 
> > The problem is that <link> has throughly proven that there is little 
> > demand for such usability features from users.
> 
> How has that been proven? The fact that the majority doesn't (yet) make 
> use of something is hardly proof, is it?

It's pretty close, though. :-)


> (Based on how I see people struggle with WWW navigation I would say 
> there certainly is demand for something like this. I can't prove it, but 
> it certainly seems obvious to me.)

While I could see an argument for there being _something_ to help people 
navigate (if we had usability studies to suggest there was a problem), I'm 
not sure we can jump straight from there to the need of a navigation bar. 
After all, we'd need evidence that the navigation bar helps.


> Btw, that reminds me of something Apple did that I think confirms my 
> idea that people find it hard to navigate the Web: Safari's SnapBack 
> function targets exactly that issue.

Does anyone use that? :-)


> > Look at RSS. Pretty much everyone supports it, and <link> is much 
> > older.
> 
> I don't see how that proves anything. If Navigator and Explorer 2.0 had 
> supported LINK then probably every single site out there would be using 
> it today. Authors and users using something, or even *recognising* that 
> they 'need' something is often only made visible after it has been made 
> available to them.

The point I think is that RSS went from not existing to being implemented 
and widely used in less than than <link> has existed, indicating that 
<link> is not as "good" as RSS. The question is: why has <link> not been 
widely implemented, when other, newer things have?


On Fri, 20 Jan 2006, Sander Tekelenburg wrote:
> 
> Remember that the idea is that authors/users can tell a browser to 
> present certain data in a manner that is consistent across sites. In 
> today's browsers I think that indeed would only be possible by 
> presenting it outside of the body, because each site's body is unique 
> and thus cannot offer such consistency.

Just saying 'display: meta' isn't enough for a browser to know what to 
display, though.


> HTML 5.0 defines a NAV element to indicate a navigation menu which is 
> allowed to contain (sectioned) lists of links, and which may be (should 
> be?) presented in a manner that is consistent across sites.

<nav> will just be rendered as the site's style sheet says it should be 
rendered.


> CSS 3.0 defines a "meta" value for the display property, thus providing 
> authors and users with a mechanism to suggest that a user-agent presents 
> targeted elements as if they contain meta data, optionally (but in 
> practice probably always) presented outside of the body, in such a way 
> that it is easy for the user to access and is presented consistently 
> across sites. Exactly how the *contents* of an element that is displayed 
> "meta" are presented is up to the user-agent, allowing for a 
> presentation that makes sense for a given browsing environment. (The 
> spec could include a suggestion that a possible implementation would be 
> a separate browser window, which the user may target with User CSS to 
> effect his own preferred consistent presentation across sites.)

I don't understand how the 'meta' value would know what to show or do.


On Sun, 22 Jan 2006, Anne van Kesteren wrote:
> 
> However, I'm still not sure what problem is being solved here.

Indeed.


On Sun, 22 Jan 2006, James Graham wrote:
> 
> If I understood correctly, the problem that is being solved is loosely 
> "websites all look different and so are hard to navigate".

Are we sure that Web authors actually want to solve this? Because without 
their involvement, this will be hard to fix.


> Am I correct? Assuming I am, the idea of display:meta or any other 
> similar solution is doomed to fail for the same reasons that <link> has 
> never really taken off (only the situation with display:meta would be 
> much worse because it applies to all elements):
> 
> 1. It doesn't make sites consistent. Even if we only consider 
> display:meta being used to create native menus from navigation lists, 
> each site would still have totally different items in a totally 
> different order. In desktop applications, the consistency comes not so 
> much from the fact that all menu bars look the same and appear in the 
> same place (though that is important) but from the fact that it is 
> possible to guess which items will be in which popup and what the 
> function of each item will be (e.g. the Edit menu will _always_ start 
> Undo, Redo, Cut, Copy, Paste... assuming those actions are supported by 
> the application). On the web, there is inherently no such consistency 
> (websites don't have nearly the same consistency of actions that desktop 
> apps have) and it's hard to imagine a Web equivalent to Desktop UI 
> Guidelines to bully site authors into providing a consistent menu 
> stucture.

Indeed.


> 2. It violates the mental separation between browser and site. My 
> experience when using the firefox link toolbar is that, even on the rare 
> occasions where it was populated with useful entries _at_all_ I was more 
> likely to use the on site navigation controls, simply because I wasn't 
> looking in the browser chrome for a site-specific control. I guess many 
> people would experience the same problem.

Interesting.


> 3. Of course point 2 wouldn't be a problem if this was used to 
> pervasively and consistently (but see point 1) that everyone got used to 
> looking in the browser chrome for site-specific functionality. But in 
> the meantime, why would a significant fraction of authors use a style 
> rule that, for all that people would notice it, might as well be named 
> display:really-well-hidden? And if no authors use it, no one will learn 
> to look for it and... well you see its a problem that was discussed a 
> long time ago.

Indeed.


On Wed, 11 Jan 2006, Sander Tekelenburg wrote:
> 
> [...]

I'm not really convinced that this proposal solves the problem it sets out 
to solve, nor that authors want to solve the problem, nor that there is a 
problem in the first place, to be honest.

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

Received on Thursday, 1 November 2007 17:08:23 UTC