Unorthodox use of html5 nav tag

Question

I have made "creative" use of the new html5 elements, sometimes pushing the intended boundaries a bit.

Like most, my site is mainly made of articles comments and links to other articles. I decided that I'd use the article tag just once, so there's no confusion whatsoever. For comments, I'm using the aside element and I think that it fits the definition - it's related to the content but it can be done without.

In the case of links to other articles (actually, titles with excerpts and taxonomy aids), I've decided to just use the nav, for lack of a better element, and I know that this is where it becomes tricky. Normally, nav is intended as a list of links for the main navigation. Well, clicking on related posts actually is the primary means of navigation on my site (and most web 2.0 sites). They're also a "list" of links, as beside the main link they also contain a link to the category listing, one to the author's other posts and one to the date-based archive.

The issue is that there are 10+ such navs on each page (can't wrap them in the same nav as they're not all consecutive), which was probably not intended by spec authors - or was it?

The code validates just fine and sectioning makes sense as well, but I wonder if there still are any practical consequences to this. I don't want the site to be a nuissance to screen reader users, for example (otoh, if it's no nuissance, I wouldn't want to cater for a problem that doesn't exist either). So what is the worst that could happen?

Answer 1

Following the HTML5 specification allows various user agents to "present and use documents and applications in a wide variety of contexts that the author might not have considered." (HTML5, Semantics).

If you’re not using the most specific elements available, or if you’re using elements not according to their definitions, it’s possible that some user agents fail to do whatever their job is.

If these are "practical consequences" for you can’t be answered, because it depends on what you care about, and on which user agents do and will consume your documents (which is impossible to know).

For example:

• The article element is defined to represent, among other compositions, a "user-submitted comment".
  The spec even explicitly mentions the case for a blog post’s comments, which could be represented "as article elements nested within the article element for the blog entry."

  It is conceivable that, for example, a comment-processing user agent will look for (or even depend on) this markup.

  And by not following the spec here (not using article for comments), you can’t use other features of HTML5, or its extensions, that are based on using appropriate elements. For example, if you’d nest your aside elements (representing the comments) in the article (which should be done, as they are related to the article, not the whole document):

  • You could not use the address element for providing the article author’s contact information. If you’d use article (as intended), each one (this means, the original post as well as each comment) could have its own address.

  • You could not use the author link type for the commenting user’s website, as this applies to the "nearest article element ancestor" (so the commenting users would be considered authors of your post).

• While using the nav element for "related links" is not wrong (its actual definition is pretty broad), I think it’s counterproductive to do this.

  If the links are related to the article, they should be nested in this article. Using nav here would convey the wrong meaning: it’s not the navigation for this article, right? Instead of nav, here using the aside element seems to be appropriate.

  For sites that don’t have a classical menu, the pagination is typically the primary navigation.

  And think for example about screen reader users: they might use a feature to jump to the page’s navigation (e.g., to get an overview of the site, to learn what is available). Even ignoring the fact that having multiple, scattered nav elements might make this harder, how useful would it be to listen to a list of a few (not even all) post titles, which are typically longer than what’s ideal for a site navigation? And on top of that, this navigation likely even changes from page to page, so the users would have to do it again and again, skipping through possibly many duplicates.

tl;dr: Unless you have very good reasons, follow the definitions from the spec. Better use meaningless elements (div, span, in some cases section, etc.) instead of "reinterpretting" other elements which you can’t use according to their defined meaning or their intended purpose.

Answer 2

I guess the only thing that could happen is that web crawlers (such as googlebot) will treat those as navigation sections. what the actual meaning of this we could only tell if someone from google will reveal to us some secrets...

Things to consider:

Reading the nav tag specs:

Browsers, such as screen readers for disabled users, can use this element to determine whether to omit the initial rendering of this content.

for article the specs says:

An article should make sense on its own, and it should be possible to read it independently from the rest of the web site.

Examples of where an element can be used:

Forum post Blog post Newspaper article

So.. If it was me I would put the whole thing (all articles) inside <main></main> tag and create separate <article> for each article. for the comments I would use <aside> too, also for the links I would use <nav> just like you did, but maybe someone else have better solution.