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

[Matthew Raymond]

Sander Tekelenburg wrote:
> At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote:
> 
>> Sander Tekelenburg wrote:
>>> At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote:
> 
> [...]
> 
>>    So what you're saying is that "display: meta" will basically mean
>> "not presented in the body".
> 
> Well, in the sense that in most browsing situations that would probably be
> the consequence of presenting something as meta data, yes.
> 
> Remember that the idea is that authors/users can tell a browser to present
> certain data in a manner that is consistent across sites. In today's browsers
> I think that indeed would only be possible by presenting it outside of the
> body, because each site's body is unique and thus cannot offer such
> consistency.

   Requiring that the presentation be consistent is not the same as
defining the presentation.

>> 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.
> 
> Well, I suppose we could choose to instead define a value "chrome" for the
> display property. But I think that name doesn't convey the purpose as well.

   To be honest, even if I agreed with "display: meta" in principle, I
would not want the "display" property used for this purpose. In fact,
"position: meta" makes more sense.

> Also, it just might be that in the future we'll see a browser that works in
> ways none of us envision today, allowing it to offer such cross-site
> consistent presentation in the body. I'd rather define a value that makes its
> purpose clear, than one that assumes a certain environment.

   I don't know how you can't see that this is semantic. Someone
seriously needs to hit you with a clue stick.

>> What you're talking about is a CSS property value that lets the
>> user agent vendor determine the presentation and functionality.
> 
> No. Just the presentation.

   If the user agent is determining the presentation, what the heck is
CSS doing??? You're advocating a presentational property that _doesn't_
determine the presentation.

>>>>   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.
> 
> Ah, I see. Yes, I would agree with that. But I see display:meta as
> [1] an addition to that - a way to define in more detail how the user agent
> should present it
> [2] something that can be useful for more than just navigation menus

   You need to provide a clear use case where you'd want to use
"display: meta" in favor of something like HTML5 <menu> markup. I'm just
not seeing the use case here.

>> What happens when you style a non-<nav> element as "display: meta"?
> 
> The user-agent presents that element's data as if it were meta data.

   Then the elements wouldn't show up at all.

> This might sound like allowing a potential mess, but I think it doesn't have
> to. Suppose a user-agent would use a [separate] browser window for
> display:meta. It could render any content there as it can today; it could be
> made easy to find for the user (through a key combination, a menu item,
> whatever) and it could ensure consistent presentation across sites by
> applying the same dedicated Style Sheet to it always.

   Exactly how does that work with tabbed browsing, or multiple windows?
What happens when a user thinks it's a popup and closes the navigational
window? You also have problems with the window blocking the browser
window, both the chrome and the actual document body. Furthermore, web
authors would not take kindly to having their styling overridden in this
window. Then again, the special dedicated style sheet would be
meaningless for languages that are primarily presentational like SVG.

   Furthermore, how does "display: meta" apply for XML languages that
are actually used for the chrome itself, like XUL? What happens when I
style <xul:window> as "display: meta"?!?

>>>>   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.
> 
> Well, yes, but limited by the fact that HTML only affects structure and
> meaning/functionality. CSS can offer additional 'solutions', by affecting
> presentation.

   The author can always style an HTML5 <menu> element as he/she sees
fit and let the user agent decide what to do with the actual CSS
properties in a given context, so styling is not an issue. All "display:
meta" does is force us to require CSS support to allow cross-site
consistent navigational lists.

>>>> 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...
> 
> I don't think so. If I understand you correctly, you're saying HTML could
> define that user-agents may present NAV in a way that is consistent across
> sites, which would in effect result in allowing them to present NAV outside
> of the body.

   No, I'm saying that <menu> could be used to define navigational lists
that could be displayed in a consistent manner across websites. The
<nav> element doesn't allow for proper markup restriction.

> I agree with the semantics/functionality of that, but I think it isn't
> complete enough. It's a bit like HTML not specifying what font size must be
> used for some element, leaving that up to the user-agent. It's entirely
> correct for HTML to not deal with font size, but we *do* want to give authors
> and users a mechanism to affect it. Regard display:meta in that light -
> offering authors and users a mechanism to affect a presentation, instead of
> leaving it entirely up to the user-agent.

   HTML doesn't specify font sizing because HTML is supposed to be
semantic, while the font size is presentational. Furthermore, it doesn't
necessarily leave the font size up to the UA, because CSS may define
that font size.

   You're also ignoring the problem of how selectors interact with
"display: meta". Consider this...

HTML:
| <div id="test1">
|   <p>Testing 1... 2... 3...</p>
|   <menu id="menu1"><!-- Menu content here. --></menu>
| </div>

CSS:
| #menu1 { display: none; }
| #test1:hover #menu1  { display: meta; }

   When a person hovers the mouse over "Testing 1... 2... 3...", the
navigational content appears in the chrome, but when they try to use the
navigational content, the mouse exits the document body (or at least the
<div> element in question) and the navigational content disappears
before they can get to it.

   Similar selector-based problems like this could result in specific
navigational content only being being available when the certain
elements are selected or have focus.

>>> 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.
> 
> That's true. Thus any element could be set to display:meta, just like any
> element can be set to any other value of the display property. I still don't
> see how that would require any markup language to be aware of display:meta
> though.

   You claim that "display: meta" allows any number of presentations and
