News

BEM: 3 Tipps für bessere CSS-Architektur

Mit BEM machst du deine Frontend-Architektur skalierbar. (Grafik: BEM)

BEM. Wer sich mit Frontend-Architektur beschäftigt, wird um die Methodik der „Block, Element, Modifier“ nicht herumkommen. In diesem Artikel lest ihr, wie ihr BEM für eure Projekte spezifizieren und optimieren könnt.

Crashkurs zu Block, Element, Modifier

BEM dient dazu, eine skaliebare CSS-Architektur aufbauen zu können und ist vergleichbar mit SMACSS oder OOCSS. Dabei werden einzelne Strukturen im DOM nur mit Klassennamen nach einem bestimmten Muster benannt, um den Code leichter lesbar und skalierbarer zu machen. Das Muster beziehungsweise die Naming-Convention dazu ist: .block__elment--modifier{} oder .block--modifier{}.

bem

Mit BEM machst du deine Frontend-Architektur skalierbar. (Grafik: BEM)

Praktisch angewendet wäre folgendes Beispiel denkbar: .sidebar__advertisment-square. Damit ist es sofort erkennbar, dass es sich um ein Element handelt, dass sich in der Sidebar befindet und Werbung im quadratisches Format enthält. Um das noch genauer zu verdeutlichen, möchte ich euch mehrere Beispiele zeigen:

.sidebar__form{}
.sidebar__advertisement{}
.sidear__navigation{}

Im Sinne der Code-Convention ist jetzt zu erwähnen, dass es von einem bestimmten Code-Block Varianten geben kann. Ein Beispiel um das zu verdeutlichen:

.sidebar__form--newsletter {}
.sidebar__advertisement--125x125{}
.sidebar__navigation--secondary{}

Wie oben bereits angesprochen, erlaubt BAM aber auch eine Variation von „Blocks“. Somit ist .navigation--secondary durchaus möglich, um eine Sub-Navigation kennzeichnen zu können.

Höheres UX für Entwickler: BEM anpassen

Simurai hat in seinem Blog erläutert wie er BEM adaptiert hat, um damit im Team besser arbeiten zu können:

.digit-Progress{}          /* org-Component */
.digit-Progress-bar{}      /* org-Component-childElement */
.digit-Progress--small{}   /* org-Component--variation */

Dabei ist digit ein klassischer Namespace, um Konflikte zwischen einzelnen Projekten zu vermeiden. Wie ihr seht, gibt es kleinere Unterschiede zum klassischen BEM:

1. BEM-Adaption: Bindestrich vs. Unterstrich

BEM-2

Text-Markierung mit angepassten BEM. (Animation: Simurai)

Der Hauptgrund warum hier von Unterschrich auf Bindestrich gewechselt wurde, ist ganz einfach: Somit lässt sich der Text besser markieren.

Wenn Wörter mit Unterstrichen verbunden werden, dann wird bei einem Doppelklick das gesamte Konstrukt markiert. Wenn allerdings ein Bindestrich genutzt wird, könnt ihr nur einzelne Wörter per Doppelklick markieren. Das erleichtert etwas den Workflow.

2. BEM-Adaption: CamelCase

Ein kleines Problem gibt es, wenn der Block oder das Element aus mehreren Wörtern besteht. Ein möglicher Ansatz wäre, dass man einen weiteren Bindestrich einsetzt, allerdings würde das den Lesefluss erheblich stören – Wörter könnten aber trotzdem mit einem Doppelklick selektiert werden. CamelCase ist hier eine Alternative: Der Lesefluss wird nicht verschlechtert und es kann trotzdem noch via Doppelklick markiert werden.

3. BEM-Adaption: MainComponent

In diesem speziellen Workflow werden die Haupt-Komponenten, also „Blocks“ mit einem großen Buchstaben am Anfang geschrieben, um sie leichter von „Elementen“ unterscheiden zu können. Sollte, wie am Anfang des Artikels erwähnt, Namespacing zum Einsatz kommen, ist es auch hier leichter den Komponentennamen beziehungsweise, den des „Blocks“, zu erfassen.

