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

Mon Jan 9 12:39:00 PST 2006

Sander Tekelenburg wrote:
> 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.

   No they're not. They're implementations of the |rel| and |title|
attributes. Even if they were implementations of "display: meta", this
is not the correct forum. The W3C www-style mailing list is.

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

   Until I can turn items into metadata using "display: meta" in a style
sheet, there is no implementation. Furthermore, you're mixing semantics
with presentation, so the "meta" value will never be included in CSS in
the first place.

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

   So could anything else using the style "display: none".

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

   This is a simple matter of DHTML. Just because something's in the
chrome doesn't mean that you can't do the exact same thing in the <body>.

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

   This problem is better solved by markup, though. For instance, what
happens if I use "display: meta" in my user style sheet? What happens if
I use "display: block" in my user stylesheet to override the "meta"
value, and it ends up making a page five times bigger because it has a
complex menu system?

>>If that's true, then there's a serious problem with CSS.
> 
> I can't follow.

   CSS (in combination with HTML and Javascript) is more than flexible
enough to simulate virtually any UI. In fact, the other day I saw a page
that emulated the Windows XP desktop. I don't see an obvious UI it can't
simulate within the <body>, and any space used in a browser window for
chrome would probably come at the expense of the size of the <body>.

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

   Doubt it. All I see are a bunch of complex rules on how to process
the children of a "meta" element. It would be a nightmare to spec, and
it would require you to spec how meta interacts with both HTML and all
XML-based languages.

   By contrast, you could implement an HTML-based menu system that would
leave CSS as-is and could be easily implemented on top of menu widgets.

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

   Why not just have menus, then? Why mix presentation with semantics at
all?

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

   Support for "linkbars" often includes features the intelligently add
items that aren't included by the author. For instance, a linkbar button
may be add for "http://whatwg.org" on a page with the url
"http://whatwg.org/specs/web-apps/current-work/". If there was such a
demand for this type of navigation, it would find its way into browsers
whether web pages supported <link> or not.

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

   Sadly, I am not familiar with all of the features of Safari.

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

   Native support, add-ons and plug-ins for <link> exist for nearly
every browser. Yet most people don't use them. The <link> element is
trivial to add, and most webmasters use them for CSS, yet most of them
use <link> for little else.

   There is no significant barrier to entry for this feature. It's a
problem of demand. RSS and Atom feeds originally required add-ons to
use. RSS itself, as I understand it, is horrifically fragmented into
dozens of incompatible versions. Yet, as of IE7, the vast majority of
browsers will support feeds natively.

   Earlier versions of Navigator and IE didn't support RSS any more than
<link>, and <link> has been a stable, unchanging standard for years. The
reason feeds won the race to browser integration is because users wanted
 feeds and not a linkbar.