重大变化:混合声明
CSS 改变了处理混合嵌套规则声明的方式,我们确保 Sass 也遵循了它的行为。
迄今为止的故事迄今为止的故事 permalink
¥The Story So Far
从历史上看,如果你在 Sass 中将嵌套规则和声明混合在一起,它会将所有声明拉到规则的开头,以避免重复外部选择器。例如:
¥Historically, if you mixed together nested rules and declarations in Sass, it would pull all the declarations to the beginning of the rule to avoid duplicating the outer selector more than necessary. For example:
SCSS Syntax
.example {
color: red;
&--serious {
font-weight: bold;
}
font-weight: normal;
}
CSS Output
.example {
color: red;
font-weight: normal;
}
.example--serious {
font-weight: bold;
}
当 纯 CSS 嵌套 首次推出时,它的行为方式相同。但是,经过一番考虑,CSS 工作组决定 更有意义的做法是让声明按照它们在文档中出现的顺序应用,如下所示:
¥When plain CSS Nesting was first introduced, it behaved the same way. However, after some consideration, the CSS working group decided it made more sense to make the declarations apply in the order they appeared in the document, like so:
SCSS Syntax
.example {
color: red;
&--serious {
font-weight: bold;
}
font-weight: normal;
}
CSS Output
.example {
color: red;
}
.example--serious {
font-weight: bold;
}
.example {
font-weight: normal;
}
弃用旧方法弃用旧方法 permalink
¥Deprecating the Old Way
- Dart Sass
- since 1.77.7
- LibSass
- ✗
- Ruby Sass
- ✗
嵌套规则后声明的使用最初已被弃用,以便通知用户即将发生的更改,并让他们有时间使其样式表与之兼容。
¥The use of declarations after nested rules was first deprecated in order to notify users of the upcoming change and give them time to make their stylesheets compatible with it.
希望尽早选择新 CSS 语义的用户可以将嵌套声明封装在 & {}
中:
¥Users who wanted to opt into the new CSS semantics early could wrap their nested
declarations in & {}
:
SCSS Syntax
.example {
color: red;
&--serious {
font-weight: bold;
}
& {
font-weight: normal;
}
}
CSS Output
.example {
color: red;
}
.example--serious {
font-weight: bold;
}
.example {
font-weight: normal;
}
Can I Silence the Warnings?Can I Silence the Warnings? permalink
Sass provides a powerful suite of options for managing which deprecation warnings you see and when.
Terse and Verbose ModeTerse and Verbose Mode permalink
By default, Sass runs in terse mode, where it will only print each type of deprecation warning five times before it silences additional warnings. This helps ensure that users know when they need to be aware of an upcoming breaking change without creating an overwhelming amount of console noise.
If you run Sass in verbose mode instead, it will print every deprecation
warning it encounters. This can be useful for tracking the remaining work to be
done when fixing deprecations. You can enable verbose mode using
the --verbose
flag on the command line, or
the verbose
option in the JavaScript API.
⚠️ Heads up!
When running from the JS API, Sass doesn’t share any information across
compilations, so by default it’ll print five warnings for each stylesheet
that’s compiled. However, you can fix this by writing (or asking the author of
your favorite framework’s Sass plugin to write) a custom Logger
that only
prints five errors per deprecation and can be shared across multiple compilations.
Silencing Deprecations in DependenciesSilencing Deprecations in Dependencies permalink
Sometimes, your dependencies have deprecation warnings that you can’t do
anything about. You can silence deprecation warnings from dependencies while
still printing them for your app using
the --quiet-deps
flag on the command line, or
the quietDeps
option in the JavaScript API.
For the purposes of this flag, a "dependency" is any stylesheet that’s not just a series of relative loads from the entrypoint stylesheet. This means anything that comes from a load path, and most stylesheets loaded through custom importers.
Silencing Specific DeprecationsSilencing Specific Deprecations permalink
If you know that one particular deprecation isn’t a problem for you, you can
silence warnings for that specific deprecation using
the --silence-deprecation
flag on the command line, or
the silenceDeprecations
option in the JavaScript API.
新方法新方法 permalink
¥The New Way
- Dart Sass
- since 1.92.0
- LibSass
- ✗
- Ruby Sass
- ✗
现代版本的 Sass 的行为与纯 CSS 相同:声明会按照编写顺序发出,即使这需要复制包含它们的规则以解决规则交错的问题。对于粗体(/* */
样式)注释和没有子规则的 @ 规则也是如此。
¥Modern versions of Sass behave the same way as plain CSS: declarations are
emitted in the same order they’re written, even if that involves duplicating the
rule that contains them to account for interleaved rules. The same is true for
loud (/* */
-style) comments and at-rules without children.