–variation

Die Trennung durch zwei Bindestriche bei unterschiedlichen Varianten wurde beibehalten, weil sich die Varianten dadurch besser von Elementen unterscheiden lassen.

Fazit: BEM in Projekten

Ich finde den Ansatz den Simurai dahinter verfolgt gut und sinnig. Desweiteren macht es Sinn, auf das Anwendererlebnis der Entwickler zu achten, denn diese sind in diesem Use-Case auch die Hauptnutzer.

Mehr zum Thema BEM findet ihr auf der offiziellen Website.
Wie sieht eure Naming-Convention aus?

Vielleicht auch interessant: Ihr wollt Dropdown-Menüs mit CSS erstellen?? Hier findet ihr Tutorials und Demos, die euch weiterhelfen.

via simurai.com

Zur Startseite
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

6 Kommentare
topas
topas

Nur eine kleine Verständnisfrage: Was spricht bei dem in der Animation genannten Beispiel gegen den Code:

Es ist kompakter, übersichtlicher, weniger Tipp-Arbeit, Attribute werden „vererbt“, da die CSS kaskadiert, man kann die Gültigkeitsbereiche besser steuern („–small“ ist immer 90% font-size, anstatt es 40 mal für verschiedene Konstellationen zu hinterlegen). Wer will kann mittels „.digit-Progress .small“ immer noch nachjustieren, mit „.digit-Progress>small“ sogar punktgenau landen. Und mittels lessCSS kann man den ganzen Spaß auch leicht programmieren und abstrahieren.
Wieso sollte man also auf all die Features von Kontext-Selektoren, Kaskadierung und Spezifität verzichten und stattdessen den Quellcode unnötig vergrößern?

Antworten
dgshsbd
dgshsbd

Durch Spezifität und Kaskadierung bringst du unnötige Komplexität hinein. Da es in CSS kein Mittel gibt die Kaskade zu unterbrechen, kann man nur durch höhere Spezifität das Vorherige Überschreiten wodurch ein Teufelskreis entsteht.
Zu starkes Nesting ist auch problematisch, da dadurch die Wiederverwendbarkeit leidet und die die CSS-Struktur zu DOM-zentriert wird.

Antworten
Marco Willi
Marco Willi

Interessant, aber wie oben schon geschrieben auch mehr Quellcode. Kommt auf die größe des Teams und Projekts an denk ich.

@Mario
Sind ein paar Rechtschreibfehler noch im Text. Auch einmal „BAM“ statt „BEM“. Gruß.

Antworten
Jan

Hm. An manchen Stellen macht das vielleicht Sinn, ja. Aber die Form oder sogar genaue Angaben wie z.B. „125×125“ in die Benennung der Klasse einzuführen finde ich eine ->ziemlich<- schlechte Idee.

CSS ist dazu da das Design von der Struktur des Codes zu trennen. Wenn man die CSS-Klassen schon mit "125px" benennt, dann kann man ja gleich den style direkt ins HTML-Tag reinschreiben. "Liest sich ja auch schnell.."

Man macht ja den ganzen Spaß, sodass man die CSS-Dateien einfach austauschen kann und die Webseite, trotz gleichem DOM ein komplett anderes Design hat. Wenn man aber die Klassennamen schon mit der Form, z.B. "square" versieht, dann muss der Designer entweder die box quadratisch lassen (wozu dann redesign), oder die Klasse heißt halt square, ist sie aber später nicht mehr. Ich hatte mal sowas auf einigen Websites.. das macht echt keinen Spaß das zu fixen..

Antworten
Marco Willi
Marco Willi

Dem stimme ich zu.
Allerdings denke ich nicht, dass es viele Anwendungsfälle in der Praxis gibt, in denen man wirklich das Layout mittels CSS-Austausch verändern will.

Antworten
Abbrechen

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung