[html5] <nav> for external links?

Bjartur Thorlacius svartman95 at gmail.com
Sun May 1 09:00:19 PDT 2011


On 5/1/11, Jukka K. Korpela <jukka.k.korpela at kolumbus.fi> wrote:
> Bjartur Thorlacius wrote:
>
>>> By definition, the <body> element is the entire document to be
>>> presented to the user, including any navigation, top banner, footer,
>>> and aside stuff. It's all there is, except that the <head> element
>>> contains _metadata_ that may affect _how_ the body is presented.
>>>
>> So you're arguing that <head> should contain only <script>s and
>> <style>s?
>
> I'm not arguing anything about that, simply citing the definitions. And I'm
> surely not arguing against the definitions; <title> is required and <meta>
> and <link> are allowed in <head>, but they do no constitute part of the
> visible document, by definition.
>
I can't speak for your UA's rendering, but on all mainstream
configurations the title is drawn on the screen, usually on the
topmost column.

Head is defined to contain metadata for the document. I consider
navigation links to be metadata. Sadly, metadata is ambiguous enough
for that to be debatable.

I don't think there's any definition for 'the visible document,' but
they're surely no more parts of the main content than navigation
links.

>> Information in <body> is highly context sensitive, but
>> information in <head> may be rendered before the <body>, after or
>> injected into it.
>
> Browsers are not expected to render the <head> part, and they don't. On some
> browsers this may be changed using CSS, but that is rather anomalous and
> does not make sense except in special situations.
>
Rendering (standard) next and prev links in the footer of a page makes
sense to me, and sequences of documents are quite common (and thus no
'special situation').

>> I find
>> <head>
>> <link rel="related" type="image/jpeg" href=./complementary-image>
>> </head>
>> more logical than
>> <body>
>> <aside>
>>  <img src="./complementary-image" type="image/jpeg" alt="">
>> </aside>
>> </body>
>
> There is no rel="related" defined even as proposed at
> http://microformats.org/wiki/existing-rel-values
> How logical can an element be when you apparently rely on the meaning of
> some attribute value with no defined meaning? Would it mean 'is related to'?
> Rather pointless, as linked resources are always supposed to be related -
> somehow.
>
Right, I just used related as I didn't find any standard rel value for
this relationship. The rel attribute is #IMPLIED in HTML 4.01, but
required by the W3C HTML5 Working Draft.

> If the image is supposed to be rendered as part of the document, it belongs
> to <body>, and its placement in the markup is supposed to specify the
> default placement.
>
What about images for which there is no "default placement"? News
articles often link to videos, pictures and illustrations that readers
may be interested in. They are related to the current page, but don't
form a part of it. Given enough screen estate, an UA may decide to
embed them into the final rendering - but whether to and where is up
to the UA. HTML5 suggests marking these up with a figure inside the
body, even though they shouldn't necessarily be rendered adjacent to
the surrounding nodes.



More information about the Help mailing list