[html5] <nav> for external links?

Sat Apr 30 09:00:10 PDT 2011

On 4/29/11, Jacob Kristensen <admin at blueboden.com> wrote:
>> So you're arguing that <head> should contain only <script>s and <style>s?
>> Information in <body> is highly context sensitive, but information in
>> <head> may be rendered before the <body>, after or injected into it. I
>> find
>> <head>
>> <link rel="related" type="image/jpeg" href=./complementary-image>
>> </head>
>> more logical....
>
> Head has other uses, and could have other uses in the future. But its just
> overkill to use for navigation links.
>
> Even links to related pages doesn't make sense to include in the head, as
> this would indicate that its related to the document or page as a whole,
> rather then the specific section otherwise indicated by using the relewant
> elements.
>
Navigation links link to resources related to the whole page, right?
What's your definition of a navigation link.

> In the case where the designers has chosen to make use of it, they would
> still have to include a normal navigation somewhere in the body, which would
> just double their work.
No, they shouldn't. That's unnecessary duplication.Back when I used
Webkit (as wrapped by surf) I had something like the following in my
style.css:
head, title {
	display:	block;
	[size, weight, position, etc]
}

You could easily apply the above to more descendants of <head>. I'm
not sure how to render empty elements such as <link> and <meta>,
though.

> Besides. You can't really control where the browser puts the information
> taken from the head. Say, if you have put some navigation links in the head
> section, you would likely still want to control where it should be placed
> visually on a page.
>
There's always CSS (I've only got Webkit at hand, but surely at least
Gecko allows <head> to be styled).

Navigation links most likely shouldn't be placed "on a page", but
provided out-of-band, or somehow differently from the main content of
the page. An interactive widescreen rendering might render links to
the right of the main content, with a separate scrolling mechanism (if
needed). A small-screen (interactive, visual) rendering might provide
the links only upon explicit request. The latter would also be
appropriate for people like me who can't concentrate when their screen
is full of information they don't need (ATM).

I think browsers and users should decide where and when to draw the
information provided by authors.

> So i really don't think its the best way to create links to related stuff.
> It may have its limited use in static documents, but using nav is likely
> better, if for nothing else, to at least maintain some consistency as of how
> things are done.
>
Please clarify or provide an example. Are you referring to the usage
of <link> as opposed to <a>?