Tipps zur CSS-Struktur für Unternehmenswebsites (oder zu anderen Themen)

CSS und HTML sind einfach zu verstehen. Es erfordert jedoch jahrelange Übung, sich mit den besten Architekturansätzen vertraut zu machen, wenn Websites (und Apps) so erstellt werden, dass sie wiederverwendbar und in Zukunft wartbar sind und Entwickler zufrieden stellen.

Was ist hier unter Architektur zu verstehen? Es ist die Struktur des CSS-Codes. Die Art und Weise, wie Sie es in Dateien aufteilen, die Regeln hinter Klassennamen, die Tiefe der Selektoren, die Art und Weise, wie es kaskadiert, was vererbt wird, wie Sie Komponenten, Seiten, Elemente und Modifikatoren einrichten.

Das Anwenden von Best Practices auf alle diese Website-Komponenten mit Hunderten von Seiten, verschiedenen Arten von Inhalten, Bildschirmansichten und Randfällen sowie die Überlegung, mehr hinzuzufügen und vorhandene zu ändern, ist der schwierige Teil.

Mit Komponenten erstellen, nicht mit Seiten

Dies ist einer der wichtigsten zu berücksichtigenden Teile. Sie sollten nicht basierend auf der Seite stylen, auf der Sie sich befinden. Mach keine .homepage… {} Stile. Wenn Ihre Seite einen Abschnitt enthält, formatieren Sie den Abschnitt. Damit können Sie es auch auf anderen Seiten wiederverwenden. Wenn Sie eine Schaltfläche haben, formatieren Sie die Schaltfläche wie .button {} und verwenden Sie sie an anderer Stelle wieder. Es gilt für alle Ansichten.

Dies ist der häufigste Rat und der (bisher) leistungsstärkste Ansatz, den Sie verwenden können.

Wie gehen Sie nun mit seitenspezifischen Unterschieden um? Weil dies der häufigste Grund ist, pro Seite zu stylen? Nun, es gibt einige Ansätze:

Verwenden Sie Modifikatoren.

In „BEM“ steht das „M“ für Modifier. Dies ist der .block__child-Modifikator-Look. Auch wenn Sie kein BEM verwenden, gibt es trotzdem Modifikatoren. Wenn eine Komponente oder ein Abschnitt variiert, fügen Sie einen Modifikator hinzu.

Idealerweise sollte der Designer nachdenklich sein und Variationen auf ein Minimum beschränken, um den Code sauber zu halten, aber Sie sollten keine Angst haben, mehr hinzuzufügen. Variationen sollten idealerweise nur einige Eigenschaften überschreiben und mit demselben Markup funktionieren. Dies ist eine gute Möglichkeit, sich Komponenten in der HTML-Phase zu nähern. Fügen Sie die benötigten Tags hinzu und halten Sie sie auf der gesamten Website konsistent. Fügen Sie aufgrund einer Modifikatorklasse keine neuen hinzu.

Stil Kinderkomponenten.

Der andere Ansatz besteht darin, basierend auf dem Kontext zu stylen. Eine Schaltfläche ist immer eine Schaltfläche, sie hat ihre .button-Klasse und alles, aber Sie können sie trotzdem anpassen, wenn sie Teil einer anderen Komponente ist. Dies ist im Allgemeinen keine gute Idee, da es zu Inkonsistenzen führt, aber es ist auch ein ziemlich realistischer Anwendungsfall. Andernfalls würden Sie 20 Modifikatoren mit seltsamen Namen erhalten.

Kontextbezogene Stile sind, wenn Sie eine Komponente nur dann formatieren, wenn sie ein Kind einer anderen ist. Nehmen wir zum Beispiel eine Artikelkarte. Es hat standardmäßig seine Stile. Wenn es sich jedoch um einen farbenfrohen Abschnitt handelt, an dessen Seite sich Text befindet, muss die Karte einige andere Elemente enthalten (z. B. animierte Formen usw.).

