CSS 最棒的一点在于它允许 Web 开发人员用更少的代码实现更多功能。 这到底意味着什么？ 首先，CSS 允许开发人员
- 编写更少、更少的 XHTML 代码
- 将网站格式与内容分离
- 使用一个 CSS 文件控制开发人员允许自己控制的尽可能多的网站主题/设计
- 轻松地使网站显示适应用户，而不是用户适应网站
- 更改我们网站针对特定设备和特殊情况的显示
列表还在继续。 用更少的代码做更多事情的功能就在那里； 开发人员需要编写 XHTML 代码以充分利用 CSS 的强大功能。 我经常看到 CSS 未被充分利用的一个地方是导航菜单。
根据您网站的设计，您可以使用垂直导航或水平导航。 您也可以同时使用两者。 如果您使用 XHTML 列表（<ol> 或 <ul>）作为导航，那么您很有可能编写了额外的代码。 现在是时候利用 CSS 的 display 属性了。 我们将把…
<div id="navigation">
<h3>Categories</h3>
<ul class="nav-list">
<li><a href="/css">CSS</a></li>
<li><a href="/html">HTML</a></li>
<li><a href="/mootools">MooTools</a></li>
<li><a href="/php">PHP</a></li>
<li><a href="/xml">XML</a></li>
</ul>
</div>…转换成…
<div id="navigation">
<h3>Categories</h3>
<a href="/css">CSS</a>
<a href="/html">HTML</a>
<a href="/mootools">MooTools</a>
<a href="/php">PHP</a>
<a href="/xml">XML</a>
</div>…使用一些非常基本的、跨浏览器兼容的 CSS。
在这种情况下，使用列表/列表项结构方法的唯一真正优势是 <li> 本质上是“块”元素； 它们是实心的容器，除非浮动，否则会换行。 CSS 允许我们使用 display:block; 属性/值组合来阻止指定的元素。 为了去除上面冗余的列表代码，我们可以为导航菜单内的任何链接（<a>）指定 display:block;。
#navigation a { display:block; }上面的示例是垂直导航所需的一切。 对于水平导航，您需要指定一个 float 值，就像使用列表项一样。
#navigation a { display:block; float:left; }就这些？是的！ 在很多情况下，您可以简单地获取以前的 <li> 属性并将它们移动到链接选择器！ 上面的代码对开发人员和用户都具有巨大的优势，因为
- 开发人员可以节省大量带宽
- 页面加载速度更快
- 更少的代码意味着更快的维护
- 列表属性不会干扰您的锚点属性
如果您不相信或想看看此 CSS/XHTML 的实际效果，请随时查看我的网站的源代码：davidwalsh.name。
在您发表评论之前…
我的方法受到了批评，所以我想回答一些我预见的几个问题/评论。
1. 这段代码很丑！
我从未听说过客户说我的代码很丑。 但是，我确实因为创建加载速度快的网站而受到了感谢。 请记住，在大多数情况下，只有开发人员才会关心代码的外观。 功能是关键。
2. 它并没有节省那么多代码！
想想您的页面被用户下载了多少次！ 想想您的 JavaScript 库增加了多少额外的下载时间！ 所有 Web 开发人员都应该考虑下载时间。
3. 您的代码降级效果不好。
可访问性始终是我考虑的一个因素。 如果您关闭所有 CSS 样式，页面将简单地显示用空格分隔的链接。 与列表一样好？ 不，但仍然易于阅读。
在与 Chris 交流时，他提出了一个非常巧妙的观点。 可以创建一个 <h2> 标签（或您选择的任何标签），将其命名为“导航”，并使用 CSS 隐藏它。 如果 CSS 被关闭，则“导航”标题将显示，用户将清楚地知道他/她正在查看导航。
我要特别感谢 Chris 让我与大家分享我的方法。 我计划监控评论，所以请分享您的想法和建议。
屏幕阅读器的可访问性怎么样？
语义学怎么样？
IE 中的 display:block 怎么样？
我不太喜欢这种技术，主要是因为您剥夺了 HTML 的语义：我们不再拥有一个结构化的导航链接列表，而是拥有一个模棱两可的锚标记集，这些标记在理论上构成了您页面的导航。 链接和导航项之间没有明确的分组。
此外，我认为您提供的列表示例略显冗长。 拥有 nav-list 类可能没有必要，因为可以使用 #nav ul 很容易选择列表。
将列表与一组链接结合使用的另一个好处是，它可以很好地提供一些额外的标记来附加 CSS，因此 Douglas Bowman 的滑动门 等技术是可能的。
至于节省带宽……我想这可能有所帮助，但缩短 ID 名称也可能会带来相当类似的性能改进！
与列表一样好？ 不，但仍然易于阅读。
这是否像它可以的那样易于阅读？ 因为这是您的链接在不支持 CSS 的浏览器（我指的是移动浏览器）上的显示方式。
为什么不将所有列表都设为那样？ 事实上，我们可以使用表格来实现它们……（/讽刺）
@Romz 和 @Mathew：各个“h”标签代表导航分组，因此，使用此系统时，不同导航部分之间的分离不会消失。 Display:block 在所有 IE 和现代浏览器中都能正常工作，因此这不是问题。 我确实知道缩短 ID 会起作用，但我为了这个示例而使用了较长的 ID。 但是，缩短的元素 ID 无法接近创建列表所需的字节数。
最后，上述解决方案并非在所有情况下都有效，因此使用我的示例无法实现滑动门示例（除非您每个链接都有不同的按钮图像）。 但是，对于许多目的，此解决方案都能正常工作。
@James：“IsThisAsPlainReadableAsItCouldBe？”应为“Is This As Plain Readable As It Could Be？” 回车符会渲染为空格。 不过，你的讽刺意味很巧妙。
您可以不用 <li> 元素就能实现滑动门。 只需使用 span 作为您的额外挂钩即可代替列表元素。
@Chris：我想我关于使用列表以及拥有语义标记的额外功能来实现滑动门的观点是，span 添加了没有结构意义，而列表却有意义。 当然，您可以使用 span，但关键是 span 没有添加任何结构意义，而列表则有。
@James：对我来说，列表似乎是查看一组导航项的完美方式，而不是一堆无法区分的链接，但话又说回来，这在很大程度上取决于移动设备。 然而，随着 iPhone 和谷歌的 Android 等设备的出现，我认为这个论点将变得越来越不相关。
您还可以去除空格并节省惊人的 20 个字节，从 188 个减少到 168 个。字节，伙计们……
原始文件大小为 270 个字节，减少到 239 个字节。
但两者都显示为 4.00 kb，真是不可思议。
在我的一个界面设计课程中，他们教我们使用列表表示链接是正确的语义（将相关的一组内容放在一起）。 但是，我之前“作弊”过，没有将链接放入列表中，因为这样编码和设置样式更容易！ 我想无论您做出什么决定，都应该取决于您的网站将获得多少流量——只有在可以节省大量带宽时才走捷径？
http://www.peachpit.com/articles/article.aspx?p=369225&rl=1
http://www.csslounge.co.uk/2005/06/16/the-semantic-web/
在快速搜索中，我偶然发现了这两个网站，它们解释了使用列表而不是链接的用途，并且无需使用 UL 或 OL。
在我阅读了你的文章后，我一直在寻找更多关于屏幕阅读器或类似工具如何使用列表进行导航的信息，似乎列表对于残障人士的理解和正确翻译非常重要。因此，为了实现无障碍，使用“导航”作为标题的解决方案将无法使用，我不得不反对这种节省代码的方式。
我想你已经预料到读者会有这种反应了 :)
无论如何，我认为这是一种非常合理的方法。
这并没有做到用更少的代码实现更多功能……而是用更少的代码实现了更少的功能。失去语义含义和可访问性并不是减少击键次数的借口。那只是懒惰。我不会向任何 Web 开发人员推荐这种方法。
感谢您的想法。
-Nate
我写这篇文章的目的并不是说“这就是你应该如何做”。而是说这是你可以如何做。我理解人们使用列表，对此我没有任何问题；我只是想指出，很多时候列表并不是必需的，CSS 使你能够不必使用列表。
@Chris：关于带宽使用量以及从 270 字节降至 239 字节，节省的空间量显然取决于导航菜单的大小。然后将其乘以网站获得的页面浏览量。然后将该数字乘以每天获得的访客数量。这就是您的常客会感激的节省。
我确实预料到了这种反应——当我能做到的时候，我倾向于将 CSS 推到极限。当我在我的博客上发布以下内容时，我收到了同样的回应。
当然，它可能在语义上不正确，但它确实有效。
@Yaili：我非常喜欢你的博客设计！
对隐藏的 -tag 的另一个补充是，添加一个隐藏的 -tag 来分隔每个文章列表（例如，在首页上）。文章标题应该是 h1 或 h2（两者都适用于 SEO 和最佳可访问性选项），但如果你不得不关闭 CSS，那么在文本结束时更容易理解。
该死。如果没有预览脚本，我就无法看到标签是否按我想要的方式呈现。标签 1：
<h2>和标签 2：<hr />节省带宽？大多数浏览器都会缓存历史记录中经常访问的页面的本地副本。
我确实想看看以这种方式完成的带子导航的导航。你觉得你能推一把吗？
例如……
你提供的对于段落中的链接列表来说是可以的，但不适用于任何类型的实际导航。
重复我之前说过的话，这并非在所有情况下都有效。为了在视觉上添加子导航，你需要为子导航项添加一个类。对于屏幕阅读器，你需要使用列表。
我在我的网站上对这篇文章做出了回应。在语义、可访问性和灵活性方面，这种方法无法满足任何满足任何人（即使是使用基于计算机的浏览器且视力完美的人）的要求或建议（即使如此，这也是一种延伸）。
我也有一个想法，它很可能也不适用于站点地图页面。我希望如果它确实在某个站点上使用，你也会包含一个正确的站点地图。
虽然我欣赏“前卫”的 CSS，但我认为它对名为 CSS tricks 的网站来说并不好。它不是 CSS-Mistakes，我们不应该教授错误的语义、xhtml 和 css 代码。
突破界限和打破界限之间是有区别的。只是很高兴这么多人在档案目的方面对这件事发表了评论。
XHTML 2 将拥有新的元素 NL 和 LABEL，那不是很好！但是旧版本的浏览器不支持它。但幸运的是，几乎所有浏览器都支持 UL、OL 和 DL。
我想在这里继续扮演魔鬼的代言人，因为我认为这是一个有趣的讨论。
这里很多人都在谈论语义这个词。我怀疑无序列表在语义上是否能很好地描述导航链接。列表非常适合食谱或如何拆卸化油器的分步指南，但我不知道页面导航是否需要它。
从语义上讲，导航需要用某种东西“包装”起来。我知道 div 被滥用和过度使用太多了，但我认为这里的“分隔”与无序列表在语义上一样适用，甚至更多。
这里更重要的考虑因素是可访问性以及此导航在启用 CSS 和禁用 CSS 时的外观。我整理了一个快速示例，展示了一个我认为在这两方面都做得不错的页面导航。
使用 div 的唯一问题是，div 用于将页面划分为多个部分。目前，列出导航的最语义化方式是使用列表。它是一个导航链接列表，将带你到网站的其他位置。就像 Chris S. 说的那样，XHTML 2.0 将会推出更多语义化的方式来实现这一点。也就是说，如果 HTML 5 没有击败它的话。
顺便说一句，Web 设计标记的整个未来确实变得越来越混乱。
无论如何，目前可用的最语义化的标记将是导航的列表。至少在我看来是这样。
@ Chris S：我的示例代码对我来说算是一个技巧——用更少的代码实现结果。请意识到，这个网站也不是“CSS-Standards”或“CSS-Recommended-Semantic-Practices”。你对此赋予了太多“价值”。这是一篇展示样式 CAN 做什么的文章，而不是你 SHOULD 做什么的文章。我写这篇文章的目标之一是扮演魔鬼的代言人——创造新的想法并不一定需要遵守规则。
@ Chris C：感谢你发布示例——希望这能使事情更清楚一些。
只是一个说明，不是关于文章，而是关于你的项目符号列表。图像的底部部分不见了。如果你需要截图，请告诉我！！
使用 firebug，我注意到在第 170 行（我认为）li 的行高是 1.5em，我尝试了 1.7，它显示了完整的图像项目符号。
.post li {style.css (第 170 行)font-size:1.2em;
line-height:1.7em;
margin-bottom:0.9em;
margin-top:0.5em;
}
希望对您有所帮助
好吧，我几乎完全是网页设计新手，我自己想出了 David 的技巧。我在我第一个从头开始制作的页面上使用了导航列表，但后来决定在我的下一个练习页面上想要一个水平导航栏。我没有对通常为垂直的列表进行任何技巧操作使其变成水平，我只是决定将导航链接在栏中内联。
当然，如果你正在制作更复杂的东西，代码将需要更复杂，但对于基本的导航栏，我认为 David 提出的技巧非常有效。就像 David 说的那样，它以空格分隔链接，并且即使完全关闭 CSS，它看起来也很好。如果屏幕阅读器从“链接主页”等开始，我认为用户会很快意识到这是一个导航区域。
从网页设计新手的角度来看，使用列表似乎也存在自身的问题，可能是因为全职设计师已经习惯了这些问题。虽然此技术可能不适用于所有设计，但它对某些人来说是有效的。
在阅读了关于此主题的几篇帖子后，我不确定我是否同意列表一定比 div 好。人们可以将他们的导航视为链接列表或按钮块。由于目前没有针对 nav 元素/项目的特定标签，因此在我看来，它只是将 nav 强行塞入当前可用的内容中。这是否使其具有语义/意义？由于它不是“标准”，对我来说，它更像是一种理论或个人观点，而不是绝对的语义。