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

[Sander Tekelenburg]

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

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

Agreed. That's because HTML defines structure and meaning/semantics, not
presentation. In that sense you're right that presenting a title attribute's
contents in a "Status Bar" would be an implemantation of HTML - but merely in
the sense that it makes that content accessible. But that seems a bit like
saying it is an implementation of TCP/IP. It's true of course, but rather
broad. More minutely would be saying that such a presentation is an
implementation of display:meta because only *then* do you refer to the
detailed aspect of the presentation method.

[...]

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

No, absolutely not. The entire point would be that user-agents would have the
freedom to decide for themselves what sort of presentation of display:meta
would be appropriate. Exactly because different presentations will be best
for different browsing environments. (It would be good if the spec would
mention some examples of possible implementations, but only to convey to
browser developers that they are to take the freedom to implement this in a
way that makes sense to their specific browsing environment.)

> I'm not
> sure how pleased browser vendors would be to have portions of their
> browser GUI defined in a spec...

Indeed. In no way do I mean to go in that direction. Quite the contrary. In
the *current* situation a Web page's navigation menu can look entirely
different from a given UI's convention. The "display:meta" I envision would
allow user-agents to present such a navigation menu in a manner that is
consistent with the browsing environment's UI - whatever that is. (The goal
being that the navigation menu would become easier to find and use for end
users than is currently possible.)

[...]

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

I don't see how. Surely you're not proposing that HTML should start dealing
with presentation again? (I haven't said anything about it yet, but some of
the proposed HTML for "menu" that I've seen floating by in this discussion
gave me the impression that that indeed is the direction it is heading in,
which quite surprised me - not to say scared me. I'm hoping I just
misunderstood.)

[...]

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

Hm... OK. I think I would prefer to refer to that as "the browsing
environment's UI". If only because that doesn't limit itself to graphical UIs.

Does "chrome" also indicate non-graphical UI aspects? (Think of a cli
browser, a braille browser, a talking browser, none of which would (have to)
have such graphical UI elements as "toolbars" or "menubars".)

[...]

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

Yes, but only up to the point of display:meta defining that something is to
be presented outside of the body. Beyond that, it's up to the user-agent.

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

Well, not for display:meta of course. But I do agree that the point of
display:meta would be to allow a user-agent to present something in a manner
consistent among different websites. In that sense, yes, if that can be
achieved through in-body presentation, that would be fine. (I just don't
think it *can* be achieved that way.)

If we'd want to take that road, display:ua (user-agent) might be a more
appropriate name. Its meaning would then be something along the lines of
"display in a consistent, user-agent specific manner, not a site-specific
manner". But I'd expect an in-body implementation of this would be a much
harder approach to achieve, if only because then the user-agent would have to
style some part of the body in a way that will conflict with the rest of the
body. Removing it from the body, which display:meta would 'do', seems more
realistic to me.

>>>What happens if
>>>I use "display: block" in my user stylesheet to override the "meta"
>>>value

[...]

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

Yes, but that's a much more general 'problem' because it applies to *any*
styling already anyway as even today there is no guarantee that a user-agent
will support any CSS (or even inline images). Just browse today's Web with
CSS disabled and *many* sites will look a complete 'mess' (especially those
relying on 'DHTML'). That's not CSS' fault. It's the authors' fault of making
CSS-dependant sites.

[...]

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

If a NAV element would be allowed only to contain a UL element, that would
solve a legacy browser support issue, wouldn't it? Antiques would ignore the
NAV element and just render the UL and its contents.

Better yet might be to not introduce a new nav element at all, but to go no
further than introducing a nav property for UL? (Or maybe no "navigation
elements/attributes" at all, given that the entire idea appears to be quite
presentational.)

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

True. But given that authors cannot rely on CSS support anyway that seems
irrelevant to me.

[...]

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

Yes.

> Yet this is exactly why
> "display: meta" is inappropriate as well: you have to provide a
> well-defined presentation.

No, quite the contrary, this should be left up to browser developers
themselves as that would be the only way to guarantee a presentation that is
consistent with the browsing environment's UI (and, due to that, consistent
across sites).

For the same reason I don't see a problem leaving this up to browser
developers. They will know what the correct presentation would be in their
UI. The only thing a spec would have to say about display:meta is [1] that
the content it targets should be presented outside of the body and [2] in a
manner that is consistent with the browsing environment's UI (and thus
consistent across different sites).

[...]

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

Exactly.

>  As a result, you essentially
> have a CSS property that gives <link> semantics to other HTML elements.

No :) CSS doesn't affect semantics, just presentation.

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

That might be a useful application for 1 or 2 websites that are about
demonstrating the WinXP desktop. But we all know that there are webdevelopers
out there who love to try to force their site's presentation to be just like
the one environment *they* happen to be comfortable with, ignoring that it
would confuse the hell out of many other people. HTML/CSS should not cater
for such authoring. Authors who want that sort of control should use other
techniques, like Flash.

>    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 depends on the square peg. We should not want to give authors tools to
force presentations on users.

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

Indeed. (I was struggling finding the right word. Indeed "across" is what I
meant. I'll try to stick with that :))

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

Right.

> due to space considerations.)

For example, yes.

[...]

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

I can't follow. Today's CSS specs already define such limitations, don't
they? Some apply to block level elements only, some to positioned elements,
etc. A CSS spec would only have to define to what sort of elements
display:meta applies. Markup languages don't need to be aware of that.

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

Given that it appears to be meant as a list, I'd expect it to only allow list
items. You're right though that a problem might exist with what list items
are allowed to contain.

Still, I'm not sure how real that problem might be in practice. In theory a
nav element's list items might contain <P>s with a lot of text. That could be
a problem for a user-agent (depending on its display:meta implementation).
But how likely is it that an author would do such a thing in a navigation
menu? Isn't this comparable with the fact that the HTML spec doesn't define a
limit for the length of a title attribute, but that in most browsing
environments there *is* a limit on the amount of text that can be rendered
through a Tooltip? In other words, does this really *need* to be defined, or
would it be reasonable to leave some level of responsibility to the author
here?

Also, as I've mentioned before, I can imagine an implementation consisting of
presenting display:meta in a separate browser window (maybe 'hiding' the
current one - which would re-appear when a menu item is activated by the
user). It would still offer the advantages of allowing (albeit possibly
slightly less) consistent presentation across sites and being easy to find
for users.

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

I'm not sure this would be a problem. One browsing environment might choose
to present the image, another might choose to only present the ALT text. (But
I might be misunderstaning your example, given the closing ul lacking an
opening ul. Typo?)

[...]

> For "display: meta" to work well with <nav>, the element would have to be
> designed specifically for it.

I agree that *if* that is the case, it might well be a problem. I'm just not
convinced that it *is* the case :)


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