css sass_用Sass构建CSS类选择器

css sass

CSS naming conventions are legions. You probably know BEM and SMACSS already (the latter also being more than naming conventions). There is also OOCSS which is more like a full methodology. They all heavily rely on CSS class selectors, as they are heavily re-usable.

CSS命名约定是众多的。 您可能已经知道BEM和SMACSS (后者还比命名约定更多)。 还有OOCSS ，它更像是一种完整的方法。 它们都非常依赖CSS类选择器，因为它们具有很高的可重用性。

Using Sass can help writing those selectors in a more modular fashion. through selector nesting and mixins, we can come up with fancy crazy solutions to build the desired API. In this article, I”ll (re-)introduce a few of these ways, listing what I feel are the pros and cons of each of them.

使用Sass可以帮助以更模块化的方式编写这些选择器。 通过选择器嵌套和混合，我们可以得出 花式的 疯狂的解决方案来构建所需的API。 在本文中，我将(重新)介绍其中的几种方式，列出我认为每种方式的利弊。

本机选择器嵌套 (Native Selector Nesting)

Having a way to nest selectors in order not to have to repeat the original block name has been a long asked feature in Sass. In version 3.3 of Sass, this feature has finally been introduced. First with a very odd syntax during the beta, later changed for a better one when the stable version went live. The reasons behind this change are explained by Natalie Weizenbaum in this article.

在Sass中，有一种方法是嵌套选择器，而不必重复原始块名。 在Sass版本3.3中，终于引入了此功能。 在Beta期间，首先使用非常奇怪的语法 ，后来在稳定版本上线时对其进行了改进 ，以使其更好 。 Natalie Weizenbaum在本文中解释了此更改的原因。

Basically, the reference selector (&) can be used as part of a sub-class name in order to create another class name from the first at root-level of the document (meaning @at-root is not needed here).

基本上，引用选择器( & )可用作子类名称的一部分，以便在文档的根级别从第一个类创建另一个类名(这意味着此处不需要@at-root )。

.foo {
  // Styles for `.foo`

  &-bar {
    // Styles for `.foo-bar`
  }
}

This feature has soon be over-exploited to write BEM selectors, such as the very popular media object:

很快就过度利用了此功能来编写BEM选择器，例如非常流行的媒体对象 ：

.media {
  // Styles for `.media` block

  &__img {
    // Styles for `.media__image` element

    &--full {
      // Styles for `.media__image--full` modified element
    }
  }

  &--new {
    // Styles for `.media--new` midifier
  }
}

The previous code would be compiled to:

先前的代码将被编译为：

.media {}
.media__img {}
.media__img--full {}
.media--new {}

优点 (Pros)

• It relies on a native feature, needing no extra helpers such as variables or mixins.
  它依赖于本机功能，不需要额外的帮助程序，例如变量或混合。

• Overall quite simple to grasp once you know how the reference selector (&) works.

  知道引用选择器( & )的工作原理之后，总体来说很容易掌握。

缺点 (Cons)

• It exposes the & syntax, which might be slightly confusing if not scary for developers that are not familiar with Sass.

  它公开了&语法，对于不熟悉Sass的开发人员来说，如果不感到害怕，可能会有些混乱。

• Nesting is usually not printed at root unless @at-root is used, which might be disconcerting.

  除非使用@at-root ，否则通常不会在根目录下打印嵌套，这可能会令人不安。

BEM mixins (BEM mixins)

Because the syntax for the class generation was so ugly during the beta of Sass 3.3 (@at-root #{&}__element), we quickly saw, popping here and there, some mixins to hide the misery and provide a friendlier API.

因为在Sass 3.3的beta( @at-root #{&}__element )期间，用于生成类的语法非常丑陋，所以我们很快就看到，在这里和那里突然弹出了一些混合包，以隐藏痛苦并提供更友好的API。

@mixin element($element) {
  &__#{$element} {
    @content;
  }
}

@mixin modifier($modifier) {
  &--#{$modifier} {
    @content;
  }
}

You would use them like this:

您将像这样使用它们：

.media {
  // Styles for `.media` block

  @include element("image") {
    // Styles for `.media__image` element

    @include modifier("full") {
      // Styles for `.media__image--full` modified element
    }
  }

  @include modifier("new") {
    // Styles for `.media--new` midifier
  }
}

We could also create a block mixin in the same fashion but it would not be that helpful as a block is nothing but a single class name. Let”s keep it simple. Although, for some people modifier and element seemed too long to type so we saw a few e and m blooming.

我们也可以以相同的方式创建一个block mixin，但是它并不是很有用，因为一个块不过是一个单一的类名。 让我们保持简单。 虽然，对于某些人来说， modifier和element似乎太长而无法键入，所以我们看到一些e和m开花。

.media {
  // Styles for `.media` block

  @include e("image") {
    // Styles for `.media__image` element

    @include m("full") {
      // Styles for `.media__image--full` modified element
    }
  }

  @include m("new") {
    // Styles for `.media--new` midifier
  }
}

优点 (Pros)

• This version provides a friendly API that is easy to understand once you know what BEM is and how it works.
  此版本提供了一个友好的API，一旦您知道BEM是什么以及它如何工作，就易于理解。

缺点 (Cons)

