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

Mon Jan 9 16:31:10 PST 2006

At 15:39 -0500 UTC, on 2006-01-09, Matthew Raymond wrote:

> Sander Tekelenburg wrote:
>> At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:
>>>Sander Tekelenburg wrote:

[...]

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

> Even if they were implementations of "display: meta", this
> is not the correct forum. The W3C www-style mailing list is.

Yes, I will be coining the idea there.

[...]

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

> [...] you're mixing semantics with presentation

I am? How? Hoe is the idea of display:meta (present non-meta data as meta
data) different from display:table (present non-tabular data as tabular data)?

[...]

>> A "LINKs Toolbar" ("navigation method" would perhaps be a better term, as it
>> is less implementation-specific) could be hidden by default and presented
>> only when needed.
>
>    So could anything else using the style "display: none".

Except that that still requires some in-body mechanism, probably requiring
space and definitely being different on every site, to change that content to
a 'visible' state. 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.)

>> Like what I mentioned earlier for mobile devices. That way
>> such a navigation aid would not take *any* space, unless needed - and it
>> could take *all* space, when needed. I don't see how you could achieve that
>> with in-body presentation.
>
>    This is a simple matter of DHTML.

How does an end-user control the presentation of any site through 'DHTML'?
Does the ECMA standard define that users can override author javascript with
their own?

> Just because something's in the
> chrome doesn't mean that you can't do the exact same thing in the <body>.

Could you share what you mean with "the chrome"? This discussion is the first
time I hear it used and from the context it is not getting entirely clear to
me what you mean with it.

>> (In fact, it is the very fact that it would be the
>> same on every site that makes this possible, because only that allows for
>>the
>> user to know it exists even when it isn't shoved in his face. With in-body
>> presentation that's impossible - every site being different, in-body
>> presentation requires in-your-face presentation.)
>
>    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).

> For instance, what
> happens if I use "display: meta" in my user style sheet?

Assuming your user-agent supports it, it will present the element you
targeted as if it were meta data, instead of in-body.

(Sure, I can see that this will affect presentation of the rest of the body's
content. Just like display:none does.)

> What happens if
> I use "display: block" in my user stylesheet to override the "meta"
> value, and it ends up making a page five times bigger because it has a
> complex menu system?

Exactly that. The menu would be presented in-body, making the 'page' 5 times
bigger. So what? Today's pages *are* 5 times bigger.

The same thing would happen in any user-agent that doesn't support
display:meta. This is nothing new. Not every browsing environment can present
everything the way another browsing environment can. Not every browsing
environment can display "tooltips", for example. This is the entire point of
the Web - being able to exchange content and its meaning, regardless of the
end-user's browsing environment's capabilities.

>>>If that's true, then there's a serious problem with CSS.
>>
>> I can't follow.
>
>    CSS (in combination with HTML and Javascript) is more than flexible
> enough to simulate virtually any UI.

But that approach makes (keeps) users dependant on authors' javascripts.
Authors who cannot even know what UI to simulate for a specific end user.

> 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. It would
also not allow for the consistent presentation on different sites, as this
still depends on every site implementing its own UI. Plus it would simply not
be possible to do this in every browsing environment - think of text-only
browsers, a speaking browser, a braille browser, etc. Things like this should
be left up to the user. Something along the lines of this display:meta idea
seems to me to be more likely to make that possible than 'author-side'
javascript.

[...]

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

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

[...]

>> It would allow authors to provide 1
>> single navigation menu, not having to worry whether a user-agent supports
>> display:meta (like authors need to with LINK), and it would allow both
>> authors and users (and browsers' built-in Style Sheets) to present that
>> outside of the body, and thus consistently.
>
>    Why not just have menus, then? Why mix presentation with semantics at
> all?

Why allow display:list-item or display:table on objects that aren't lists or
tabular data? Because there is often a difference between what something
*is*, and what would be a useful presentation of it.

[...]

>> Btw, that reminds me of something Apple did that I think confirms my idea
>> that people find it hard to navigate the Web: Safari's SnapBack function
>> targets exactly that issue.
>
>    Sadly, I am not familiar with all of the features of Safari.

Safari's "SnapBack" is probably best described as a temporary bookmark. It
lets you mark the current page and later (during the same browsing session)
jump back to it. It is useful for instance when browsing a search engine's
results, getting lost, and wanting to return to that search engine's results.
IIRC (I don't use Safari) it is presented as a single button. The first click
marks the current page, the second click takes you back there.

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