Selektorenkonkatenation mit Präprozessor ja/nein/vielleicht?

[Gunnar Bittersmann]

In CSS-Präprozessoren könnte man Nesting und Stringkonkatenation nutzen, um Selektoren zusammenzubasteln, bspw. aus

.block {
  property1: value1;
    
  &__element {
    property2: value2;
        
    &--modifier {
      property3: value3;
    }
  }
}

dieses zu generieren:

.block {
  property1: value1;
}

.block__element {
  property2: value2;
}

.block__element--modifier {
  property3: value3;
}

Aber sollte man das tun? Oder besser lassen?

Kennt jemand Artikel, die Vor- und Nachteile gegenüberstellen?

😷 LLAP

PS: Was ich von BEM halte, tut hier nichts zur Sache. 😉

[Rolf B]

Hallo Gunnar,

Artikel habe ich nicht, aber wenn Du das BEM Konzept nutzt und einen CSS Präprozessor verwendest, dann wäre es durchaus im Sinne von DRY, mit Konkatenation zu arbeiten. Wenn Konkatenation auch in Regel-Mixins funktioniert, erlaubt Dir das eine ganz ordentliche Wiederverwendbarkeit von Mixin-Blöcken.

Ob das effizient ist, ist eine andere Frage. Das Performance-Problem bei CSS ist ja dem Vernehmen nach eine große Masse an Regeln.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Ob das effizient ist, ist eine andere Frage. Das Performance-Problem bei CSS ist ja dem Vernehmen nach eine große Masse an Regeln.

Den Gedankengang verstehe ich nicht.

Hier ging’s doch um den Quelltext – ob die erste oder die zweite Variante besser lesbar und wartbar ist. Beim Client kommt in beiden Fällen derselbe CSS-Code an.

😷 LLAP

[Rolf B]

Hallo Gunnar,

ich sprach von der Regelinflation, die BEM und das unbedachte Einbinden von Mixins mit sich bringen.

Ohne BEM ist man - denke ich - generischer unterwegs und braucht weniger Regeln, und hat natürlich die Gefahr, dass eine Änderung weiter wirkt als man es sich gedacht hat.

Rolf

[djr]

Dagegen spricht für mich die Erfahrung, dass die IDE nicht mit den zerstückelten Klassennamen klar kommt. Z.B. wenn sie aus dem HTML-Dokument heraus beauftragt wird, die Style-Definition(en) von block__element zu finden. Ist in der .scss-Datei block__element ausgeschrieben, dann wird es gefunden, zerstückelt nicht. Gleiches gilt auch bei automatischem Rewrite des Klassennamens.

Ich lasse mich hier aber gerne korrigieren. Vllt kennt jemand den Konfigurationstrick, das passende Plugin oder kann bestätigen, dass seine IDE das in der aktuellen Version nativ kann.

[djr]

Viel mehr Schreibarbeit ist das Ausschreiben auch nicht, denn ist .block einmal definiert, wird es bei der Eingabe von .b schon direkt von der IDE vorgeschlagen und kann mit einem Tastendruck übernommen werden.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

In CSS-Präprozessoren könnte man Nesting und Stringkonkatenation nutzen, um Selektoren zusammenzubasteln […] Aber sollte man das tun? Oder besser lassen?

Ich hab die Frage auch im Vogelnest gestellt. Ziemlich einhellige Meinung in den Antworten: nicht machen.

Jannis Borgers:
Die Selektoren mag ich immer lieber eins zu eins im Stylesheet haben. Wenn ich im Browser debugge und die zusammengesetzte Klasse sehe kopiere ich mir oft den Namen. Das bringt mit Nesting in der SCSS-Datei dann leider nichts. Es macht‘s auch unnötig kompliziert, finde ich.^[1]

Stephan Zavodny:
Sehe ich ganz genauso.^[2]

Webrocker:

.block {
  &__element {}
  &--modifier {}
}

finde ich bei 'kurzen' modulen recht übersichtlich.
bei umfangreicheren dingern habe ich aber bemerkt, dass ich in zeile 1000+ schneller ein .block__element {} erkenne, als ein &__element {}^[3]

Manuel Strehl:
Von außen leidet auch die Grepability. Ich hab ein Whitelabel-Produkt mit ~ 100 Kundenstylesheets. Wenn ich wissen will, welches .block__element verwendet, schießt mir die Sass-Syntax gründlich ins Bein.^[4]

Marco Hengstenberg:
Biste der einzige Entwickler im Dorf: egal.
Wenn nicht: eher nich machen. Wenn konkatidings, dann nur mit Pseudo-Elementen oder zwei Klassen (kommt beides auch eher selten vor).
Übersichtlichkeit und Lesbarkeit leidet ungemein finde ich.
Meine Meinung. Kann man auch anders sehen.
Und was @jannisborgers sagt.^[5]

Schuer:
Nicht verwenden, sondern lieber ausschreiben. Macht es merklich einfacher auffindbar.^[6]

Nico Hagenburger:
Nachteil mit &: Globale Suche nach Klassennamen im Editor wird unmöglich. Insbesondere die Kollegen, die nicht täglich mit Sass arbeiten, ist das sicher nervig.^[7]

Das deckt sich mit meiner Meinung:
Ich hab auch ’ne Meinung dazu; wollte euch aber nicht beeinflussen.
&__element finde ich auch grausam, aus den genannten Gründen: unübersichtlich (wofür & steht, ist 2 Bildschirmseiten höher), schlecht durchsuchbar (TIL “grepability” 😂), undurchsichtige Verschachtelung (wenn man dann noch blöderweise Spaces statt Tabs verwendet und die Einrückungstiefe nicht mal eben ändern kann, verliert man da schnell den Überblick).
&::before und &::after finde ich OK. Mit &--modifier kann ich auch noch leben; das bezieht sich ja auch aufs selbe Element. (Sofern man BEM überhaupt einen Sinn abgewinnen kann).
&__element bezieht sich auf was ganz anderes; deshalb würd ich das tunlichst vermeiden.^[8]

😷 LLAP

---

1. https://twitter.com/jannisborgers/status/1313382560119115776 ↩︎

2. https://twitter.com/rastersysteme/status/1313383360497156096 ↩︎

3. https://twitter.com/webrocker/status/1313381212975779842 ↩︎

4. https://twitter.com/m_strehl/status/1313391804130131969 ↩︎

5. https://twitter.com/nice2meatu/status/1313385353743654913 f. ↩︎

6. https://twitter.com/_DECAF/status/1313409548938547201 ↩︎

7. https://twitter.com/Hagenburger/status/1313517389397532672 ↩︎

8. https://twitter.com/g16n/status/1313500136002248705 ff. ↩︎