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

[Sander Tekelenburg]

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.

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

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.

[...]

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

[...]

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

[...]

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

This might sound like allowing a potential mess, but I think it doesn't have
to. Suppose a user-agent would use a seperate 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.

[...]

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

[...]

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

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.

So I think we need both. The HTML you propose, and display:meta to give
authors and users a mechanism to affect its presentation. (See also the
conclusion at the end of this message.)

[...]

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

[...]

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

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.

[...]

	[author can't anticipate display:meta]

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

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

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?

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

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

Agreed.


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.

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

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


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