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

[Sander Tekelenburg]

At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:

> Sander Tekelenburg wrote:
>> At 01:03 +0000 UTC, on 2005/12/31, Ian Hickson wrote:

[...]

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

Exactly. That would in fact be an implementation of display:meta. Rendering
the contents of TITLE attributes in a Status Bar is too.

(Btw, I don't know if this is in the current Opera, but way back in Mac Opera
5 when we first implemented LINK support, a hack was added that recognised
some standard A link types on a few sites, like Google's search results'
"Next" link which would then be interpreted as LINK rel="next" and presented
accordingly in the LINKs Toolbar. Thus there is, or at least was, a working
implementation of display:meta for LINK elements. It doesn't seem all that
far-fetched to me.)

[...]

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

A "LINKs Toolbar" ("navigation method" would perhaps be a better term, as it
is less implementation-specific) could be hidden by default and presented
only when needed. Like what I mentioned earlier for mobile devices. That way
such a navigation aid would not take *any* space, unless needed - and it
could take *all* space, when needed. I don't see how you could achieve that
with in-body presentation. (In fact, it is the very fact that it would be the
same on every site that makes this possible, because only that allows for the
user to know it exists even when it isn't shoved in his face. With in-body
presentation that's impossible - every site being different, in-body
presentation requires in-your-face presentation.)

> If that's true, then there's a serious problem with CSS.

I can't follow.

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

Indeed, *that* is what I'm trying to say. LINK itself is not important to me.
More comfortable navigation is. And given all the factors and circumstances
involved, my impression is that something like the NAV {display:meta} we
discussed could be a good solution. It would allow authors to provide 1
single navigation menu, not having to worry whether a user-agent supports
display:meta (like authors need to with LINK), and it would allow both
authors and users (and browsers' built-in Style Sheets) to present that
outside of the body, and thus consistently.

>    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? (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.)

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.

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


-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>