Es gibt viele CSS-Methoden, und ich hasse sie alle. Manche mehr (Rückenwind & Co.) und manche weniger (BEM, OOCSS, etc.). Aber letzten Endes haben sie alle Mängel.

Menschen nutzen diese Ansätze natürlich aus guten Gründen, und viele der angesprochenen Probleme sind auch bei mir der Fall. Deshalb möchte ich in diesem Beitrag meine eigenen Richtlinien für die Organisation von CSS aufschreiben.

Dies ist keine vollständig beschriebene CSS-Methodik, die jeder einfach verwenden könnte. Vielleicht könnte man daraus mit etwas mehr Arbeit eines machen, aber der Zweck dieses Beitrags besteht lediglich darin, zu zeigen, wie ich diese Entscheidungen beim Schreiben von CSS treffe.

Eingebaute Elemente

Als Faustregel versuche ich, so oft wie möglich integrierte Elementtypen zu verwenden und so wenig unnötigen Aufwand wie möglich zu machen.

Der Bedarf an tausend verschiedenen Arten von Schaltflächen ist ein Zeichen dafür, dass auf einer tieferen Ebene möglicherweise etwas mit dem Design nicht stimmt. In manchen Fällen finde ich es jedoch reizvoll, dass CSS inaktiv bleibt, bis Framework-spezifische Klassen verwendet werden , in den meisten Fällen halte ich es für ideal, wenn ein Button nur Click Me! ist und wie ein Button ohne weitere Magie aussieht.

div.btton sollte sich in eine Schaltfläche

verwandeln

Benutzerdefinierte Elemente

Nicht alle Designelemente haben ein semantisch passendes HTML-Äquivalent, und in diesen Fällen greife ich normalerweise auf benutzerdefinierte Elemente zurück.

Ich habe nicht viele Fälle gesehen, in denen benutzerdefinierte Elementnamen ohne begleitendes Javascript verwendet wurden, aber es hat sich als überraschend gute Wahl für das Schreiben von klarem HTML erwiesen, das auch so aussieht, wie ich es möchte.

Völlig getrennte Elemente in Bezug auf das Design entwickeln im Laufe der Zeit auch eher Anforderungen, die nur mit JavaScript implementiert werden können, was Ihnen einen klaren Weg zur Implementierung derjenigen gibt, die weder Änderungen im HTML noch erfordern das CSS.

div.vsep sollte sich in Vertical-Separator

verwandeln

Klassen

Klassen sollten als Modifikatoren des vorhandenen Knotennamens und nicht als völlig neue Elementtypen funktionieren und oft ähnliche, aber unterschiedliche Auswirkungen auf verschiedene Elementtypen haben.

Ein gefährlicher Knopf ist ein Knopf. Gefahr

Attribute

Einige Möglichkeiten zum Ändern von Elementen sind keine einfachen Ein-/Ausschalter, für die Klassen nützlich sind, sondern verhalten sich eher wie Schlüssel-Wert-Paare.

In diesen Fällen haben sich benutzerdefinierte Attribute mit passenden Selektoren fast immer als die beste Option erwiesen, wenn ich sie verwendet habe. Im Gegensatz zu getrennten Klassen zeigen sie auf Syntaxebene an, welches Attribut und welcher Wert ist. Dadurch ist es für Redakteure einfacher, sie hervorzuheben, für das menschliche Auge ist es einfacher, sie schnell zu analysieren, und die Schnittstelle mit JavaScript ist einfacher.

Für diejenigen unter uns, die immer noch hoffen, dass die attr()-Funktion eines Tages nicht nur für Inhalte in CSS Einzug halten könnte, ist dies auch eine zusätzliche Ebene der Zukunftssicherheit.

Ausweise

IDs sind per Definition innerhalb des Dokuments eindeutig. Daher ist jede Regel, die auf eine bestimmte ID abzielt, begrenzt und erfordert möglicherweise eine Umgestaltung, wenn sich später herausstellt, dass es doch mehr als ein Element dieses Typs auf der Ebene geben sollte.

Daher sollten IDs sparsam und nur dann verwendet werden, wenn es keinen Sinn macht, jemals mehr als ein Element in einem Dokument zu haben.

Die Vorteile gegenüber Klassen sind sowohl in praktischer Hinsicht als auch in Bezug auf die Lesbarkeit eher gering, sodass ein Fehler auf der Seite der Klassen normalerweise die beste Idee ist, wenn keine klare 1-zu-1-Beziehung zwischen Element und Stil identifiziert werden kann.

Inline-CSS

Jede reale Anwendung wird irgendwann Elemente haben, die lediglich eine individuelle Optimierung erfordern, um sie in dem Kontext, in dem sie erscheinen, ästhetisch ansprechender zu gestalten.

In diesen Fällen ist das Stilattribut die richtige Wahl. Jeder Grund, warum die Verwendung als schlechte Praxis gilt, gilt für jede Art von Inline-Styling, einschließlich Utility-Klassen. Das Problem ist nicht das Attribut, sondern die Vermischung von Stil und Markup.

Der einzige Unterschied zwischen Stil und Klasse für Inlining-Stile besteht darin, dass einer den Zweck angibt, die Verwendung von einfachem CSS ermöglicht und größtenteils universell ist, während der andere dies nicht ist.

Einfach ausgedrückt hat width: 100px eine universell definierte Bedeutung, während .width-100 alles bedeuten könnte.

Utility-Klassen

In sehr seltenen Fällen werden elementspezifische Stile so komplex, dass ihre explizite Einbindung die Lesbarkeit beeinträchtigen würde oder sogar unmöglich ist (z. B. wenn Medienabfragen erforderlich sind).

In diesen Fällen sind Utility-Klassen im Grunde die einzige Option, auch wenn sie hässlich sind.

In einer idealen Welt könnten diese getrennt von bestimmten Mixin-Klassen behandelt werden, und ich habe sogar darüber nachgedacht, Präfixe zu verwenden, um sie leichter voneinander zu unterscheiden, habe aber letztendlich keinen guten Weg gefunden, diese nicht hässlich zu machen.

Mir gefällt die Idee, Utility-Klassen ein voranzustellen, um darzustellen, dass sie dem Element eine Art Funktionalität hinzufügen, im Gegensatz zu normalen Klassen, die angeben, um welchen Typ eines Elements es sich handelt.

Rote schwebende Schaltfläche

---

Und das war’s auch schon. Natürlich gleicht kein Projekt dem anderen, und manchmal müssen die Regeln ein wenig geändert werden, um praktisch zu bleiben, aber im Großen und Ganzen ist das mein Rahmen für die Entscheidung, wie etwas auf dem Bildschirm auf eine bestimmte Art und Weise aussehen soll.

Was denken Sie? Hassen Sie es? Halten Sie es für sinnvoll? Lass es mich in einem Kommentar wissen?