sass嵌套_使用CodePen学习Sass，第8部分：命名和嵌套媒体查询

sass嵌套

Stylesheets for a website are often written from a single “ideal” state (usually mobile-first or desktop), which is then added to and adjusted with a series of @media queries:

网站的样式表通常是从一个单一的“理想”状态(通常是移动优先或桌面状态)编写的，然后将其添加到一系列@media查询中并进行调整：

典型的@media断点 (Typical @media Breakpoints)

body { /* general rules */ }
h1, h2 { /* still more general rules */ }
@media all and (max-width: 960px) {
    /* first breakpoint */
    body { /* changes to selectors */ } 
}
@media all and (max-width: 650px) {
    /* second breakpoint */
    body { /* more changes */ } 
    h1 { /* more changes to other selectors */ } 
}

This approach congregates all breakpoint changes for the site into groups, usually at the end of your stylesheet. While helpful from an organizational point of view, this does have a few downsides:

这种方法通常在样式表的末尾将站点的所有断点更改聚合为组。 尽管从组织的角度来看很有帮助，但这确实有一些缺点：

1. “Clumping” selectors leads to broader browser interventions. Once your CSS has a few media queries, there’s an understandable desire to avoid adding further technical debt. As a result, developers tend to shoehorn new changes into existing @media sets. This creates a few CSS “jump points” for a site where everything changes, rather than a considered, granular response to changing viewport width.

   “集中”选择器会导致更广泛的浏览器干预 。 一旦CSS遇到了一些媒体查询，就可以避免避免增加技术负担，这是可以理解的。 结果，开发人员倾向于对现有的@media集进行新的更改。 这会为所有更改的站点创建一些CSS“跳点”，而不是对更改的视口宽度进行仔细的细粒度响应。

2. Harder to find selectors. A selector may be altered several times across several different media queries widely separated in the stylesheet, making them hard to track down during bug testing and maintenance.

   很难找到选择器 。 在样式表中广泛分离的几个不同的媒体查询中，选择器可能会更改几次，从而使它们很难在错误测试和维护期间进行跟踪。

Sass嵌套媒体查询 (Sass Nested Media Queries)

Sass inverts this approach: rather than clumping changes together under a few @media breakpoints, it can place media queries inside selectors. Like many other aspects of Sass explored in this series, nested media queries are easiest to practice with on CodePen, where a variation of the code below resides:

Sass颠覆了这种方法：它可以将媒体查询放置在选择器中，而不是将更改汇总到几个@media断点下。 像本系列中探讨的Sass的许多其他方面一样，嵌套媒体查询最容易在CodePen上进行实践，其中包含以下代码的变体 ：

body { 
    line-height: 1.3;
    margin: 2rem;
    background: grey;
    @media all and (max-width: 650px) {
        line-height: 1.4;
        margin: 1rem;
        background: black;
    }
}

In English: under desktop viewing conditions, set the line-height of the body to 1.3, margin on all sides to 2rem, and the background to grey, and alter its horizontal and vertical padding. If the viewport is 650 pixels wide or less, change all of these properties to something more suitable for small screen devices.

用英语：在桌面查看条件下，将主体的line-height设置为1.3，将所有margin设置为2rem ，背景设置为灰色，并更改其水平和垂直填充。 如果视口的宽度等于或小于650像素，请将所有这些属性更改为更适合于小屏幕设备的属性。

This means that you can associate all the media queries for a particular element with the element itself, rather than spreading them across multiple points in your stylesheet:

这意味着您可以将针对某个特定元素的所有媒体查询与该元素本身相关联 ，而不是将它们分布在样式表中的多个点上：

body {
    font-size: 1rem;
    @media all and (max-width: 650px) {
        font-size: 1.2rem;
    }
    @media all and (max-width: 420px) {
        font-size: 1.4rem;
    }
}

If you’ve written a lot of “vanilla” CSS previously, you may have an instinct to write a selector immediately after setting the breakpoint, but in this case, that’s already set: instead, you go straight into writing properties and values.

如果您以前写过很多“原始的” CSS ，则可能有一种本能，就是在设置断点后立即编写选择器 ，但是在这种情况下，已经设置好了：相反，您将直接编写属性和值 。

This is incredibly useful when writing long, complex stylesheets, and addresses all the concerns of the traditional approach detailed above. However, it does bring a few possible disadvantages of its own, the primary one being the creation of a more complex stylesheet peppered with @media queries. Surprisingly, this does not affect performance: writing lots of little element @media queries is not significantly slower than the same changes grouped into a few queries. Readability of the final stylesheet isn’t a factor, as your output CSS should be minified anyway (one of the reasons I maintain a .zip of the Sass for this site).

在编写冗长而复杂的样式表时，这非常有用，并且可以解决上述传统方法的所有问题。 但是，它确实带来了一些可能的缺点，主要缺点是创建了一个带有@media查询的更复杂的样式表。 出乎意料的是，这不会影响性能：编写许多小元素@media查询并不比分组为几个查询的相同更改明显慢 。 最终样式表的可读性不是一个因素，因为无论如何您的输出CSS 都应该最小化 (我为此站点维护Sass的.zip的原因之一)。

Using nested media queries allows you to write immediate responsive interventions on elements, rather than trying to remember the selectors, properties and values you need to change as you search for a particular breakpoint. Which leads directly to another Sass feature…

使用嵌套的媒体查询，使您可以对元素进行即时响应干预 ，而不必试图记住在搜索特定断点时需要更改的选择器，属性和值。 这直接导致了另一个Sass功能……

命名媒体查询 (Named Media Queries)

If you decide to embrace the Sass approach of nested media queries, it can create one other potential problem: remembering breakpoint values. Thankfully, we can use Sass itself to solve that using variables:

如果您决定采用嵌套媒体查询的Sass方法，则可能会引起另一个潜在问题：记住断点值。 幸运的是，我们可以使用Sass本身使用变量来解决该问题：

$screen-large: 1500px;
$screen-med: 750px;
$screen-small: 420px;

@media (max-width: $screen-large) { 
    //
}

These named breakpoints are much easier to remember (and a good editor will even prompt or auto-complete them as you type, once you create the variables), making for fewer errors and less time spent searching through code. Of course, these variables can also be used in nested media queries inside selectors, and manipulated with Sass arithmetic to produce values for min-width and other variations.

这些命名的断点更容易记住(一旦创建变量，好的编辑器甚至会在您键入时提示或自动完成它们)，从而减少了错误，并减少了搜索代码的时间。 当然，这些变量也可以在选择器内部的嵌套媒体查询中使用，并通过Sass算术进行操作以产生min-width和其他变化形式的值。

If you’re already familiar with Sass, Hugo Giraudel takes this concept significantly further with Sass mixins and maps.

如果您已经熟悉Sass，Hugo Giraudel 会通过Sass mixins和map进一步深化这个概念 。

翻译自: https://thenewcode.com/6/Learn-Sass-with-CodePen-Part-8-Named-and-Nested-Media-Queries

sass嵌套