[html5] <nav> for external links?

Brandon Hale absolutehalo at gmail.com
Mon May 2 08:28:24 PDT 2011

> Yes, if HTML were to be designed today this would probably be quite
> different. I don't think, however, that navigational links should be
> categorized with the main content of the page, nor necessarily
> presented directly to the user.

I'm having a hard time with the ideal that navigational links are not based
upon the content of the page. If, for example, the basic links of a brochure
site are "Home", "About", and "Contact" and I am currently on the "About"
page, at what point is the link not associated to the content?

> Any changes would have to be backwards compatible. Currently, you can
> simply omit the <head> opening and closing tags (in full conformance
> with HTML 4.01). You'll have a hard time renaming existing elements,
> in special considering that modern browsers might implicitly open
> <body> upon encountering the unimplemented element (potentially
> breaking assumptions).

The backwards compatibility issue is valid and it nullifies much of my
observation. Point taken.

> Well, you'll have to read threads of the WHATWG ML archives. There
> have been proposals for this.

Understood. I'll dig into those archives.

> AIUI, the doctype is a node in the DOM:
> Quoting http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1841493061
> > DOCUMENT_TYPE_NODE:   The node is a DocumentType.
> What exactly do you mean by "not direct html content?"

I placed "outside" in quotes hoping that statement wouldn't be taken
literally. I understand that <!DOCTYPE> is a DOM node. The observation was
more focused on the nodes behavior in the document. It works "behind the
scenes" and is a processing instruction not a "physical" HTML tag rendered
in the document (i.e. <head>, <body>, <nav>, <div>).

"Direct html content" was probably not the best set of terms to use. This
goes back to my prior observation. I see a real separation between what is
happening in <head> and what is happening in <body>. <head> and it's
children are not generally a part of the visible document. <body>, on the
other hand, deals with the content of the page, directly rendered by the
browser. <a>Home</a> is "direct", while <link rel="stylesheet" href="url" />
requires the browser to look elsewhere "indirectly" before it can bring in
what is being requested.

At any rate, I'm not sure I see a reasonable argument for altering <link />
to work like <a> when <a> creates the proper protocol for "linking" pages
together. To be honest, it feels like an over complication of the language
to suggest their is some issue in deciding whether one should define
navigation in <head> or <body> using <link> or <a>. I feel that the real
issue is wether or not the proper semantic names are being used at the top
level (i.e. <head> and <body>). Since backwards compatibility is as big of a
concern as it is I don't think there is a debate to be had about wether one
should create navigation in <head> or <body>.

Per the HTML 4 Specification:

"The HEAD <http://www.w3.org/TR/html40/struct/global.html#edef-HEAD> element
contains information about the current document, such as its title, keywords
that may be useful to search engines, and other data that is not considered
document content. User agents do not generally render elements that appear
in the HEAD <http://www.w3.org/TR/html40/struct/global.html#edef-HEAD> as
content. They may, however, make information in the
to users through other mechanisms."

"Data that is not considered document content" is the key phrase there, in
my opinion. From an information architecture standpoint, I don't see a
reasonable argument for navigation links not being document content.

I'll echo Mr. Hulse here and thank each of you for the valuable insight,
opinions, and observations made in this list. I am a better developer for
having been able to learn from each of you. Thank you all very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20110502/63e415d3/attachment-0002.htm>

More information about the Help mailing list