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

Tue Jan 10 12:26:19 PST 2006

Sander Tekelenburg wrote:
[Various "such-and-such wrote" lines removed for sanity.]
>>>>  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.
> 
> How? I don't see the HTML spec stating how rel or title attributes must be
> presented.

   The spec fails to REQUIRE what the implementations do, but it does
not PROHIBIT what the implementations in question do. They don't
suddenly not become implementations of the attributes just because the
spec doesn't explicitly say they can work in a particular way.

>>   Until I can turn items into metadata using "display: meta"
> 
> Nit-pick: you will never be able to do that. Just like P {display:list-item}
> doesn't change a paragraph into a list item. It is only *presented* as a
> list-item - it still is a paragraph.

   Then you will be requiring user agents to have a specific and well
defined presentation of elements styled with "display: meta"? I'm not
sure how pleased browser vendors would be to have portions of their
browser GUI defined in a spec...

>>[...] you're mixing semantics with presentation
> 
> I am? How? Hoe is the idea of display:meta (present non-meta data as meta
> data) different from display:table (present non-tabular data as tabular data)?

   The "display: table" style and other tabular "display" values have
well defined presentations. If "display: meta" were to have a similarly
specific presentation, you'd essentially be dictating user agent GUI.
This is a serious problem, because it could be theoretically in conflict
with the standard user interface guidelines for the platform UI.

>>>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".
> 
> Except that that still requires some in-body mechanism, probably requiring
> space and definitely being different on every site, to change that content to
> a 'visible' state. The point of display:meta is that instead the data can be
> presented in a manner that is consistent (for that user-agent) at every site.
> (And that therefore it would need to waste less space.)

   This can be done with new HTML markup.

>>>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.
> 
> How does an end-user control the presentation of any site through 'DHTML'?
> Does the ECMA standard define that users can override author javascript with
> their own?

   Well, in theory you could use a combination of CSS, XBL, HTML and
Javascript to allow the end user to control presentation, but I see your
point. However, as I have stated, we can create an HTML-based solution
to solve this problem.

>>Just because something's in the
>>chrome doesn't mean that you can't do the exact same thing in the <body>.
> 
> Could you share what you mean with "the chrome"? This discussion is the first
> time I hear it used and from the context it is not getting entirely clear to
> me what you mean with it.

   "Chrome" is the GUI of a user agent that is not part of the page
body. The status bar, menus, toolbars, et cetera are all "chrome".

>>>(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.
> 
> Exactly how can markup solve this? I think we're talking about presentation,
> which is not the realm of HTML (which is why I agree this is somethin for
> www-style).

   No, you're talking about presentation. I'm talking about a general
"menu" solution that user agent vendors may or may not choose to make
part of the UA chrome. Let the vendors decide how it works or what it
looks like. A compliant implementation could possibly even be in-body.

>>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?
> 
> Exactly that. The menu would be presented in-body, making the 'page' 5 times
> bigger. So what? Today's pages *are* 5 times bigger.

   I'm not saying that in this scenario it's five times bigger simply
by virtue of it being in-body. I'm saying that the web author may never
have bothered to style the "menu" content for in-body presentation in
the first place, thus resulting in content in-body that is presented as
a massive, unstyled mess.

   With an HTML solution, we avoid the how scenario.

> The same thing would happen in any user-agent that doesn't support
> display:meta.

   (That reminds me. Some user agents don't support CSS...)

> This is nothing new. Not every browsing environment can present
> everything the way another browsing environment can. Not every browsing
> environment can display "tooltips", for example. This is the entire point of
> the Web - being able to exchange content and its meaning, regardless of the
> end-user's browsing environment's capabilities.

   If we reuse <menu> for navigational lists in HTML5, we can just style
<menu> for user agents like IE6. That way, if a legacy browser supports
CSS, we have fallback styling that can reduce the size of the
navigational markup on the page and position elements to use up less
space. By contrast, for "display: meta", you have to double-declare the
property for legacy browsers:

| display: block;
| display: meta;

   This, of course, will do nothing for HTML5-compliant browsers that
don't support "display: meta" at all.

>>>>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.
> 
> But that approach makes (keeps) users dependant on authors' javascripts.

   Which is why an HTML solution would be better than DHTML.

> Authors who cannot even know what UI to simulate for a specific end user.

   I assume you mean that a DHTML control may not conform to the user
agent or operating system UI standards. Yet this is exactly why
"display: meta" is inappropriate as well: you have to provide a
well-defined presentation. If a web author can't create a DHTML widget
that's presented correctly for all user agents and platforms, how will
CSS spec writers accomplish the same thing?

   In the end, this means that "display: meta" can't have a specific
presentation, and that user agents have flexibility in determining the
behavior and presentation (which is at the very least required to
conform with the native UI guidelines). As a result, you essentially
have a CSS property that gives <link> semantics to other HTML elements.

>>In fact, the other day I saw a page
>>that emulated the Windows XP desktop.
> 
> Which would be a confusing UI for a user who is used to another UI.

   That makes no sense. The whole point is to emulate another UI so that
the user can experience what it's like to use the Windows XP desktop.

   Non-semantic interface solutions, however, can be difficult to
maintain with regards to usability. Sometimes web authors have to make
square pegs fit the round hole, though, to achieve the desired effect.
That is, of course, why we're here in the first place: to create the
square hole.

> It would
> also not allow for the consistent presentation on different sites, as this
> still depends on every site implementing its own UI.

  (It's important for people reading this message to note that we're
talking about consistency across sites within a single browser on a
specific platform, not consistency across browsers. For instance, how a
page looks when using chrome-based navigation on my Internet-capable PDA
may not have the same user agent UI as the same page viewed on a desktop
browser. In fact, we may want it deliberately so due to space
considerations.)

> Plus it would simply not
> be possible to do this in every browsing environment - think of text-only
> browsers, a speaking browser, a braille browser, etc. Things like this should
> be left up to the user. Something along the lines of this display:meta idea
> seems to me to be more likely to make that possible than 'author-side'
> javascript.

   Again, I believe you are correct in that a non-DHTML solution is
needed, but I do not believe "display: meta" can ever be implemented
realistically in a purely presentational manner. As a result, HTML
markup is a more appropriate solution.

>>   Doubt it. All I see are a bunch of complex rules on how to process
>>the children of a "meta" element.
> 
> That depends on what type of elements a spec would allow display:meta to
> apply to.

   In other words, HTML and every XML language in existence would have
to define what elements "display: meta" applies to. Not a good solution.

> For the moment I am only thinking about the NAV element Ian
> proposes, which it seems would only contain what are essentially list items,
> possibly organised in sub lists.

   What would be the error handling for this, then? The elements don't
display at all? Does <nav> even have a limitation on what the children
can be?

> If you'd want to allow display:meta on other types of elements (I haven't
> given it much thought, but address {display:meta} might be useful for
> instance), yes, it might require thought on how to treat children. (But I
> can't think of a good example where that would be a problem. Can you?)

| <nav>
|   <p><img src="image.png" alt="[navigational header]"></p>
|   <ul/>
| </nav>

   That and every other possible permutation you can think of. For
"display: meta" to work well with <nav>, the element would have to be
designed specifically for it. Unfortunately, I doubt the same would
happen with other languages that might use CSS for styling.

>>>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?
> 
> Why allow display:list-item or display:table on objects that aren't lists or
> tabular data? Because there is often a difference between what something
> *is*, and what would be a useful presentation of it.

   Again, this means that user agents would have to implement specific
UI for "display: meta". This may conflict in some cases with the
platform UI standards and guidelines.