是否可以在源代码中嵌套 CSS 选择器而不输出它们嵌套？ [复制]

Question

例如，我想通过这样做使我的代码更易于阅读：

#article{
  ...

  #article_inner{
    ...
  }
}

但是，我希望它编译成这样：

#article{
  ...
}

#article_inner{
  ...
}

这可以使用 SASS 吗？

Answer 1

是的，@at-root 会做你想做的事。

但是，我质疑你问题的前提。

首先，假设您真的想写#article { #article-inner {。为此，SASS 将生成代码#article #article-inner {。您希望它生成#article-inner {。但为什么？大概您担心解析、下载或应用前者的效率可能低于后者。但实际上，效率上的任何差异都微不足道，甚至不存在。

其次，我想知道为什么您认为嵌套规则“更易于阅读”。实际上，对我来说，阅读它更难。大概您认为遵循 HTML 的结构会使它更易于阅读。实际上，遵循 HTML 的结构会使您的 CSS 变得脆弱。在计算机科学术语中，这被称为“耦合”，通常被认为是一件坏事；在这种情况下，您将 HTML 与 CSS 耦合得太紧了。例如，如果 #article-inner 出于某种原因移动或出现在其他地方，那么即使 ID 匹配，您的规则也会停止工作。

经验丰富的 SCSS 编码器会非常轻松地使用其嵌套功能。相反，他们编写与 HTML正交 的规则，这些规则可以组合以创建许多样式效果，而不受 HTML 的层次结构的束缚。我所知道的优秀 SCSS 编码器在.class { color: red; &:hover { color: blue; } } 之类的情况下将自己限制为嵌套，或者在其他情况下最多嵌套一层。在您的情况下，如果您必须使用 @at-root 来做您想做的事情，那么您现在实际上以可读性的名义降低了代码的可读性。

SCSS 不会永远存在。有一天，CSS 将处理它现在为我们所做的大部分事情，包括变量。一些商店已经开始远离 SASS，因为它丑陋、冗长的宏、mixin、难以维护的功能（如 @extend）以及过度嵌套，回到原始 CSS 或转向更现代的预处理器（如 suitCSS）。我们对供应商前缀的 SASS 越来越少；其他预处理器支持模块化、自动化的供应商前缀工具。因此，由于所有这些原因，在今天编写 SCSS 时考虑到将来某个时候您的代码可能需要从 SCSS 移植远离的可能性并不是不合理的。这表明您应该避免在并非真正需要时使用大量 SCSS 特定的功能，例如您的情况下的嵌套。

如果您想要可读性，请添加 cmets，无论如何您都应该这样做。

#article { ... }

/* The `#article_inner` element is inside `#article`.
#article_inner { ... }

更一般地说，我会质疑基于 ID 的 CSS 编写方法。大概您打算在#article-inner 上指定一堆属性，例如字体大小、背景、填充或其他。我见过有十几个属性或更多属性的 CSS。重点是什么？您不妨直接在元素上的style 属性中编写属性；至少，您只需管理一个文件（HTML）。相反，知识渊博的 CSS 设计师会创建可以应用于许多元素的小型、类似实用程序的类。例如，他们可能会定义一个PaddedGrayBox 类来处理填充和背景。然后，他们用自己的 HTML 编写

<div id='article-inner' class='PaddedGrayBox FloatRight...'>

现在 this 更具可读性。查看 HTML 的人可以立即看到正在应用的样式类型。如果你始终如一地采用这种方法，你可能会发现你可以完全放弃使用 ID，尽管我知道这对于那些相信在每隔一行是 JavaScript 编程的核心。