In diesem Fall formatieren Sie mit dem Selektor .parent .card {}. Sie müssen nur einige Eigenschaften überschreiben, wie Sie es mit einem Modifikator tun würden. Wenn Sie dies tun, fügt die Karte selbst ihren Stilen keine größere Komplexität hinzu, verhält sich jedoch in diesem speziellen Randfall ordnungsgemäß.

Wenn Sie darüber nachdenken, können Sie auch sehen, wie es "pro Seite" angewendet werden kann. Wenn das Design einige seltsame Randfälle enthält und geringfügige Unterschiede zu den Standardkomponentenansichten (und der Art und Weise, wie sie alle miteinander interagieren) bestehen, können Sie genau das mit dem Selektor .homepage {} formatieren. Denken Sie daran, dies sparsam zu verwenden. Nach unserer Erfahrung überschreiten solche Stile selten einige Codezeilen.

Wichtiger Hinweis zum Hinzufügen: Kontextbezogene Stile sind im Allgemeinen KEINE gute Praxis. Idealerweise sollten Sie das nicht einmal brauchen. Meistens haben Sie Modifikatoren, die die Arbeit gut genug machen sollten. Obwohl es in einigen Builds realistisch ist, kann es zu teuer sein, zu tief in guten abstrahierten Code mit strengen Regeln einzutauchen.

Arbeiten Sie in Abschnitten

Die meisten Unternehmenswebsites (wie auch viele andere) unterteilen Inhalte in Abschnitte. Jeder Abschnitt ist eine eigene Komponente mit einer Modifikatorklasse, die die verschiedenen Eigenschaften definiert. Ein Vorschlag für die Struktur der Klassen wäre:

• section.section-container - Dies kann der "Komponentenname" sein, der die konsistenten Auffüllungen / Ränder enthält oder was auch immer benötigt wird.
• section.section-border-top - ist ein Modifikator. Dies verwendet kein BEM, aber Sie können es bei Bedarf in Abschnitt-Container-Rand „übersetzen“.
• section.section-welcome - wäre der Name des Abschnitts.

Auch hier ist die Namenskonvention irrelevant. Mit solchen Abschnitten erhalten Sie die Freiheit, die Stile an wiederverwendbare Komponenten in vom Design erstellten Randfällen anzupassen (sei es aufgrund von Inkonsistenzen, die befolgt werden müssen, oder nur komplizierteren Ansichten).

Datentrennung

Höchstwahrscheinlich würden Sie Sass oder einen anderen ähnlichen Präprozessor verwenden. In Bezug auf die Datentrennung gibt es viele Ansätze, aber der von uns verfolgte folgt der folgenden allgemeinen Struktur:

• Allgemein - Allgemein besteht normalerweise aus Setup-Code wie dem Funktionieren eines Rasters, Stilen für HTML-Tags, Zurücksetzen / Normalisieren, einigen CMS-spezifischen Stilen und dergleichen.
• Seiten - Die oben erläuterten Seitenstile. Idealerweise sollten Sie hier sehr wenig Code behalten.
• Komponenten - Der Kern des Builds - hier befinden sich die verschiedenen Komponenten. Ein Tipp ist, dass Sie "Elemente" oder "Sonstiges" haben können, die kleinere Teile von Komponenten in eine Datei anstatt in 80 Dateien passen. Größere sollten natürlich idealerweise in separaten Dateien gespeichert werden.
• Layout - Globale Stile, z. B. in der Kopf- und Fußzeile und dann in Seitenlayouts, Modifikatoren für Ihr Raster usw.
• Plugins - Alles, was extern von einem Plugin, einer Erweiterung oder was auch immer generiert wird. Es ist schön, sie zu trennen, da Sie sie dann in anderen Projekten wiederverwenden können.

Halten Sie die Selektoren sauber

