Gunnar Bittersmann: Selektorenkonkatenation mit Präprozessor ja/nein/vielleicht?

Beitrag lesen

@@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

--
„Sag mir, wie Du Deine Maske trägst, und ich sage Dir, ob Du ein Idiot bist.“ —@Ann_Waeltin

  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. ↩︎