• The logic is hidden behind mixins and unless you explicitly know what is going on, it is not that obvious that new selectors and classes are getting generated.
  逻辑隐藏在mixins的后面，除非您明确知道发生了什么，否则不会明显产生新的选择器和类。

• Single letter mixins are probably not a good idea as they make it hard to understand the purpose of the mixin. b and m could mean a lot of things.

  单字母混合可能不是一个好主意，因为它们很难理解混合的目的。 b和m可能意味着很多事情。

人源化BEM混合蛋白 (Humanified-BEM mixins)

Lately, I read about a new BEM-like approach by Anders Schmidt Hansen. The idea is to hide the Block-Element-Modifier jargon behind a common vocabulary that makes sense when read out loud.

最近，我读到了Anders Schmidt Hansen提出的一种类似于BEM的新方法 。 这个想法是在大声读出有意义的普通词汇之后隐藏“块元素修饰符”行话。

@mixin new($block) {
  @at-root .#{$block} {
    @content;
  }
}

@mixin has($element) {
  &__#{$element} {
    @content;
  }
}

@mixin when($modifier) {
  &--#{$modifier} {
    @content;
  }
}

In this case, the whole point is to hide the code behind carefully named mixins so that it looks like the code is telling a story so the new mixin actually happens to be useful.

在这种情况下，重点是将代码隐藏在精心命名的mixin后面，以使代码看起来像个故事，因此new mixin实际上是有用的。

@include new("media") {
  // Styles for `.media` block

  @include has("image") {
    // Styles for `.media__image` element

    @include when("full") {
      // Styles for `.media__image--full` modified element
    }
  }

  @include when("new") {
    // Styles for `.media--new` midifier
  }
}

Anders goes a step further with is(..) and holds(..) mixins. The whole idea kind of reminds me of my when-inside(..) mixin to hide the & behind a human-friendly mixin when styling an element based on its upper context.

Anders在使用is(..)和holds(..) mixins方面走得更远。 整个想法让我想起了我的when-inside(..) mixin ，当根据其上部上下文对元素进行样式设置时，将&隐藏在人类友好的mixin后面。

@mixin when-inside($selector) {
  #{$selector} & {
    @content;
  }
}

img {
  display: block;

  @include when-inside(".media-inline") {
    display: inline;
  }
}

优点 (Pros)

• This approach helps making the code more readable, kind of like when we started naming our stateful classes with a leading is- (popularised by SMACSS).

  这种方法有助于使代码更易读，有点像当我们开始与一家领先的命名我们的状态类is- (由SMACSS普及)。

• Still sticks with a specific methodology (in this case BEM), but makes it more friendly for the developers.
  仍然坚持使用特定的方法(在本例中为BEM)，但使开发人员更友好。

缺点 (Cons)

• More mixins, more helpers, more things to learn for a steadier learning curve. Everybody does not like dealing with tons of mixins to write simple things such as CSS selectors.
  更多的mixin，更多的帮助者，更多的东西要学习，以使学习曲线更稳定。 每个人都不喜欢处理大量的mixins来编写诸如CSS选择器之类的简单内容。
• This might be too much abstraction for some people; not everybody likes to read code the way they read English. It depends.
  对于某些人来说，这可能太抽象了。 并非每个人都喜欢阅读英语的方式来阅读代码。 这取决于。

最后的想法 (Final thoughts)

Remember that using any of those techniques will prevent the selector codebase from being searchable since the selectors do not actually exist until they get generated by Sass. Adding a comment before selectors would solve the problem but then why not writing the selector directly in the first place?

请记住，使用任何一种技术都将阻止选择器代码库的搜索，因为选择器实际上只有在Sass生成选择器之后才存在。 在选择器之前添加注释可以解决问题，但是为什么不首先直接编写选择器呢？

Don’t use the new Sass features to BEM-ify all your selectors (.b { &__e { } }) if you care about having a searchable codebase.

如果您关心拥有可搜索的代码库，请不要使用新的Sass功能对所有选择器(.b {＆__ e {})进行BEM修饰。

— Kaelig (@kaelig) March 12, 2014

— Kaelig(@kaelig) 2014年3月12日

Anyway folks, here are the most popular ways I know to write CSS selectors with the help of Sass and between you and I, I dislike them all. And not only for the searching issue, which is not that big of a deal to me.

无论如何，这是我知道在Sass的帮助下编写CSS选择器的最流行的方式，在您我之间，我都不喜欢它们。 而且不仅是搜索问题，这对我来说没什么大不了的。

I can see the problem they are trying to solve, but sometimes simple is better than DRY. Repeating a root selector is not that big of a deal, and not only does it make the code easier to read because of less nesting, it also sticks closer to CSS.

我可以看到他们正在尝试解决的问题，但有时简单胜于DRY。 重复一个根选择器没什么大不了的，而且因为嵌套少，它不仅使代码更易于阅读，而且更贴近CSS。

Sometimes simple is better than DRY.

有时简单胜于DRY。

— Hugo Giraudel (@HugoGiraudel) May 19, 2015

— Hugo Giraudel(@HugoGiraudel) 2015年5月19日

翻译自: https://www.sitepoint.com/structuring-css-class-selectors-with-sass/

css sass