在 HTML5 中，可以嵌套 NAV 元素吗？答案

【问题标题】：In HTML5, can you nest NAV elements?在 HTML5 中，可以嵌套 NAV 元素吗？
【发布时间】：2011-10-22 15:08:49
【问题描述】：

我有一个站点范围的主菜单，我目前正在使用<nav>。我还有一个子菜单，它位于主导航下方，并且对于网站上的每个产品都不同。处理此问题的最佳做法是什么？

目前，我在主导航下方有一个单独的<div id="secondary-nav">。但由于它们都在页面的<header> 内，我正在考虑使用嵌套的<nav>。这在 HTML5 中是否可行？

【问题讨论】：

NAV元素的内容模型是Flow content，NAV元素本身就是Flow contentSource.
@Jam "NAV 元素的内容模型是 Flow 内容" = NAV 元素可以包含定义为 Flow 内容 的元素。由于 NAV 元素本身被定义为 流内容，这意味着 NAV 元素可以包含 NAV 元素。
对不起。我不是故意听起来那么刺耳的。我想知道什么是“流动元素”。它是块元素，而不是display: inline，还是position: static，而不是position: fixed。基本上，流元素是否有助于页面的流动？
@JamWaffles - “什么是流程元素”解释起来并不简单。它可能需要一个单独的 SO 问题。
哦，好的。那我就这样吧:-)

【解决方案1】：

目前规范中没有任何内容表明不允许嵌套navs。并且看到<nav>是块级元素，嵌套它们没有错。

【讨论】：

【解决方案2】：

在那里使用nav 是完全可以接受的。如果可以删除，您可能还想查看aside，或者查看在nav 中使用section 标记以更好地划分内容。这又回到了整个语义辩论，我的立场是，如果有意义，就去做。它不需要在语义上 100% 正确，因为除了查看源代码的人之外，没有人会知道。

【讨论】：

语义的重点不是要有好看的标记，而是为标记添加额外的功能。通过创建语义标记，您正在构建一个可以被屏幕阅读器、搜索引擎等普遍理解的结构。
@thirdender 我同意标记应该是正确且实用的，但是看起来不错的标记通常在技术上也可以（“如果看起来不错，它会飞得很好。”）。毕竟，标记语言意味着人和机器都可读。
是的。我想我想说的是（在一年后重新阅读我的评论之后：-p）是语义是关于增强标记的含义。如果语义无关紧要，那么 <div> 和 <nav> 都同样“可读”。我们在某些地方使用<nav> 的原因是为了增强该部分标记的含义。如果做得好，搜索引擎和可访问性技术会提高对页面内容和结构的认识。搜索引擎“啊哈！导航”，屏幕阅读器宣布“这里有一个菜单”。
是的，语义是关于增强意义的。但这种认为它可以被普遍理解的想法与现实相去甚远。在现实屏幕阅读器中，搜索引擎等已经开发了自己的 HTML“扩展”，并结合自己的技巧来使用它（例如 ARIA 角色、微格式、sitemap.xml 等）来解释标记。它们几乎不依赖元素的语义，因为它经常被错误地使用。事实证明，最初的评论“除了查看您的来源的人之外，没有人会知道”实际上非常接近事实。
这是不正确的，没有回答问题。