Übersetzung: Ihr BEM verschachteln?

Originallink: http://csswizardry.com/2016/11/nesting-your-bem/

Bevor ich mit diesem Artikel beginne, muss ich sagen, dass es sich hier nicht um einen Vorschlag oder einen neuen „Praxisleitfaden“ handelt. Das sind nur einige meiner eigenen Fantasien.

Ich bin ein Befürworter und Unterstützer von [BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/). Und das schon seit vielen Jahren. Es macht irgendwie Spaß, sich darauf zu freuen. Natürlich versorgt es mich mit vielen Dingen:

* **Soft Encapsulation** Dies hilft, Namenskonflikte zu reduzieren.
* **Benutzerdefiniertes CSS** Dies hilft mir zu verstehen, wie DOM-Knoten miteinander in Beziehung stehen.
* **Zielauswahl** Dies trägt dazu bei, Konflikte zwischen Teilbäumen zu reduzieren und die Erfassung zu vieler Knoten zu vermeiden.
* **Spezialität des Managementstils** Dies ist ein großes Highlight.
* **Strenge Implementierungsregeln** Dies verhindert, dass ich Klassen außerhalb des gegebenen Kontexts verwende.

Bis auf den letzten Punkt, der nur zur Hälfte wahr ist...

BEM sagt uns, dass eine Klasse, zum Beispiel: „.widget__title“, nur innerhalb von „.widget“ verwendet werden kann. Dies ist jedoch nur eine Bestimmung der Vereinbarung. Ein Entwickler könnte „.widget_title“ in „.model“ einfügen und es trotzdem funktionieren lassen. Das liegt daran:

* Sie haben BEM noch nie gesehen oder wissen nicht, wie man es implementiert
* Sie sind faul und finden heraus, dass sie .widget_title innerhalb von „.modal“ wiederverwenden können, obwohl sie es nicht sollten „Stil, und dann können Sie die Arbeit 5 Minuten früher abschließen

Sie können es und es funktioniert für sie: Die Dinge werden immer noch korrekt angezeigt. Dies führt nicht zu weiteren Fehlern, da es sich bei BEM lediglich um eine Verordnung handelt und Regelungen einer einstimmigen Zustimmung bedürfen.

Um dies zu umgehen, können wir CSS wie folgt schreiben:

```
.widget { }

.widget .widget__title { }
```

Jetzt können Entwickler „.widget_title“ nicht in „.modal“ verwenden, da wir unserem CSS mitgeteilt haben, dass „wideget_title“ nur funktioniert, wenn wir es in „.widget“ einfügen. Jetzt beginnen wir mit der Durchsetzung dieser Dinge, um Missbrauch vorzubeugen.

Hier gibt es ein weiteres Problem: die Verschachtelung

## Verschachtelung in CSS

