[html5] <nav> for external links?

Bjartur Thorlacius svartman95 at gmail.com
Sun May 1 08:52:47 PDT 2011


On 4/30/11, Jacob Kristensen <admin at blueboden.com> wrote:
>> Navigation links link to resources related to the whole page, right?
> Not necessarily. Especially not in web pages, or applications.
>
> The individual page may have multiple sections, which are independent of
> each other. In which case you likely want to include such potential "see
> also" links, in a footer placed as a child to the relevant section.
>
>> What's your definition of a navigation link.
> Navigation links that i would markup using nav, would basically be anything
> but in-content links.
> If the links is a part of the content on the page, such as the "latest news"
> links on a front page of a news site, then i would limit the use of nav to
> site-section links. I.e. Sports, movies, tv, etc.
>
IMO everything only main content should go in body.

Quoting the W3C Editor's Draft:
| The body element represents the main content of the document.

Yet, a number of children (including nav, aside and figure) don't seem
to form a part of the main content.

> Another place where i wouldn't use nav, is for search results. I.e.
> Google/yahoo results page. And in the case of blogs, for the results on a
> "by tag" page.
>
>> 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.
> Don't hold me to it, but I'm fairly sure that this is in fact an un-intended
> "feature" thing, which is allowed by browsers that support custom elements.
>
> Normally unknown elements gets treated as empty span, if I'm not mistaken.
> What you are experiencing with the styling of title, is likely just an
> unintended side-effect of the possibility to declare your own elements using
> the display property.
>

> There are several reasons why you wouldn't style the head. For one, what
> purpose should it serve? The support of link for anything but StyleSheets,
> is rather limited. And i already explained why you wouldn't want to include
> links in the head section. I also personally think its a waste of time to
> discuss, because i know the thinking which lies behind (seen it elsewhere),
> but this will have to do for now.
>
Why would you put links that aren't main content in an element that
represents the main content of the document?

>> 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).
>
> This is a very bad idea, since it would servilely limit the customization
> that web designers and developers have come to love in recent years. There
> would be a lot of angry designers, asking why you stole their navigation
> column.
>
I think it's more important to keep users happy than letting designers
control every pixel on a user's screen. Users need customizability
more than designers.

How would a designer even know whether I render navigation links in a
column or a row?

> Another problem you would have to deal with, is the multitude of different
> layout techniques in use. Removing a navigation column from a website, would
> in many cases tilt the rendering, and might even make the site unusable in
> rare cases.
>
Existing pages will keep using <ul>. UAs won't even recognize the
lists as navigational.

> It may have its use for static documents however. Where the rendering is
> less important to the designer.
>
Authors' main concern is content. The user is most interested in the
content. Design is a question of accessibility, aesthetics and
branding, i.e. complementary to the content.



More information about the Help mailing list