非正统使用html5 nav标签 [英] Unorthodox use of html5 nav tag

问题描述

我已经对新的html5元素进行了创造性的使用，有时会推动预期的界限。

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.

在链接到其他文章的情况下（实际上，带有摘录和分类辅助工具的标题），我决定只使用导航，因为缺少更好的元素，我知道这就变得棘手了。通常，nav旨在作为主导航的链接列表。好吧，点击相关帖子实际上是我网站（以及大多数Web 2.0网站）上的主要导航方式。它们也是链接的列表，除主链接外，它们还包含指向类别列表的链接，一个链接到作者的其他帖子，另一个链接到基于日期的存档。

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.

问题在于每页上有10多个这样的导航（不能将它们包装在相同的导航中，因为它们并非全部连续），这可能不是规范作者的意图 - 或者是它？

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?

代码验证得很好，分段也很有意义，但我想知道是否还有任何实际后果。我不希望该网站成为屏幕阅读器用户的新生儿，例如（otoh，如果它没有任何形象，我不想满足一个不存在的问题）。那么可能发生的最坏情况是什么？

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?

推荐答案

遵循HTML5规范允许各种用户代理呈现和使用文档和应用程序在作者可能没有考虑的各种情况下。 （ HTML5， Semantics 一些内容

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).

例如：

• 文章元素被定义为代表其他作品中的用户提交的评论。
  
  该规范甚至明确提到了博客帖子评论的情况，可以表示as article 元素嵌套在博客条目的文章元素中。

• 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.

并且不遵循此处的规范（不使用文章进行注释），您无法使用HTML5的其他功能或其扩展nsions，基于使用适当的元素。例如，如果您在文章中嵌套旁边的元素（代表注释）（应该这样做） ，因为它们与文章相关，而不是整个文件）：

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).

使用 nav 元素没有错（其实际定义相当广泛），我认为这会适得其反要做到这一点。

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.

如果链接与文章相关，则它们应嵌套在此<$ c中$ C>制品。在这里使用 nav 会传达错误的含义：它不是这个文章的导航，对吧？而不是 nav ，这里使用 抛开元素似乎是合适的。

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.

并考虑一下屏幕阅读器用户：他们可能会使用某个功能跳转到页面的导航（例如，获取网站的概述，了解可用的内容）。即使忽略了这样一个事实，即拥有多个分散的 nav 元素可能会使这一点变得更难，听一些（甚至不是全部）帖子的列表是多么有用，哪些通常比网站导航的理想长？最重要的是，这个导航甚至可能会在页面之间发生变化，因此用户必须一次又一次地执行此操作，跳过可能的重复项。

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 ：除非您有充分的理由，否则请遵循规范中的定义。更好地使用无意义的元素（ div ， span ，在某些情况下部分等）而不是重新解释根据其定义的含义或预期目的不能使用的其他元素。

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.

这篇关于非正统使用html5 nav标签的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！