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

[Matthew Raymond]

Sander Tekelenburg wrote:
> At 01:03 +0000 UTC, on 2005/12/31, Ian Hickson wrote:
>>If we're trying to solve the problem of _sending_ the data twice
> 
> We're not.
> 
>>, that is
>>easily solvable, by using rel="" on <a> elements instead of <link>
>>elements.
> 
> Yes, but only if browsers would support display:meta.

   No, user agents could construct a link bar using the |rel| values of
hyperlinks. Don't mistake the limitations of browsers for a limitation
in the spec. A user agent can interpret a web page as a talking 3D
parrot and still be HTML compliant.

   With regard to "display: meta", that belongs in www-style, but I
doubt they'll accept it, since it mixes layout with semantics.

>>If we're trying to solve the "problem" of displaying the link
>>navigation twice (once in the page and once in the browser UI) then I'm
>>not convinced that's a problem, or that we should be solving it.
> 
> It's a problem because it wastes valuable screen space and as long as it does
> waste valuable screen space there is not enough incentive for Web publishers
> to bother to offer something like LINK or nav {display:meta}.

   If screen real estate is the problem, then why have link-related
chrome at all? If web page authors really cared that much about screen
real estate, they'd just make their lists of hyperlinks take up less
room. Do you honestly mean to tell me that we can trust user agents to
create a link bar smaller than one I could create myself within the page
as a web author? If that's true, then there's a serious problem with CSS.

   Now, it is reasonably to say we need link bars or similar chrome so
that navigational buttons that have the same function are always in the
same place. If you always click in the same place to get to the root
page, or the parent and so forth, no matter what the web site, then it
does improve the user's ability to navigate.

   The problem is that <link> has throughly proven that there is little
demand for such usability features from users. Look at RSS. Pretty much
everyone supports it, and <link> is much older. Tabbed browsing. Again,
pretty much everyone supports it. If <link> had anywhere near this level
of support from users, we wouldn't be having this conversation. In fact,
the more I think about it, the more I think that HTML features written
specifically for chrome integration should be avoided.