Worauf kommt es bei der expliziten Benennung der Nachkommenklasse in Anwesenheit von SCSS an?

Question

Ich versuche, die Gründe hinter CSS-Namenskonventionen wie BEM oder SUITCss zu verstehen und zu verstehen. Es fällt mir schwer, den Wert der Namen von Nachkommenklassen in Gegenwart von SCSS zu verstehen.

Zum Beispiel:

<ul class="menu"> 
    <li class="menu__item"></li> 
    <li class="menu__item"></li> 
    <li class="menu__item"> 
     <a href="#" class="menu__item_link">link</a> 
    </li> 
</ul> 

.menu { 
    .menu__item { 
     //styles 
     .menu__item__link { //styles } 
    } 
    //or alternatively this syntax.. 
    &__item { //styles } 
} 

Mit der Fähigkeit zur Nest Regeln in SCSS, ich sehe die zwingenden Gründe nicht für mich, die Vorfahren Klassennamen in meinem Code enthält. Oben habe ich Stile definiert, die nur für ein "Element" innerhalb eines "Menüs" verwendet werden sollten, indem man Klassennamen von Nachkommen verwendet. Die verschachtelte Struktur teilt dies jedoch bereits mit! Die Regeln für menu__item würden ohnehin nur für ein Element in einem Menü gelten. Warum muss ich das also in den Klassennamen aufnehmen?

Warum nicht:

<ul class="menu"> 
    <li class="item"></li> 
</ul> 

.menu { 
    .item {//styles} 
} 

Ich verstehe, dass der Nachkomme Namenskonvention deutlicher und vielleicht mehr Zukunft freundlich. Ich argumentiere jedoch, dass es im HTML nur expliziter ist. Wenn ich mich fragen wollte, wie man dieses "Menü" -Modul erstellt, könnte ich einfach das CSS konsultieren und sehe genauso klar, wie ein Menü Elemente darin verschachtelt hat.

Ich denke, ein möglicher Vorteil ist, dass ich meine CSS un-verschachtelt schreiben könnte, etwa so:

.menu { //styles } 
.menu__item { //styles } 
.menu__item__link { //styles } 

und verwenden Sie dann ein „menu__item“ überall und es wäre immer noch in den Klassennamen, dass diese explizit war das Styling eines Gegenstandes unter einem Menü..aber warum definieren Sie es dann als Nachkomme eines Menüs? (Ein anderer Vorteil, nehme ich an, ist kürzere CSS-Bezeichner-Zeichenfolgen, wenn Dinge nicht verschachtelt sind)

Es scheint mir, dass, wenn ein Klassenname als ein Nachfolger unter einem anderen verwendet werden soll, dies in SCSS erreicht und präsentiert diese Logik klar. Warum sollte diese BEM-Syntax dann notwendig sein?

Ich möchte jemanden hören, der die Argumentation dieser Art von Konvention erklärt. Ich möchte mich an so genannte Best Practices halten, aber es ist schwer für mich, dies blind zu tun, ohne eine Konvention zu verstehen.

Answer 1

Beginnen wir mit der Idee von BEM oder SMACSS.

Die Hauptaufgabe jeder Methode ist die Strukturierung und Modularisierung Ihres Codes.

Zum Beispiel BEM Verwendung folgende Abstraktionen:

Blocken - unabhängiger Teil UI (wie Feedback-Form),

Element - Teil des Blockes Überhöhung ohne Block vorhanden ist (wie Feedback Form Schaltfläche) ,

Modifikator - Helfer, mit dem Sie Block oder Element ändern können (wie Knopf größer oder kleiner machen).

SMACSS verwenden verschiedene Abstraktionen: Modul, Layout, Basis, Status, Thema. Um klar auf die Idee kam, sich vorstellen, Ihre HTML-Seite aus logischen Schichten enthält,

1) BASE - Sie CSS-Resets hinzufügen, definieren H1, H2 ...Schriftgrößen, definieren Farben. Also in der Basis legen Sie Dinge als sollte geändert werden.

2) LAYOUT - fügt Gitter oder separate Seite in Regionen hinzu. 3) Modul - unabhängig Inhalt Artikel

3) STATE - ganz in der Nähe BEM Modifikator aber mit einer Aktion mit dem Modul verbunden, wie is_hided, is_collapsed

4) Theme - kann für BASE Überschreibung verwendet werden .

Um diese Abstraktionen zu trennen, müssen Sie einer Namenskonvention folgen, damit Sie auf den ersten Blick verstehen, was diese Klasse macht. Wenn Sie der Namenskonvention folgen, ist es auch viel einfacher, Ihr Projekt zu verwalten. Es ist leicht, neuen Teammitgliedern zu erklären, wie Code organisiert ist und wie man neuen Code schreibt, der wie von einer Person geschrieben aussieht.

Es ist extrem wichtig in großen Projekten mit großen Teams.

Außerdem können Sie mit der Namenskonvention die Anzahl der Nachkommenselektoren verringern, die die Leistung verbessern.

Answer 2

Mehrere Bemerkungen.

1/Zuerst

.menu { 
    .menu__item { /* ... */ } 
    //or alternatively this syntax.. 
    &__item { /* ... */ } 
} 

Die beiden SCSS Syntaxen sind nicht äquivalent. Der erste verwendet eine Kaskade (".menu .menu__item"), nicht die zweite (".menu__item"). Nur der zweite ist BEM-konform.

2/Warum nicht eine Kaskade:

.menu { 
    .item { /* styles */ } 
} 

BEM ermöglicht Skalierbarkeit. Wenn wir CSS schreiben, konzentrieren wir uns nur auf einen kleinen Kontext: den Block. Und jeder Block kann viele Male wiederverwendet werden.

Aber Kaskaden sind nicht kontextfrei. In Ihrem Beispiel gibt es ein Block "Menü", das ein Element "Element" enthält. Der Kontext des Elements "item" ist der Block "menu". Die Kaskade unterbricht jedoch die Kontexttrennung für die Unterblöcke. Eine vorangestellte BEM-Syntax erlaubt das Verschachteln von Blöcken, die Kaskade nicht. Zum Beispiel:

<ul class="menu"> 
    <li class="menu__item"></li> 
    <li class="menu__item"> 
     <div class="other-block"> 
      <span class="other-block__item"></span> 
     </div> 
    </li> 
</ul> 

Beachten Sie das Element "Element" im Unterblock. Mit einer Kaskade anstelle eines Präfix würde es durch eine Regel gestylt, die auf die Elemente "Element" des Elternblocks abzielt.

3/Diese Klasse Name ist nicht BEM-konform:

.menu__item__link { /* styles */ } 

Elemente bieten keinen Zusammenhang. Nur Blöcke bieten Kontexte. Der Kontext eines Elements ist der Kontext seines Blocks. Daher ist "link" kein Nachkomme von "item" in der BEM-Struktur. Die beiden sind Brüder, unabhängig von ihren Situationen im DOM-Baum. Sie sollten verwenden:

.menu { /* styles */ } 
.menu__item { /* styles */ } 
.menu__link { /* styles */ }