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，其丑陋，冗长的宏，mixins，难以维护的功能如@extend，过度嵌套，回到原始CSS或转发到更现代的预处理器，如suitCSS。供应商前缀越来越少需要SASS;其他预处理器支持模块化的自动化供应商前缀工具。因此，出于所有这些原因，今天编写SCSS以考虑您的代码可能需要在未来的某个时间从SCSS移植远的可能性并非不合理。这表明你应该避免在不需要时使用大量特定于SCSS的功能，例如在你的情况下嵌套。

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

#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...'>

现在这个更具可读性。查看HTML的人可以立即看到正在应用的样式。如果你始终如一地采用这种方法，你可能会发现你可以完全取消使用ID，虽然我知道对于那些认为做$('id')（或{{1}的面向jQuery的程序员来说，这将是一个很大的转变。每一行都是JavaScript编程的核心。

是否可以在源中嵌套SASS选择器而不将它们嵌套输出？

1 个答案: