我应该在 <nav>s 中使用 <ul>s 和 <li>s 吗？答案

【问题标题】：Should I use <ul>s and <li>s inside my <nav>s?我应该在 <nav>s 中使用 <ul>s 和 <li>s 吗？
【发布时间】：2011-07-29 12:42:01
【问题描述】：

现在我们有了一个专用的<nav> 标签，

这是：

<nav>
  <ul>
    <li><a href="#foo">foo</a></li>
    <li><a href="#bar">bar</a></li>
    <li><a href="#baz">baz</a></li>
  </ul>
</nav>

比下面的更好吗？

<nav>
  <a href="#foo">foo</a>
  <a href="#bar">bar</a>
  <a href="#baz">baz</a>
</nav>

假设我不需要额外的 DOM 级别来进行某些 CSS 定位/填充，那么首选方式是什么，为什么？

【问题讨论】：

这是一个很好的问题...对于 HTML 4 没有意义的标签，之前的最佳实践是否适用？

标签： html html-lists nav

【解决方案1】：

nav 元素和列表提供不同的语义信息：

nav 元素表明我们正在处理一个主要的导航块
列表表明此导航块内的链接形成项目列表

在http://w3c.github.io/html/sections.html#the-nav-element，您可以看到导航元素也可以包含散文。

所以是的，在 nav 元素中包含一个列表确实增加了意义。

【讨论】：

非常感谢，这正是我所需要的！此外，robertc 关于屏幕阅读器在下面宣布“3 项列表”的评论非常有用。
似乎 UL 标签没有任何帮助：css-tricks.com/navigation-in-lists-to-be-or-not-to-be
链接似乎对我有用。请务必阅读后续内容，其中声明列表和没有列表是平局。 css-tricks.com/wrapup-of-navigation-in-lists
在我看来，没有<ul><li> 的<nav> 似乎会有更多动态的子菜单。如果您在<nav> 中有多个不同类型和位置的菜单列表怎么办？我会将这些菜单列表分组为<ul><li> 中的<nav>。所以如果你的菜单有规律，我会选择<ul><li>。

【解决方案2】：

对我来说，无序列表是不需要的额外标记。当我查看 HTML 文档时，我希望它尽可能干净且易于阅读。如果使用适当的缩进，查看者已经清楚地显示了一个列表。因此，将UL添加到这些a标签是不必要的，并且使阅读文档更加困难。

虽然您可能会获得一些灵活性，但我相信最好不要使用无意义的 ul 类来膨胀标记，而是一举为 a 元素设置样式。而且你没有任何借口：使用 :before 和 :after 伪选择器。

编辑：我已经知道一些 ARIA 屏幕阅读器对列表的处理方式与简单的锚标记不同。如果您的网站面向残疾人，我可能会考虑使用基于列表的方法。

【讨论】：

【解决方案3】：

此时，我会保留 <ul><li> 元素，原因是并非所有浏览器都支持 HTML5 标签。

例如，我在使用 <header> 标记时遇到了一个问题 - Chrome 和 FF 工作起来就像一个魅力，但 Opera 却很糟糕。

在所有浏览器都完全支持 HTML 之前，我会坚持使用它们，但要依赖旧的来实现向后兼容性。

【讨论】：

使用 HTML 5 Shim javascript 文件 (remysharp.com/2009/01/07/html5-enabling-script) 来减少与 Opera 和 IE 等浏览器的任何可能的向后兼容性错误。
但是你的网站对非侵入式脚本不友好:)
你的意思是直到 IE8 退出市场......所以直到 2016 年......:)
@Šime - 正是 :) 关闭 Javascript 不再是浏览器中的选项；)
@Agent_9191 会的 - 今天我完全惊讶于我想检查有多少人仍在使用 IE7 并猜猜是什么 - 在大多数国家/地区，使用 Opera 或 iPad safari 等浏览器的人更多比在 IE7 中。我很高兴我现在可以放弃对 IE7 的支持！而IE8迟早会消失。这是我们将不得不面对的最后一个顽固的浏览器（IE9 并不是那么糟糕）。

【解决方案4】：

这真的取决于你。如果您通常使用无序列表来标记导航菜单，那么我会说在

【讨论】：

+1 因为提到对于屏幕阅读器，navs 和 as 现在和列表一样好。

【解决方案5】：

nav > a 的简洁标记当然很诱人，但请考虑子菜单和下拉菜单的问题（其他答案中未提及）。 HTML 允许您将一个列表嵌套在另一个列表中，这是一种构建此类菜单的优雅（我敢说是语义）方式：

<nav>
  <ul>
    <li><a href="#foo">foo</a></li>
    <li><a href="#bar">bar</a>
        <ul>
            <li><a href="#qux">qux</a></li>
            <li><a href="#quux">quux</a></li>
        </ul>
    </li>
    <li><a href="#baz">baz</a></li>
  </ul>
</nav>

你不能嵌套a元素，所以排除nav > a，除非你开始在divs中包装东西：

<nav>
  <a href="#foo">foo</a>
  <a href="#bar">bar</a>
    <div>
      <a href="#qux">qux</a>
      <a href="#quux">quux</a>
    </div>
  <a href="#baz">baz</a>
</nav>

一些流行的 CSS 框架（如 Bulma 和 Semantic/Fomantic UI）为带有下拉菜单的导航栏做了类似的事情。所以它可以完成，但对我来说感觉有点笨拙。 qux 和 quux 并没有真正嵌套在 bar 中，就像在第一个示例中一样。

【讨论】：

【解决方案6】：

不，它们是等价的。请记住，HTML 5 向后兼容 HTML 4 列表，因此您可以随意在相同方面使用它们。权衡的是第二个版本的代码更少。

如果您担心浏览器的向后兼容性，请确保包含this shim 以提供诸如<nav> 和<article> 等标签的功能。

【讨论】：

链接列表提供了额外的语义和可访问性（例如，屏幕阅读器会在您进入导航时显示“三个项目的列表”）。
@robertc 屏幕阅读器的观点非常好。你应该把它放在一个答案上！我会把它标记为正确的。无论如何 +1。

【解决方案7】：

如果我们是在“按部就班”谈论，那么不；您不需要使用列表来标记您的导航。它们提供的唯一真正优势是在造型时提供更好的灵活性。

【讨论】：

【解决方案8】：

我会保留<ul><li> 标签，因为新标签（<nav>、<section>、<article> 等）只是<div>s 的语义化版本。

出于同样的原因，您不会只在 <div> 中拥有大量链接，它们还应该在 <nav> 标记中进行结构化。

【讨论】：

过去我使用