Ich habe [aktiv argumentiert](http://cssguidelin.es/#pecificity), dass die Verschachtelung in CSS eine schlechte Sache ist, weil:

* fügt Funktionen hinzu (diese sollten immer verwaltet werden);
* führt zu einer Abhängigkeit von Speicherorten (ein Zeichen für unflexible Systeme);
* verringert die Portabilität (was bedeutet, dass wir es nicht nach Belieben verschieben können) ;
* Erhöhte Fragilität (verschachtelt bedeutet erhöhte Wahrscheinlichkeit falscher Selektoren).

Zusammenfassend: [Halten Sie Ihre CSS-Selektoren kurz](http://csswizardry.com/2012/05/keep-your-css-selectors-short/

).

Aber im Fall der Verwendung von verschachteltem BEM sehen wir, dass die Verschachtelung uns echte Vorteile bringt. Doch wie gehen wir mit diesen Mängeln um?

## Spezifität

Beachten Sie, dass es generell wichtig ist, immer eine niedrige Spezifität beizubehalten. Das ist absolut wahr und es ist ein toller Rat. Allerdings gibt es hier einen kleinen Unterschied zu den uns bekannten. Wenn Leute sagen, dass die Spezifität in allen Fällen gehandhabt werden sollte, meinen sie in Wirklichkeit, dass wir die Konsistenz wahren und kaum Unterschiede zwischen den Selektoren haben sollten.

Theoretisch (aber bitte versuchen Sie es nicht) ist der einzige Selektor für ein Element der ID-Selektor, der die Spezifität gut verwalten würde: Die Spezifität ist im Allgemeinen hoch, aber zumindest alle konsistent und gleich.

Wenn wir darüber sprechen, wie mit dem Problem der Konsistenz umzugehen ist, beziehen wir uns auf seine [Spezifitätskarte](http://csswizardry.com/2014/10/the-pecifity-graph /) möglichst flach.

Wenn wir uns die folgende Reihe von CSS-Komponenten ansehen:

```
.nav-primary { }

.nav-primary__item { }

.nav-primary__link { }

.masthead { }

.masthead__media { }

.masthead__text { }

.masthead__title { }

.sub-content { }

.sub-content__title { }

.sub-content__title--featured { }

.sub-content__img { }
```

…Wir haben festgestellt, dass jede ihrer Klassen genau die gleichen Besonderheiten aufweist. Dies ist ein schönes flaches Spezifitätsdiagramm:


[Größeres Bild anzeigen](http://csswizardry.com/wp-content/uploads/2016/11/graph-speciality-01.png)< figcaption>

Sobald wir diese Klassen wie folgt verschachteln:

```
.nav-primary { }

.nav-primary .nav-primary__item { }

.nav-primary .nav-primary__link { }

.masthead { }

.masthead .masthead__media { }

.masthead .masthead__text { }

.masthead .masthead__title { }

.sub-content { }

.sub-content .sub-content__title { }

.sub-content .sub-content__title--featured { }

.sub-content .sub-content__img { }
```

…das Spezifitätsdiagramm, das wir sehen, sieht folgendermaßen aus:


[Größeres Bild anzeigen](http://csswizardry.com/wp-content/uploads/2016/11/graph-speciality-02.png)< figcaption>

Oh mein Gott! Spikes sind genau das, was wir vermeiden wollen, da sie Schwankungen in der Spezifität zwischen Selektoren darstellen, die im Projekt sehr nahe beieinander liegen.

Hier veranschaulichen wir den spezifischen Nachteil der Verschachtelung. Können wir das vermeiden? Wie?

## Verlinke die erste Klasse

Wenn wir die erste Klasse (den Block) mit sich selbst verknüpfen möchten, gehen Sie folgendermaßen vor:

```
.nav-primary.nav-primary { }

.nav-primary .nav-primary__item { }

.nav-primary .nav-primary__link { }

.masthead.masthead { }

.masthead .masthead__media { }

.masthead .masthead__text { }

.masthead .masthead__title { }

.sub-content.sub-content { }

.sub-content .sub-content__title { }

.sub-content .sub-content__title--featured { }

.sub-content .sub-content__img { }
```

…wir können dafür sorgen, dass alle verschachtelten Elemente gezielt und ohne Nebenwirkungen abgeglichen werden:

* Wir müssen die Position dieses Blocks im DOM nicht kennen, daher werden wir seine Spezifität nicht aufgrund einiger möglicher sich ändernder Positionen erhöhen
* Wir stellen keine Verbindung zu einem anderen anderen oder spezifischen Element her oder Klasse. Dies bedeutet, dass die Block-Klasse immer noch sehr leichtgewichtig ist.

Dieser Anstieg der Spezifität ist völlig eigenständig, und jetzt sehen wir eine Spezifitätskarte wie diese:


[Größeres Bild anzeigen](http://csswizardry.com/wp-content/uploads/2016/11/graph-speciality-03.png)< figcaption>

Größer als das erste Bild, aber immer noch sehr glatt. Auch wenn unsere Spezifität zwei Ebenen hoch ist, ist sie dennoch gut gemanagt: Unsere Selektorkomponente hat kein besonderes Gewicht.

## Vereinfachen mit Sass

Um das Verschachteln und Verknüpfen zu vereinfachen, können wir eine Vorverarbeitung verwenden, in diesem Fall Sass:

Wir sollten alle damit vertraut sein, wie man reguläre Selektoren in Sass verschachtelt:

```
.nav-primary {

.nav-primary__item { }

.nav-primary__link { }

}
```

Das bringt uns, genau wie wir es erwartet haben:

```
.nav-primary { }

.nav-primary .nav-primary__item { }

.nav-primary .nav-primary__link { }
```

Aber wie verknüpfen wir die erste Klasse schnell und effizient mit sich selbst? So:

```
.nav-primary {

{&} { }

.nav-primary__item { }

.nav-primary__link { }

}
```

Durch die Verwendung von „{&}“ können wir die aktuelle Klasse mit sich selbst verknüpfen. Das bedeutet, dass alle Stile unseres Blocks (in diesem Fall „.nav-primary“) hier sind:

```
.nav-primary {

{&} { /* Blockstile */ }

}
```

[Sehen Sie sich ein kleines Beispiel über Sassmeister an](http://www.sassmeister.com/gist/a14e5b242ee6b20932dd44df0a3d215c)

## Tatsächliche Ergebnisse

Jetzt befinden wir uns in einer Situation, in der wir tatsächlich die Verwendung von Selektoren erzwingen und aktiv verhindern, dass sie wirksam werden – wenn wir sie aktiv aus dem richtigen Teil des DOM verschieben. Dies hilft uns, in Umgebungen zu arbeiten, in denen andere Entwickler nicht wissen, wie BEM funktioniert, oder Leute sind, die dazu neigen, herumzuspielen, bis alles richtig aussieht.

Wir haben auch eine Besonderheit, die alle Klassen verwaltet (wenn auch erhöht)

### Mängel

Wir fügen einige Besonderheiten hinzu, die wir im Allgemeinen immer vermeiden sollten.

## Anwendungsfall

Wenn Sie versuchen möchten, diese Technologie zu erweitern, müssen Sie vor Beginn einige wichtige Anwendungsfälle identifizieren. Das erste, was mir in den Sinn kam, waren Grid-Systeme. Immer wieder sehe ich Entwickler, die versuchen, zusätzlich zur übergeordneten Klasse „.grid“ die Klasse „.grid__item“ zu verwenden. Wenn ich also anfangen würde, diese Technik anzuwenden, würde ich hier beginnen:

```
.grid.grid { }

.grid .grid__item { }
```

## Verwenden oder nicht verwenden?

Ich bin mir nicht sicher, wie ich eingangs sagte, dass es sich hierbei nicht um eine Technologie handelt, die ich wärmstens empfehle oder zu der ich mich verpflichte. Ich wollte es nur als Referenz ansprechen, insbesondere für Entwickler, die sich in einer Umgebung befinden, in der andere Entwickler CSS so leicht missbrauchen.

Was ich jedoch sagen möchte ist: Wenn Sie Ihr BEM verschachtelt haben, gehen Sie bitte zurück und reduzieren Sie Ihre Spezifitätskarte, indem Sie Ihre erste Klasse verknüpfen.