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

[Ian Hickson]

On Sun, 1 Jan 2006, Matthew Raymond wrote:
> 
> 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.

So long as it puts quotes around the contents of <q> elements... (assuming 
it's an HTML4-compliant parrot you mean).


> 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.

I agree. This is one reason I don't see the out-of-band link UI aspect of 
HTML's <link> element from ever truly taking off.


> 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.

I don't know if I'd go that far (e.g. the back/forward integration APIs 
have clear demand; though it remains to be seen if our APIs get 
implemented and used, people are certainly doing their best to implement 
JS libraries to fake them today).

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