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

[Matthew Raymond]

Sander Tekelenburg wrote:
> At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote:
[Snip!]
>>>>>> 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.

   ...Or behavior.

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

   This is misleading. A browser in not an implementation of TCP/IP.
Rather, the APIs it uses are. The actual implementation is written
against some very strict specifications and has to be to insure
interoperation with other implementations.

   HTML is deliberately flexible in how it can be interpreted to allow
a variety of implementations. However, it is strict when it has to be,
like how form data is submitted back to the server.

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

   If something is an implementation of a CSS property value, then it
has to work when you use that CSS property value. That's just common
sense. You can't call the XUL element <textbox> an implementation of
<input type="text">, because it isn't. It could be USED to implement
<input type="text">, but that doesn't mean it actually is one.

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

   So what you're saying is that "display: meta" will basically mean
"not presented in the body". This is not a presentation. It's the
exclusion of a presentation. It would be like me saying "everything
outside of that telephone both" is a location. It's not. The "telephone
both" is a location. "Everything outside" is the entire universe minus
the telephone both.

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

   User style sheets already let users decide what these pages look
like. What you're talking about is a CSS property value that lets the
user agent vendor determine the presentation and functionality.

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

   No. I'm suggesting markup that tells the user agent that certain
content is intended as list for commands and/or navigation. The user
agents may do as they see fit with this information.

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

   Why the obvious intent would be that <menu> could be rendered with
platform menu widgets, I do not believe that the intent is to make this
a requirement. User agents may do as they see fit.

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

   "Browsing environment's UI" is misleading. Do scrollbars count as
part of this? "Chrome", while sounding mildly visual, is nearly always
used to refer to elements of the user interface that are not part of the
document body.

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

   I don't see why not.

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

   If the user agent determines the appropriate presentation and
functionality, it's interpreting the meaning of "display: meta", and
that makes it semantic.

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

   We shouldn't create arbitrary restrictions for user agents simply
because we lack the creativity to come up with a design outside those
restrictions.

> "display in a consistent, user-agent specific manner, not a site-specific
> manner".

   So we're using "display: meta" to create a page style that says
"ignore the page style"?

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

   I agree that in-body implementations are unlikely, but if that's the
case, writing that into a specification would simply be redundant, since
the realities of the market would do far more to prevent it that any
spec would.

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

   This doesn't solve anything outside of the <nav> element. What
happens when you style a non-<nav> element as "display: meta"? Allowing
a CSS property to determine the children of an arbitrary element in the
DOM just doesn't make sense.

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

   Better yet, just replace "ul" with "menu" and forget the CSS. ;)

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

   Huh? In that situation, HTML markup would provide a solution, whereas
CSS would not.

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

   So you're pretty much making my case for me...

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

   Actually, I hear Flash is even less accessible than HTML, and forcing
people to something like Flash would just encourage Flash-only web
design, which is a real pain already.

   That said, there's really no reason why you couldn't build stuff like
simulated desktops already with HTML+JS+CSS. You just don't want to give
them the ability to make a text box look like a button and what not.
Navigational lists actually probably shouldn't be too heavily stylable,
except for maybe context and pull-down menus, and even that's debatable.

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

   I believe this is done in current CSS specs by providing specific
presentation details, then allowing user agents to ignore properties
when they have cause to do so. CSS provides presentational hints which
user agents can ignore if they have proper cause to do so (such as
operating system UI conventions).

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

   But CSS allows you do define which elements are presented as block or
inline, so I don't see your point. The properties in that particular
case are being defined as specific to certain CSS "display" property
values, not specific elements.

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

   http://whatwg.org/specs/web-apps/current-work/#the-nav

   From the spec:

| The nav element represents a section of a page that links to other
| pages or to parts within the page: a section with navigation links.
|
| When used as an inline-level content container, the element represents
| a paragraph.
|
| Each nav element potentially has a heading. See the section on
| headings and sections for further details.

   Doesn't sound like it's intended for lists only to me.

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

   It's a heck of a lot more likely with a CSS property, because all you
have to do to style something that's not a navigational menu is to get
the selector wrong. By contrast, if you're using markup to define what
constitutes a navigational list, the problem doesn't exist.

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

   The difference is that the author knows that when he/she uses
<title>, it's going to be displayed in a manner consistent with the
platform UI. By contrast, you do not know that the author of a specific
web page knows that the first <h1> element in the <body> will be styled
with "display: title" or some similar display type. This is because
multiple individuals may be working on content for a single site and
they may be using a single style sheet for all pages. This style sheet
may be changed without notice. As a result, you can't rely on the author
to be able to coordinate the style sheet with the content.

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

  The problem is that the markup has meaning, and this meaning is
potentially stripped from a user perspective when "display: meta" is
used, depending on the implementation. Granted, that's not such a huge
problem with this specific markup. Here's another example:

| <nav>
|   <h1>
|     <iframe src="header.html" width="200" height="10"></iframe>
|   </h1>
|   <ul><!-- List of links here. --></ul>
|   <ol><!-- List of links here. --></ol>
| </nav>

   What do you even do with the <iframe>? Use the non-existent contents
instead, thus yielding a blank header? And how would the header be
displayed? What effect does using an ordered list have? With something
like <menu>, you can define what elements can be children and have the
user agents ignore all inappropriate children. In that regard, you don't
have to define a behavior for every possible element of every language,
because many of those elements wouldn't be valid children anyways.

> (But
> I might be [misunderstanding] your example, given the closing ul lacking an
> opening ul. Typo?)

   In XML, <tag/> is the same thing as <tag></tag> with no inner
contents. I was using that to indicate that there was an unordered list
there without specifying the full markup for the list.