Das Thema der Skalierung von CSS wurde in einer kürzlichen ShopTalk Show mit Ben Frain viel diskutiert. Ben hat sich viele Gedanken zu dem Thema gemacht und sogar ein ganzes Buch darüber geschrieben, Enduring CSS, das sich um eine ganze ECSS-Methodik dreht.
Er sprach darüber, wie es im Wesentlichen zwei Lösungen für das Styling in großem Umfang gibt
- Totale Isolation
- Totale Abstraktion
Totale Isolation ist irgendeine Form des Schreibens von Stilen, die auf eine von Ihnen eingerichtete Grenze (wie eine Komponente) beschränkt sind, aus der diese Stile nicht nach außen oder innen durchdringen.
Totale Abstraktion ist irgendeine Form des Schreibens von Stilen, die global, aber so generisch und wiederverwendbar sind, dass sie keine unbeabsichtigten Nebenwirkungen haben.
Totale Isolation kann aus <style scoped> in einer .vue-Datei, CSS Modules, bei denen CSS-Klassen-Selektoren und HTML-Klassen-Attribute dynamisch generierter Kauderwelsch sind, oder einem CSS-in-JS-Projekt wie glamerous stammen. Selbst streng befolgte Namenskonventionen wie BEM können eine Form der totalen Isolation sein.
Totale Abstraktion kann aus einem Projekt wie Tachyons stammen, das Ihnen eine feste Menge an Klassennamen zum Stylen gibt (Tailwind ist eine konfigurierbare Version davon), oder ein programmatisches Werkzeug (wie Atomizer), das speziell benannte HTML-Klassenattribute in ein Stylesheet mit genau dem verwandelt, was es benötigt.
Es ist der Mittelweg, der Probleme hat. Es ist die Verwendung einer Namensmethodik, aber ohne sich streng daran zu halten. Es ist die Verwendung einiger Stile in Komponenten, aber auch ein globales Stylesheet, das zufällige andere Dinge tut. Oder es tragen viele Entwickler zu einem Styling-System bei, das keine strengen Regeln hat und globale und isolierte Stile mischt. Jedes Stylesheet das wächst und wächst und wächst. Es durch das Entfernen ungenutzter Stile zu bekämpfen, ist keine wirkliche Lösung (und hier ist der Grund).
Beachten Sie, dass das Web ein großer Ort ist und nicht alle Projekte eine Skalierungslösung benötigen. Eine riesige Codebasis mit Hunderten von Entwicklern, die jahrzehntelang gewartet werden muss, tut das absolut. Meine persönliche Website tut das nicht. Ich hatte meinen fairen Anteil an Styling-Problemen, aber ich war nie so gelähmt, dass ich etwas so Strenges wie Atomic CSS (et al.) implementieren musste, um Arbeit zu erledigen. Noch bei keinem Job, den ich bisher hatte. Ich sehe aber die Vorteile.
Stellen Sie sich die Größe von Twitter.com über ein Jahrzehnt vor! Nicolas hat einen tollen Thread, in dem er Twitters PWA mit Twitters Legacy-Desktop-Website vergleicht.
Das CSS der Legacy-Website ist das Ergebnis, wenn Hunderte von Leuten über viele Jahre hinweg direkt CSS schreiben. Spezifitätskriege, Redundanz, ein Kartenhaus, das nicht repariert werden kann. Das Ergebnis ist ein extrem ineffizientes und fehleranfälliges Styling, das sowohl Benutzer als auch Entwickler bestraft.
Ich liebe den Artikel und das Thema im Allgemeinen (es ist das, worüber ich in letzter Zeit am meisten in CSS nachgedacht habe). Aber
Ich habe diesen Mittelweg sehr genossen. Ich halte ihn für den besten!
Ich habe mich immer gefragt, warum es kein spezifisches CSS-Code-Wort gab, das die Kaskade stoppt... damit wir nicht über die kaskadierenden Stile schreiben müssen, die sich negativ auf das Element auswirken.
Ich habe angefangen, das erwähnte Enduring CSS-Buch zu lesen. Während vieles von dem, was der Autor sagt, gegen meine Neigungen geht (Verwendung von viel redundanten Code), sehe ich seine Begründung, die diesen Ansatz für große Projekte, die aktiv gewartet werden, angemessen erscheinen lässt. Es ist eine Art massives Hybrid/Cherry-Picking aus vielen verschiedenen Ansätzen. In gewisser Weise ist es DRY, in gewisser Weise nicht.
Ich habe viel Zeit gebraucht, um es zu verstehen, und endlich habe ich es geschafft.
Danke für das Teilen dieses Beitrags, macht weiter so.
Ich denke, wir müssen das Styling in einem mehrschichtigen Ansatz definieren.
global
Marke
App
Feature
Modul (zusammengesetzte Komponente)
Komponente
Die Frage ist dann, wie jede Schicht auf die darunterliegende Schicht einwirkt (die Kaskade).
Es wäre schön, einen einfachen Mechanismus zur Definition des Geltungsbereichs von Variablen über diese Schichten hinweg zu haben und diese innerhalb eines bestimmten Kontexts überschreiben zu können.
Ein weiteres Problem ist, wie man seine Komponenten, Module und Features von dort entkoppelt, wo sie implementiert werden. Wenn Ihre Komponente Styling-Regeln dafür hat, wie sie angezeigt werden soll, wenn sie in einer Seitenleiste präsentiert wird, ist sie nicht unbedingt so unabhängig, wie sie sein könnte. Ich denke, es ist sinnvoller, diese Styling-Anpassung innerhalb des übergeordneten Moduls/Features vorzunehmen, da das übergeordnete Element seine Kinder von Natur aus einschließt/kennt. Das Problem dabei ist, dass man, wenn sich die Stil-Verträge der Kindkomponente ändern, diese Anpassungen in den übergeordneten Elementen nachverfolgen muss.
Die breite Herausforderung besteht darin, dass wir, wenn wir CSS versuchen, in objektorientiertere Modelle zu integrieren, Abstraktionen schaffen, die schwierig zu debuggen und zu warten oder einfach nur unintuitiv sind. Es mag elegant erscheinen, eine Reihe von Mixins zu schreiben, die repetitive Klassen generieren oder Namespaces automatisch definieren oder eine beliebige Anzahl anderer Dinge tun können, aber wenn man diesen Code an Entwickler weitergeben muss, kann es zu Problemen kommen.
Ich schaue mir einige Lösungen an und denke: "Das ist großartig, das könnte ich definitiv gebrauchen", und dann denke ich: "Wie werden die 50 Offshore-Entwickler, die Praktikanten und die neuen Junior-Entwickler und der C-Entwickler, der einen Karrierewechsel ins UI macht, alle mit begrenzten CSS-Kenntnissen das verstehen?" Irgendwann muss man Eleganz und Code-Wiederverwendung gegen Lesbarkeit und Intuitivität abwägen. Nicht, dass wir nicht versuchen sollten, das Wissen aller zu verbessern, aber manchmal können wir in Abstraktionshölle geraten und alle verlangsamen, weil die Rockstars an der Spitze es für eine großartige Idee halten.
Am Ende wäre es schön, eine Vielzahl von Werkzeugen und Techniken zu finden, die für verschiedene Bereiche eines Produkts und des Produktlebenszyklus gelten. Utility-Klassen halte ich für großartig für schnelle Prototypen und Fehlersuche, aber ich würde sie nicht für die Produktion verwenden wollen. Ich habe es geliebt, CSS Modules zu verwenden, aber sie sind sehr langsam zu kompilieren und es gibt einige Herausforderungen, sie außerhalb einer SPA/React-Umgebung zu nutzen. SASS ist großartig und ich liebe die Struktur und Organisation, die es Ihrem CSS bringen kann, aber es kann ziemlich schnell außer Kontrolle geraten und zu einem komplizierten Durcheinander werden. BEM stößt auf dasselbe Problem wie immer – Dinge zu benennen ist schwierig. CSS-in-JS-Stile können nicht in Nicht-SPA-Projekten geteilt werden ... usw.
ICH HABE EINE GROSSARTIGE IDEE! Lasst uns einfaches altes CSS verwenden! (Pause für den Effekt... nur *Grillen* sind zu hören.)
N-nein, ich meine es *ernst*, Leute! Wir suchen immer nach dem *grüneren Gras*, und so suchen viele von uns (ich eingeschlossen... leicht zu beweisen durch meinen fast fanatischen Glauben an das *nicht mehr CSS, aber noch nicht ganz BOOTSTRAP*, W3CSS) nach – und *finden* – das nächste Beste. Und wenn man einen Moment darüber nachdenkt, wird man erkennen, dass bei all den xSSes (Excess-Ess-es, Wortspiel ursprünglich nicht beabsichtigt, lol), und diesemSS, und USS, MESS, GPSS, und wahrscheinlich sogar LMNOPSS auf all den .js Pre-, Post- und, ich glaube, sogar Post-Partum-Prozessoren, nun ja... verdammt! Bei *so vielen* Geschmacksrichtungen werden wir natürlich alle irgendwann den perfekten Fleck "grüneres Gras" finden!
Oh, aber dann müssen wir mehr lernen (und hier dachten Sie, CSS wird zu groß), wie Mixins, Moxins, Boxins und Toxins. Füge etwas Wiederholung der CSS-Formate hinzu, und... ugh! Ja, ich weiß: aber TL;DR mich noch nicht. Ich bin fast fertig. Aber der Punkt *war*, Ihnen ein wenig Erschöpfung zu verschaffen. Ich meine, Sie müssen zugeben: Es gibt *eine Menge* CSS/JS-Alternativen da draußen.
Und die meisten, wenn nicht *alle* von ihnen helfen Ihnen nur dabei, das zu tun, was Sie *bereits* mit dem ursprünglichen CSS tun konnten, aber etwas schneller oder mit weniger Code, was ebenfalls eins und dasselbe ist.
Es gibt *ständige Updates und Überarbeitungen* von CSS. Tatsächlich kehre ich, selbst mit meiner Liebe zu W3CSS, sozusagen zu meinen Wurzeln zurück... UNSEREN WURZELN, eigentlich. Zurück zum OGCSS? Okay, okay... zu viel. Zurück zum ursprünglichen CSS. Und ehrlich gesagt? Ich mag wirklich, was ich sehe. Probieren Sie es noch einmal aus. Sie werden vielleicht, wie ich, angenehm überrascht sein.
Passen Sie auf sich auf und
Viel Spaß beim Codieren!
Michael C