如果我有一个容器和一个项目列表，我可能会有以下HTML标记：
<div class="container food foodcontainer">
<ul class="list foodlist">
<li class="listitem fooditems"></li>
...
我可以用两种方式设置它们（假设使用纯CSS而不是/ sass或任何其他帮助器）。首先，就像通常会做的那样：
.food { /* style */ }
.food .list { /* style */ }
.food .list .listitems { /* style */ }
或者，我可以通过详细的描述性类名简单地引用所有内容：
.foodcontainer { /* style */ }
.foodlist { /* style */ }
.fooditems { /* style */ }
没有更多的级联关系！ 是否有理由不对所有内容执行此操作（以便每个元素都由单个类/ id名称引用）？我（以及处理相同代码库的人员）只需不< / strong>要么在可读性方面要好得多;如果有的话，我们会发现更容易掌握的独特和直接名称，也更容易搜索。
an ancient article通常建议使用更短，更独特的选择器来提高性能;在its more recent update中，它表示整体表现已经好转。但是好多少？短路仍然更快吗？
答案 0 :(得分：1)
.food .list { /* style */ }仅定位<{1}}类 类list元素的元素。
food仅定位.food > .list { /* style */ }类list元素的元素。
food定位类.list { /* style */ }的所有元素，无论其父元素如何。
通常，如果您想确保仅针对特定元素中的元素而不是任何其他可能具有相同类别的元素，请根据您的需要使用上述第一个或第二个元素。
当然，你也可以为他们提供独特的课程，以避免链接他们，但IMO只是一个不必要的麻烦，记住你已经使用过哪些课程。此外，我认为它有助于提高可读性，当你将它们链接起来而不是提出独特的类时 - 那么它更容易看出这些规则适用于哪些元素。
我不会过分担心其中任何一个的表现 - 除非你有大量网站。
您可以阅读有关CSS选择器here的信息。
答案 1 :(得分：1)
嗯，你可以为每个元素提供一个类，但级联关系的重点是防止必须为每个元素提供一个类。
例如：
a{ /* style link elements some way */ }
.some-div a { /* but in some-div they should look differently }
在这种情况下，您只需要在div上设置1个类。否则你必须在你的html中给每个链接元素一个类，这会适得其反。
使用关系可以更加通用，避免达到最终使用header-logo-nav-link-first之类的名称。您必须记住该课程，但您还必须在每个元素中编写它。有没有看过50多个链接的页脚？ ;）
您的选择器越具体，您的样式就越优先。
答案 2 :(得分：1)
非常有趣的问题。从本质上讲，您已经为类体系结构确定了两个维度。第一个是food维度，具有语义含义，特别适用于与食物相关的所有事物。第二个是列表维度，它是一个布局维度，特别适用于与列表及其布局相关的所有内容。
这是打破课程的一种非常聪明的方法。它有助于防止与食物有关的规则“泄漏”到与列表有关的规则中，反之亦然。您的HTML成为具有不同含义的类组的类的干净正交组合。在我看来，这是理想的。它遵循特定的CSS设计理念，即以不同的方式组合较小的类，从而促进重用并提高可读性。另一种选择是“厨房 - 水槽”类，它们难以重复使用且难以阅读。这将诱使您使用具有@extend等功能的预处理器，并且事情将从那里迅速下坡。
定义单例类的技术术语是“超级目标”。一个示例id Food__orange-disabled--listitem。如果沿着这条路走下去，你将在余生中写下并重写这些奇异的类名。每一次更改都需要更改CSS和HTML。这种方法的支持者声称效率是采用它的一个原因，这可能是五年前的一个问题，但正如你所提到的，今天的浏览器可以处理合理数量的嵌套选择器而不会出汗。
答案 3 :(得分：0)
我正在重新审视这个问题，因为我发现了更新，更新的文章和参考文献。
简而言之，应该没有理由阻止使用非嵌套名称。事实上，它甚至可以帮助提高性能和可维护性。
BEM (and other similar naming schemes) tackles the maintainability issue.
And, class-centric styles help with performance.
我还想补充一些解释，为什么在其他答案中给出的一些理由，或者我所看到的其他地方的原因，并不适用于反对该案件。
“这不是CSS的工作原理。”
CSS确实可以使用嵌套关系，正如其名称所暗示的那样，但这本身并不是我们必须或应该使用它的原因。
“嵌套关系更容易维护。”
这只是一种“可能”，具体取决于代码风格。比如，我们有一个如下的样式表：
a { /***/ }
.some-div a { /***/ }
.more-div a { /***/ }
而且，我们在模板中的某处有一个链接：
<div class="some-div ...
<div ...
<div class="some-other-div" ...
<a href="...
现在，当我们查看模板中的链接时，我们会看到一个没有类的标记a。它有什么样的风格？好吧，我们必须转到样式表并搜索a，并且会有很多a个，并且它们可以任意嵌套。
这就像其他编程语言中的“神奇数字”一样;唯一的区别是，我们有标签名称而不是数字常量。搜索单个a就像在源代码中搜索3一样;我们必须从上下文中推断出大部分信息。
并且没有办法快速搜索css选择器，因为我们不知道样式表中使用了祖先树中的哪个父级。可能是.some-div a或.some-div .some-other-div:last-child a。
相反，如果我们对标签本身进行了分类（例如<a class="some-div-link-class some-other-class" ...）。这只是一次搜索。