非正统使用 html5 nav 标签答案

【问题标题】：Unorthodox use of html5 nav tag非正统使用 html5 nav 标签
【发布时间】：2015-06-28 02:21:42
【问题描述】：

我对新的 html5 元素进行了“创造性”使用，有时会稍微突破预期的界限。

像大多数人一样，我的网站主要由文章 cmets 和指向其他文章的链接组成。我决定只使用一次文章标签，所以没有任何混淆。对于 cmets，我使用的是 side 元素，我认为它符合定义 - 它与内容相关，但可以不使用它。

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

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

代码验证得很好，切片也很有意义，但我想知道这是否还有任何实际后果。例如，我不希望该网站对屏幕阅读器用户造成滋扰（otoh，如果它没有滋扰，我不想解决也不存在的问题）。那么可能发生的最坏情况是什么？

【问题讨论】：

HTML5 规范提到了 nav 元素，“该元素主要用于包含主要导航块的部分” – 请注意，它表示部分和主要导航块– 复数。没有人说页面上必须只有一个 nav 元素；如果这些指向其他文章的链接是在您的网站上导航的主要方式（并且以对此目的有意义的方式构建），那么我认为这没有任何问题。跨度>
“我决定只使用一次文章标签” – 你的意思是，即使页面包含多篇文章，你使用 article 只是为了其中之一，其余的不同标记？然而，恕我直言，这没有多大意义。
它不包含多篇文章（如果有的话，我当然会多次使用它），我所看到的“文章”由主要故事或帖子组成。有一些问题表明 cmets 甚至摘录也可能属于article，这就是我什至提出这个问题的原因。
如果每个页面只包含一篇文章，那么“每个页面上有 10 多个这样的导航” - 你是在说你定义为“主要” 导航，这里包含相关文章的链接吗？如果是这样，为什么需要拆分？
有一个主要的故事，“文章”，还有一堆相关的链接——“导航”。它们被分开是因为它们并不都在同一个地方——一些在文章之前（在同一类别中），一些在文章之后（上一个/下一个），一些在侧边栏上与其他元素交替等等。

标签： html nav semantic-markup

【解决方案1】：

我猜唯一可能发生的事情是网络爬虫（例如 googlebot）会将这些视为导航部分。只有当谷歌的某个人向我们透露一些秘密时，我们才能知道这究竟是什么意思……

需要考虑的事项：

阅读导航标签规范：

浏览器，例如残疾用户的屏幕阅读器，可以使用这个元素来决定是否省略这个的初始渲染内容。

对于文章的规格说：

一篇文章本身应该是有意义的，并且应该可以阅读独立于网站的其他部分。

可以使用元素的示例：

论坛帖子博客帖子报纸文章

所以.. 如果是我，我会将整个内容（所有文章）放在 <main></main> 标记中，并为每篇文章创建单独的 <article>。对于 cmets，我也会使用 <aside>，对于链接，我也会像您一样使用 <nav>，但也许其他人有更好的解决方案。

【讨论】：

【解决方案2】：

遵循 HTML5 规范允许各种用户代理“在作者可能没有考虑过的各种上下文中呈现和使用文档和应用程序”。 (HTML5, Semantics)。

如果您没有使用最具体的可用元素，或者如果您使用的元素不符合其定义，则某些用户代理可能无法完成他们的工作。

如果这些对您来说是“实际后果”，则无法回答，因为这取决于您关心什么，以及哪些用户代理会使用您的文档（这是不可能知道的）。

例如：

article element 被定义为代表“用户提交的评论”以及其他组合。
规范甚至明确提到了博客文章的 cmets 的情况，它可以表示为“嵌套在博客条目的 article 元素中的 article 元素。”

可以想象，例如，处理评论的用户代理会寻找（甚至依赖于）这个标记。

如果不遵循此处的规范（不使用 article 用于 cmets），您将无法使用基于使用适当元素的 HTML5 的其他功能或其扩展。例如，如果您将 aside 元素（代表 cmets）嵌套在 article 中（应该这样做，因为它们与 article 相关，而不是整个文档）：
- 您不能使用address element 提供article 作者的联系信息。如果您使用article（如预期的那样），则每个（这意味着原始帖子以及每条评论）都可以有自己的address。
- 您不能将 author link type 用于评论用户的网站，因为这适用于“最近的 article 元素祖先”（因此评论用户将被视为您帖子的作者）。
虽然将nav element 用于“相关链接”并没有错（它的实际定义相当广泛），但我认为这样做会适得其反。

如果链接与article 相关，则它们应嵌套在此article 中。在这里使用nav 会传达错误的意思：这不是article 的导航，对吧？而不是nav，这里使用aside element 似乎是合适的。

对于没有经典菜单的网站，分页通常是主要导航。

并以屏幕阅读器用户为例：他们可能会使用一项功能来跳转到页面的导航（例如，获取网站的概览，了解可用的内容）。即使忽略具有多个分散的nav 元素可能会使这变得更加困难的事实，听一些（甚至不是全部）帖子标题的列表会有多大用处，这些标题通常比网站导航的理想标题更长?最重要的是，这种导航甚至可能会在页面之间发生变化，因此用户必须一遍又一遍地进行，可能会跳过许多重复项。

tl;dr：除非您有充分的理由，否则请遵循规范中的定义。更好地使用无意义的元素（div、span，在某些情况下为 section 等），而不是根据其定义的含义或预期目的“重新解释”您无法使用的其他元素。

【讨论】：

我认为导航会被跳过而不是被跳过，因为在后一种情况下，这正是预期的用户行为......完成阅读并看看我们还有什么。如果导航是为了可预测性而在整个站点中保持不变，那么是的 - 这是一个很好的观点，但它不在规范中，â。他们最好把它放在那里，这样用户代理自己就知道要寻找什么。我正在尽我所能遵循定义，但也不想“把钱留在桌子上”，这就是我问的原因。当然，div 总是好的，但是丢掉几个小时的文档会很痛苦；）