- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sun, 01 Jan 2006 19:15:46 -0500
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.
Received on Sunday, 1 January 2006 16:15:46 UTC