[html5] <nav> for external links?
Bjartur Thorlacius
svartman95 at gmail.com
Mon May 2 14:04:43 PDT 2011
On 5/2/11, Brandon Hale <absolutehalo at gmail.com> wrote:
>>
>> 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?
>
I'm sorry, I don't understand you (I'm Icelandic and thus don't
read/write English natively, etc). The navigation links and the main
content would be bundled in the same document (although that doesn't
seem like a feature to me as the links would be shared between the
three pages) and most likely rendered side by side. There's definately
an association. But navigation links and main content are not the
same, and shouldn't be treated as such.
>> 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.
>
Not opening head and body explicitly is a personal preference, of course.
>> 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.
>
Good luck!
>> 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>).
>
Ah, I understand you. I think the <!> tags are defined by SGML (or
were, as HTML5 isn't a SGML language anymore), but processing
instructions can truly be used for information as to how the document
should be processed and presented, i.e. that information that's
neither main content nor tangential content/head-like metadata, as you
recognize from XML:
<?xml-stylesheet href="/styles/dark"?>
A processing instruction might in fact be even "saner" (to keep my odd
terminology) for @rel=next links if you think of them as effectively
merging the linked documents.
> "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.
>
The difference you observe seems to be the difference between
hyperlink and external resources (as defined by the HTML5 drafts)
rather than a inherent property of <link> and <a>. <Link rel=next> for
example causes the creation of a hyperlink, for example, whereas <link
rel=stylesheet> causes an external resource.
> 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>.
>
I do now (mostly) agree. As navigation links can evidently apply only
to a single section of a document, using a at rel={next,prev} as a (last)
child of the element it applies to (and body if it applies to the
whole document). I don't understand how directional navigation links
(next/prev) that apply to a section only should be rendered, so I'll
render them the same way as any other hyperlink until browser devs
come up with a better rendering. Concatenation is the obvious choice
for the others.
As for navigation links of the type you're talking about: IMO they
should be put in a seperate file (either text/uri-list or text/html)
referenced from each document. These links would then be put at the
end of aural/speech renderings, in a seperate box/frame/window/screen
on screen and tty, available upon request on handheld and tv and
omitted in projection and print (and probably in embossed renderings).
An experienced braille user would come up with suitable rendering for
that CSS media type. Then if a "Staff" page is added to the site, you
don't need to redownload anything but the navigation links. These
things are currently usually cached by a reverse proxy on behalf of
the server.
This would of course not be worth it for a brochure site (where it
would only serve to increase HTTP overhead), but might make sense on a
news site, with large articles and long, categorized and fast-changing
navigation links. Or am I overgeneralizing the concept of navigation
links, and each document should contain navigation links to "About,"
"Domestic news," "Scandinavian news" and "Rest of the world" (where
the latter two would be lists of links, and "Domestic news" would be
the empty document)? Visual renderings where paper/screen estate is
cheap enough could of course include related documents in the
rendering of one of them. The important thing to me is that the markup
allows for such unusual renderings the author may or may not have
thought of.
> 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
> HEAD<http://www.w3.org/TR/html40/struct/global.html#edef-HEAD>
> available
> 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.
>
Well, I consider navigation links the same way as titles and
descriptions: they can come in handy, but aren't main-content.
Take a YouTube video description page (e.g.
http://www.youtube.com/watch?v=_U0UaRYXwBQ&feature=topvideos_music).
The HTML document contains comments, a title, a description, a list of
related videos, a form and links to misc. YouTube sites (home, about,
copyright, TOS, etc). All metadata about the video, or about YouTube.
The data about the video is the main content of the document, but the
data about YouTube is not, and should thus be in head - to make it
clear which resources are actually related to the video, and which
ones are related to YouTube only. Think <link rel=license>.
> 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.
>
Echo and out, thank you all for the remarks and for setting me straight.
More information about the Help
mailing list