At 05:32 -0500 UTC, on 2006-01-22, Matthew Raymond wrote:
> Sander Tekelenburg wrote:
>> At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote:
[...]
> 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.
I wouldn't oppose that :)
Really, I don't care much about the means (other than that they'd need to be
realistic of course). It's the goal I care about. I coined a phrase
"display:meta" to give the means that I thought might work a name, and I
persisted in order for the discussion to make clear whether "display:meta"
would actually be that realistic means or not. Through the examples in your
last message you have convinced me that display:meta is not realistic. Thanks
for sticking with it and making that clear.
It still leaves the goal though...
[...]
>>> 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???
I was talking about nav {display:meta} suggesting that a browser presents nav
outside of the body, leaving up to the browser how to present markup that the
nav element contains.
Thus indeed:
> You're advocating a presentational property that _doesn't_
> determine the presentation.
You could call it that, yes.
[...]
>> 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.
I imagine it would be useful to display the address element in some
out-of-the-body manner as well. It's another one of those things that many
websites offer, but always presented differently.
[...]
>> 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?
Up to the browser vendor, but it could for example be something like Mac OS
X's sheets.
> What happens when a user thinks it's a popup and closes the navigational
> window?
The user wouldn't think that 'cause it would only pop up after a conscious
action - the user just clickety-clicked his browser's "navigation menu"
button.
Consider how selecting an Alternate Style Sheet or a User Style Sheet
instantly changes the presentation of the current Web page. That's the sort
of '1-click' change in presentation I mean. In fact, if CSS would allow you
to express that everything but some specific element should not be displayed,
then this whole thing could be achieved simply by switching Style Sheets. The
user could switch to a Style Sheet that shows only <nav> (or <menu>, or
<address>). A problem would then be that if the user would then activate some
link in a navigation menu, this User Style Sheet would still be applied to
that next page. So the browser would have to offer a 'non-persistent' Style
Sheet switcher - one that knows to revert as soon as the user goes to another
page.
> You also have problems with the window blocking the browser
> window, both the chrome and the actual document body.
I don't see why it would block the chrome. As to blocking the browser window:
I see only an advantage to that. When you want to view a page's navigation
menu you're not interested in that page's contents. It seems to me most Web
publishers feel that way, given how navigation menus are almost always
presented in a separate section.
> Furthermore, web
> authors would not take kindly to having their styling overridden in this
> window.
Author styling has and will always be no more than a suggestion. Nothing new
there.
> 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"?!?
No idea. These seem good examples of what's wrong with display:meta.
[...]
> 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.
You're right about <nav> of course.
Still I can't be that enthusiastic about having both a <nav> and a <menu> if
both are intended for navigational menus.
[...]
> 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.
Good example.
[...]
>> [author can't anticipate display:meta]
>
> (What's this about?!?)
That's snipping text and replacing it with a short summary. An attempt to
keep things readable.
[...]
>> 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?
Yes, in the sense that proper markup is required to indicate that something
is a navigation menu. But that does nothing for how that meaning is
communicated. Semantic markup is essential, but it is still always
*presentation* that communicates that semantic meaning to the user. <EM> by
itself indicates no meaning to the user. Only once its presentation is
affected (underlinging it, making it bold, speaking it somewhat louder), is
the meaning conveyed.
[...]
> 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.
:)
Agreed. Another good example.
[...]
>> 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.
Not at all. This was just a side alley. IMG requires ALT. IFRAME should also
require alternative content.
[...]
> 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'm not sure that would offer more than the REL attribute to A we already
have. User-agents could use that today to present such links the same way
they already present LINKs.
> 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.
Huh? You just pointed out that a nav might contain things (like Flash
objects) the user-agent might not be able to display in the chrome.
[...]
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
