Es gibt viele CSS-Methoden, und ich hasse sie alle. Manche mehr (Rückenwind & Co.) und manche weniger (BEM, OOCSS, etc.). Aber am Ende des Tages haben sie alle Mängel.
Natürlich nutzen die Leute diese Ansätze 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 anwenden könnte. Vielleicht könnte man es mit etwas mehr Arbeit in ein solches verwandeln, aber der Zweck dieses Beitrags besteht einfach 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. Daher finde ich es in manchen Fällen reizvoll, dass CSS inaktiv bleibt, bis Framework-spezifische Klassen verwendet werden , in den meisten Fällen halte ich es für ideal, wenn eine Schaltfläche nur und sieht aus wie ein Knopf ohne weitere Magie.
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, sodass Sie einen klaren Weg zur Implementierung haben, der weder Änderungen im HTML noch erfordert das CSS.
div.vsep sollte sich in ein vertikales Trennzeichen 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 Klassen mit Bindestrichen zeigen sie auf Syntaxebene an, welches Attribut und welcher Wert ist. Dies macht es für Redakteure einfacher, sie hervorzuheben, für das menschliche Auge eine schnellere Analyse und eine einfachere Schnittstelle mit JavaScript.
Für diejenigen von uns, die immer noch hoffen, dass die attr()-Funktion eines Tages nicht nur für Inhalte in CSS Einzug hält, 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. Daher ist ein Fehler auf der Seite der Klassen normalerweise die beste Idee, wenn keine klare 1-zu-1-Beziehung zwischen Element und Stil identifiziert werden kann.
Inline-CSS
Jede reale Anwendung wird irgendwann Elemente enthalten, 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 der richtige Weg. 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 zulässt 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 unterscheiden zu können, habe aber letztendlich keine gute Möglichkeit 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.
Und das war’s auch schon. Natürlich gleicht kein Projekt dem anderen, und manchmal müssen die Regeln ein wenig angepasst 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 ?
Das obige ist der detaillierte Inhalt vonWie ich CSS-Selektoren schreibe. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