Ein gutes Zeichen für sauberen Code ist, wie einfach er aussieht. Keine seltsamen Eigenschaften, alles hat seinen Zweck, es gibt geringe Einrückungen. Selektive Selektoren, die intelligent aussehen, machen Ihren Code nicht „cool“. Wenn Sie etwas wie #container> .row div [rel = ”Something”] durch .rel-Something ersetzen können (stellen Sie sich vor, dass dies ein aussagekräftiger Klassenname ist), sollten Sie das Markup nur ein wenig aktualisieren. Ziel ist es, alles einfacher zu halten.

Einkerbungen niedrig halten. Sie müssen selten mehr als drei Ebenen gehen. Sehen wir uns zum Beispiel eine .entry-Klasse an:

.eintrag {...}
.entry-title {...}

Beachten Sie, dass es nicht erforderlich ist, den .entry-Titel in .entry einzurücken. Wenn Sie später einen Modifikator in die Datei einfügen, können Sie .entry-modifier {} und .entry-modifier .entry-title {} verwenden.

Mit diesem Ansatz ist das Überschreiben von Stilen in Zukunft viel einfacher. Schauen wir uns ein weiteres häufiges Beispiel an: Sie haben das Markup nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Zum Stylen brauchen Sie nur noch:

.site-nav {} - Komponente 1

.list-menu {} - Komponente 2
.list-menu .list-item {}
.list-menu a {}

Wenn Sie mehr Komponenten enthalten haben, wie z. B. zusätzliche Dropdowns, können Sie diese direkt im .list-Menü verschachteln. Sie müssen nicht .site-nav .list-menu .list-item .dropdown {} (4 Ebenen tief) schreiben, wenn Sie zwei Ebenen von .list-menu .dropdown {} haben können.

Schreiben Sie weitere abstrakte Klassennamen für Modifikatoren

Dieser geht für Wartbarkeit. Ein häufiges Beispiel, das Sie in ähnlichen Beiträgen finden würden, wäre, keine Farbvariable auf $ red zu setzen, sondern sie auf $ primary oder $ second zu setzen.

Der Grund dafür ist, dass die Variable $ red blau ausgeben würde, wenn später eine Änderung erforderlich wäre. Es ist viel sinnvoller, dass Sie Ihre Primärfarbe ändern möchten, nicht Ihre rote Farbe, oder?

Gleiches gilt für andere Arten von Farben und Eigenschaften. Angenommen, Sie haben Zeilen, die Inhalte trennen (z. B. das <hr> -Tag). Sie nennen diesen .line-Bindestrich, weil er gestrichelt ist. Macht perfekt Sinn. Aber dann kommt eine Veränderung und sie muss gepunktet werden. Benennen Sie es in .line-gepunktet um? Dies ist kein Modifikator, dies ist die Komponente. Stattdessen können Sie es als .line-Separator bezeichnen. Und wenn Sie spezifisch sein möchten, können Sie einen Modifikator für .dotted oder .dashed hinzufügen. Diese Art der Benennung nimmt beim Erstellen einer Site häufig die meiste Zeit in Anspruch.

In Summe

Es gibt unzählige gute und schlechte Praktiken. Eine Möglichkeit, bessere Ergebnisse zu erzielen, besteht darin, Regeln zu definieren und diese zu befolgen. Es ist schwierig, solche Regeln zu entwickeln. Ein guter Vorschlag wäre daher, im Internet zu surfen und zu versuchen, alle möglichen Informationen zur Architektur zu sammeln, z. B. Namenskonventionen, bewährte Methoden, das Schreiben von wartbarem Code und vieles mehr.

Das Erstellen von gutem Code erfordert viel Zeit und Hunderttausende von Codezeilen. Fragen Sie sich dabei immer: "Würde diese Skala?", "Kann ich sie wiederverwenden?", "Habe ich zu viel überschrieben?", "Ist es sinnvoll, sie so zu benennen?". Je mehr Sie dies tun, desto optimaler werden Ihre Entscheidungen und desto besser wird Ihre Arbeitsgeschwindigkeit.

Eine Investition in gute Fundamentaldaten führt zu weniger Hin- und Herbewegungen bei Ihren Projekten, und zukünftige Änderungen, die vorgenommen werden müssen, sind viel einfacher umzusetzen.