implementations, yet you fail to consider how specific UA decisions
regarding implementation may affect how markup is presented to the user.
Granted, for a specific presentation, such as your navigational
surrogate document window idea, it's less of an issue, but for others,
such as a menu system enhanced for a variety of multimedia content, it
becomes more difficult.

> 	[potential problems with child elements]
> 
>>    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.
> 
> I don't really see how "a section with navigation links" could be anything
> but a list with list items. (Of course a list item may in turn contain other
> elements, but I don't see a problem with that, as they still are part of a
> list's item.)

   There is nothing in the language that excludes non-link content, nor
does the language require list elements. In fact, it's not altogether
clear if a <nav> with no hyperlinks would be invalid.

> That NAV "potentially has" (shouldn't that be "may contain"?) a heading
> doesn't seem like a potential problem for NAV {display:meta} to me.

   But it does support the view that <nav> isn't limited to hyperlink
content.

> 	[author can't anticipate display:meta]

   (What's this about?!?)

>>> 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.
> 
> It's even simpler than that: no author knows what browsing environment the
> user will be using and thus what presentational possibilities are available
> even; no author knows whether CSS is available at all; no author knows how
> User CSS will affect presentation of his content. This is just a given for
> the Web. Authors need to be aware of. It means authors should simply never
> adjust their content to some assumed presentation.

   But if consistency of navigational links across websites is so
important, and CSS is so unreliable, wouldn't that naturally lead one to
conclude that markup is the proper solution?

> I don't see how this is any different for display:meta than for any other
> aspect of CSS. (But I have the feeling that this is irrelevant - that it just
> applied to me earlier not understanding what you meant with a HTML solution.)
> 
> [...]
> 
>> 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?
> 
> It would depend on the user-agent's implementation of display:meta. I would
> expect a user-agent that implements display:meta as a separate browser window
> would display the iframe and its contents.

   Oh, I can just imagine it now. The HTML document in the <iframe> has
elements styled with "display: meta", which in turn have <iframe>
elements containing "display: meta"-styled elements. Navigational window
explosion. I think you just invented another form of popup ad.

> Another might not be able to, and
> would present an empty heading (which might effectively be an invisible
> header). I don't think this is that different from an image without an ALT
> attribute. User-agents that can display the image will do so. Others will
> need the alternative content and can't do anything about it if the author
> didn't bother to provide that.

   Actually, I wasn't talking about <iframe> in the context of the
element being displayed in a surrogate document window for navigational
markup. I was thinking more along the lines of the data being integrated
into a UI that may not be so HTML friendly. In that situation, it
becomes difficult to see what you would do with an <iframe> and other
content. If you use a series of menus for "display: meta", how would a
Flash <object> be displayed? Should it be displayed if it can fit inside
the bounds of an OS or platform menu item? This kind of CSS property
usage spawns questions of presentation almost infinitely without
providing any real answers.

> Btw, I think this example mostly shows a problem with the current spec of
> iframe. How about WA1.0 redefine it to *require* (alternative) content?

   This should be an obvious weakness of "display: meta". It forces the
revision of HTML and other specs just so the markup is properly supported.

>> And how would the header be
>> displayed? What effect does using an ordered list have?
> 
> That it is presented as such? Really, I'm not sure why that would be a
> potential problem.

  It may not be, for your specific conceptual implementation. Once you
consider other potential implementations, you must consider how markup
is presented.

> Let's try to reach some sort of conclusion:
> 
> HTML 5.0 defines a NAV element to indicate a navigation menu which is allowed
> to contain (sectioned) lists of links, and which may be (should be?)
> presented in a manner that is consistent across sites.

   A better solution would be that HTML 5 should define a <menu> element
for navigational lists, which user agents may choose to implement as
menus or use some other interface that makes them available in a
consistent manner across websites.

   I think <nav> should stay the way it is, but user agents my chose to
implement it in a way that embeds it in the sidebar or something similar.

> CSS 3.0 defines a "meta" value for the display property, thus providing
> authors and users with a mechanism to suggest that a user-agent presents
> targeted elements as if they contain meta data, optionally (but in practice
> probably always) presented outside of the body, in such a way that it is easy
> for the user to access and is presented consistently across sites. Exactly
> how the *contents* of an element that is displayed "meta" are presented is up
> to the user-agent, allowing for a presentation that makes sense for a given
> browsing environment. (The spec could include a suggestion that a possible
> implementation would be a separate browser window, which the user may target
> with User CSS to effect his own preferred consistent presentation across
> sites.)

   One of the (many) problems I have with "display: meta" is that it
doesn't really take into account the semantics of the selected element.
The content could be totally unrelated to navigations and still be
transformed into some kind of external-to-the-document-body content.
Thus, we're allowing content to be integrated into the UI with no regard
for any kind of use case. The only serious use case I can think of would
be covered easily by <menu>, so I really don't see demand for something
like "display: meta" in the first place. In fact, the issue with <menu>
and <nav> shows that elements like these may have subtlely different
semantics that might result in different types of integration with the
user agent UI, so you'd actually have to have different "meta" types to
cover them all. Yet, then you may end up with a situation where certain
"meta" types favor a certain UI.

> Is this something we can agree on? (Aside from still having to discuss
> display:meta on www-style of course :))

   No. In fact, I've become convinced that you would never want to use
CSS to define presentation outside the document window no matter how
specific. It's too hard to spec, to restrictive for UA vendors, and
there's a lot of potential for abuse.