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

[James Graham]

Anne van Kesteren wrote:
> Quoting Lachlan Hunt <lachlan.hunt at lachy.id.au>:
>> No it doesn't.  Neither of them make any sense at all.  If I've 
>> understood this thread well enough, the whole concept behind it means 
>> to take this element out of the normal flow and do some magic to 
>> display it somewhere appropriate in the chrome of the browser.  e.g. 
>> in a menu for <link>, the title bar for <title>, the status bar (or 
>> wherever) for something else.  Who knows what on earth would happen 
>> with this applied to an HTML document?
>>
>>   * { display: meta; }
>>
>> CSS is the wrong layer to handle this.  AIUI, I believe the binding 
>> layer (XBL) is the correct layer for it.
> 
> I agree that CSS is the wrong layer. XBL doesn't really solve this 
> though as it
> doesn't affect the semantics of the document. It merely adds some kind of
> "pseudo-dom" to the node it is bound to (that doesn't affect the 
> semantics of
> that node nor of the document the node is in).
> 
> However, I'm still not sure what problem is being solved here.
> 
> 

If I understood correctly, the problem that is being solved is loosely 
"websites all look different and so are hard to navigate". 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.

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.

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.

Of course I may have missed the point entirely. I don't claim to have 
read every word in the thread.