Die Debatte um „Brauchen wir CSS überhaupt noch?“

Das ist in letzter Zeit zu einem ziemlichen heißen Thema geworden. Es wurde auf mehreren Konferenzen und Meetups, an denen ich persönlich teilgenommen habe, besprochen. Ich habe Folien dazu gesehen. Ich kenne Leute, die buchstäblich kein CSS in der Produktion verwenden. Ziemlich verrückt, oder?

Ich dachte, wir könnten hier ein kleines Lagerfeuer machen und so rational wie möglich darüber sprechen und alle relevanten Punkte behandeln.

Wir müssen offensichtlich immer noch Dinge stylen

Niemand sagt, dass wir keine Stile brauchen. Wir müssen immer noch Dinge stylen, worüber gesprochen wird, ist, wie und wo wir das tun. Ich war gerade in einer Diskussionsrunde bei BrooklynJS und Jed Schmidt sagte

Das Schlimmste an CSS sind die „Cascading“ und die „Sheets“

Was hat jemand gegen CSS?

Dies sind die Hauptargumente gegen CSS

• Alles ist global. Selektoren werden mit allem im DOM abgeglichen. Man braucht Benennungsstrategien, um dem entgegenzuwirken und die Dinge effizient zu halten (die schwer durchzusetzen und leicht zu brechen sind).
• CSS wächst mit der Zeit. Kluge Leute in großartigen Teams geben zu, dass sie Angst vor ihrem eigenen CSS haben. Man kann Dinge nicht einfach löschen, da es so schwer ist zu wissen, ob es absolut sicher ist, dies zu tun. Also tun sie es nicht, sie fügen nur hinzu. Ich habe ein Diagramm gesehen, das die Größe von Produktions-CSS über fünf Jahre hinweg zeigt, wie die Größe stetig wächst, trotz des Fokus des Unternehmens auf Performance.
• Man kann mit Stilen in einer Programmiersprache dynamischer sein. Das Argument lautet ungefähr so: „Wir pimpen CSS sowieso schon mit Präprozessoren, also können wir es auch noch auf die nächste Stufe heben.“ Man könnte zum Beispiel (wenn man es wirklich kontrovers machen wollte) Stile auf einer User-Agent-Zeichenfolge oder der aktuellen Breite eines Moduls basieren.

Was ist dann die Alternative zu CSS?

Die Alternative sind Inline-Stile. Also statt

Wir reden von

Ich habe noch niemanden gehört, der argumentiert, dass man diese Stile direkt auf den von Ihnen erstellten HTML-Code anwenden sollte. Die Idee ist, dass man Stile über JavaScript auf Elemente anwendet.

React treibt viele dieser Gedanken voran

React ist eine JavaScript-Bibliothek, die bei View-Anliegen auf Websites hilft. Sie wird hauptsächlich von Facebook entwickelt, ist extrem beliebt und gewinnt an Dynamik. Sie hatte eine eigene Konferenz und entwickelt sich sogar zu einem Framework zum Erstellen nativer Apps.

Eines seiner Kernkonzepte ist das „Virtual DOM“. Man erstellt den HTML-Code, den man verwenden möchte, direkt in JavaScript. Zuerst mag das ziemlich seltsam erscheinen, aber diese Kopplung zwischen HTML und JavaScript ist immer vorhanden, und es gefällt den Leuten, sie von Anfang an zusammenzuschreiben. Ich zitierte kürzlich Keith J Grant, und ich werde es wieder tun

Diese Kopplung ist real und unvermeidlich. Wir müssen Event-Listener an Elemente auf der Seite binden. Wir müssen Elemente auf der Seite von unserem JavaScript aus aktualisieren. Unser Code muss bidirektional und in Echtzeit mit den Elementen des DOM interagieren.

... das Mantra von React ist es, aufzuhören so zu tun, als wären das DOM und das JavaScript, das es steuert, getrennte Anliegen.

React bietet die Möglichkeit, Inline-Stile direkt zu verwalten. Sie nennen sie, was sie sind: Inline-Stile. Hier ist ein grundlegendes Beispiel

Siehe den Pen Inline Styles with React von Chris Coyier (@chriscoyier) auf CodePen.

Die virtuelle DOM-Sache, die React macht, ist auch wegen ihrer Geschwindigkeit wichtig. DOM-Manipulation wird in JavaScript im Allgemeinen als langsam angesehen, und daher wäre das Verwalten von Stilen durch DOM-Manipulation auch langsam. Aber React hat den Zauberstaub, der die Manipulation schnell macht, sodass sich die Leute bei der Arbeit mit React keine Sorgen um die Langsamkeitsprobleme machen.

Hier ist ein weiteres Beispiel von Chris Nager.

Die Stilerstellung ist immer noch abstrahiert

CSS ist die Abstraktion des Stils von allem anderen. Es sind buchstäblich Dateien, die Sie öffnen und bearbeiten, um Stile zu verwalten. Sie werden dies wahrscheinlich nicht aufgeben, wenn Sie zu einem JavaScript-basierten Inline-Stil-Setup wechseln. Sie hätten dann wahrscheinlich style.js statt style.css. Sie würden immer noch Schlüssel/Wert-Paare schreiben und Dateien in einem Build-Prozess zusammenfügen.

Es wird anders sein, aber die Abstraktion der Erstellung ist immer noch vorhanden.

Was bringt Ihnen die Inline-Stillegung?

Kaskadenlos

Die beängstigende „globale“ Natur von CSS wird neutralisiert. Die Kaskade, abgeschwächt. Ich glaube nicht, dass man sagen kann, dass die Kaskade vollständig verschwunden ist, denn einige Stile werden vererbt, so dass Stile immer noch an Kindelemente weitergegeben werden können, und das ist eine Definition von Kaskade. Aber die modulare Natur dieser Art der Entwicklung führt wahrscheinlich zu weniger überlappenden Stilproblemen. Ein Modul hier ist so gestylt, ein Modul dort ist so gestylt – wahrscheinlich keine Konflikte in Sicht.

Alles JavaScript

Ein Gefühl, das ich bekomme, ist, dass einige Leute einfach gerne und lieber komplett in JavaScript arbeiten. Man könnte sicherlich einen Teil des Erfolgs von Node.js diesem Umstand zuschreiben.

Dynamische Stile

„Zustand“ ist weitgehend eine JavaScript-Angelegenheit. Wenn Sie möchten/brauchen, dass sich der Stil basierend auf dynamischen Bedingungen (Zuständen) auf Ihrer Website ändert, kann es sinnvoll sein, das Styling, das mit der Zustandsänderung zusammenhängt, zusammen mit allem anderen zu handhaben.

In einem kürzlichen Vortrag auf der CSS Conf (Folien) verwendete Colin Megill das Beispiel des neuen Tweet-Eingabebereichs von Twitter als dynamischen Ort, der den Zustand anderer Elemente ändert.

Wer macht das eigentlich?

Ich hörte Colin Megill sagen, dass sie buchstäblich null CSS bei „großen Dingen“ verwenden und keine Leistungsprobleme feststellen. Ich werde dies mit URLs aktualisieren, wenn ich sie erhalte. Ich höre, ein großes Projekt wird innerhalb eines Monats live gehen.

Ich weiß, Jed Schmidt arbeitet an der mobilen Version von UNIQLO, und man kann die Inline-Styles dort sehen

Update von Jed: Diese Version der Website ist komplett Sass, und die Inline-Styles, die Sie dort sehen, stammen von JavaScript-Animationen.

Christopher Chedeau hat darüber gesprochen und ist buchstäblich ein Facebook-Ingenieur, also vielleicht auch Facebook ein bisschen?

Kann dieses Konzept mit, Sie wissen schon, CSS kombiniert werden?

Selbst wenn Sie sich auf das Konzept der Inline-Stile eingelassen haben, kann es dann harmonisch mit etwas (muss ich es sagen) normalem CSS koexistieren? Ist das Seitenlayout als Inline-Stil angemessen? Ergibt eine globale Typografie nicht immer noch Sinn? Ich bin mir nicht sicher, ob wir in dieser Welt schon weit genug sind, um eine Best Practice zu sehen.

Im obigen Beispiel m.uniqlo.com wird auch eine 57k CSS-Datei ausgeliefert, und Sie können auch im DOM Hinweise auf klassenbasierte Zustände (z. B. „is-open“) sehen.

Viele Leute mögen das wirklich nicht

Überraschung! Es gibt mehr Argumente dagegen als dafür. Als ich Meinungen dazu sammelte, sagte ich Lea Verou: „Manche Leute mögen diese Idee wirklich!“ Woraufhin sie mir sagte

Man kann Menschen finden, die Exkremente essen, das bedeutet nicht, dass es eine gute Idee ist.

Lassen Sie uns andere Argumente durchgehen

Styling ist das, wofür CSS da ist

Dies ist der „religiöse“ Blickwinkel, der uns wahrscheinlich nicht sehr weit bringen wird.

Die Trennung der Belange ist CSS inhärent

Die Trennung der Belange ist ein sehr nützliches Konzept beim Erstellen komplexer Websites. Beim Schreiben von CSS erhalten Sie automatisch eine Trennung der Belange: Es ist eine Datei, die nur für das Styling bestimmt ist.

Inline-Stile stehen an der Spitze des Spezifitäts-Spektrums

Eine geringe Spezifität in CSS bedeutet, dass Sie, wenn Sie auf Spezifität angewiesen sind, um einen Styling-Krieg zu gewinnen, diese als Werkzeug zur Verfügung haben. Wenn Sie bereits an der Spitze stehen, haben Sie diesen Spielraum nicht.

Die !important-Deklaration kann immer noch einen spezifischen Eigenschafts-/Wert-Styling-Krieg über einen Inline-Stil gewinnen, aber das ist ein etwas anderes Konzept und ein noch widerwärtigerer Kampf.

Manche einfache Zustände sind in CSS viel einfacher

Wie macht man :hover/:focus/:active in Inline-Styles? Gar nicht. Man simuliert es. Und was ist mit Media Queries?

Klassen hinzufügen/entfernen ist bereits ein perfektes Werkzeug für Zustandsänderungen

JavaScript ist wirklich gut darin, Klassen zu Elementen hinzuzufügen/zu entfernen/zu ändern. Und Klassen sind eine perfekte Möglichkeit, den Zustand in CSS zu handhaben.

.is-open {
  display: block;
}

Außerdem können Sie den Zustand von Elternelementen ändern (indem Sie eine Klasse ändern), um den Zustand vieler Elemente innerhalb zu beeinflussen

.tweet-too-long {
  .tweet-button {
    opacity: 0.5;
  }
  .warning-message {
    display: inline-block;
  }
}

Browser sind nicht dafür gemacht, mit Styling auf diese Weise umzugehen

Inline-Stile sind zum Beispiel buchstäblich Daten, die in einem Attribut direkt am DOM-Element gespeichert werden. Das DOM-Gewicht ist eine Sache (es kann Browser langsam machen oder zum Absturz bringen). Diese Styling-Informationen werden jedoch nicht nur im Stilattribut gespeichert, sondern auch im DOM in den Stileigenschaften des Elements dargestellt. Ist das dasselbe, oder ist dies eine Art doppelt gewichtetes Styling?

Gibt es Geschwindigkeitsunterschiede zwischen…

var thing = document.getElementById("thing");
thing.style.width = "100px";
thing.style.height = "100px";
thing.style.backgroundColor = "red";

var thing2 = document.getElementById("thing-2");
thing2.setAttribute("style", "width: 100px; height: 100px; background-color: red;");

Wurde das herausgefunden, um zu entdecken, was am besten browserübergreifend ist? Wenn sich diese Dinge durchsetzen, müssen sich Browser weiterentwickeln, um Dinge auf andere Weise zu handhaben?

Der Browser hat dieses ganze Konzept des CSSOM. Können wir das irgendwie intelligenter durch JavaScript statt Inline-Stile nutzen?

CSS ist erfolgreich wegen seiner Einfachheit

CSS ist ziemlich einfach zu erlernen. Viele Leute kennen es. Man kann dafür Leute einstellen. Es ist portabel.

Einige dieser „dynamischen“ Styling-Probleme können mit normalem CSS gelöst werden

• Es gibt Demos, die das Messen von Breiten und das Subtrahieren fester Werte davon beinhalten. CSS kann das mit calc().
• Es gibt Demos, die das Festlegen von font-size oder line-height beinhalten, das von der Browserbreite oder -höhe abhängt. CSS kann das mit Viewport-Einheiten. JavaScript für diese Art von Dingen zu verwenden, ist Überinstrumentierung.
• Es gibt Demos, die Farben dynamisch auf vielen verschiedenen Elementen ändern. CSS wird das mit nativen Variablen tun können.

Wir haben das 1996 versucht und es war damals eine schlechte Idee

Verschwinde von meinem Rasen.

CSS ist cachefähig

Das Netzwerk ist immer noch der Engpass. CSS-Dateien können zwischengespeichert werden, sodass das Netzwerk überhaupt nicht ins Spiel kommt und das ist rasend schnell.

Sie können React immer noch verwenden

React ist ziemlich großartig. Hier ist ein Artikel von David Khourshid über das Styling von React-Komponenten in Sass. Mark Dalgleish mag die globale Natur von CSS nicht und hat funktionierende Konzepte zur Lokalisierung von Selektoren. Glen Maddern erläutert dies in Interoperable CSS.

Interessiert sich denn niemand mehr für progressive Verbesserung?

Dies ist eine breitere Diskussion und fällt hier vielleicht nicht in den Rahmen. Da Websites (einschließlich React-basierter Websites, die Inline-Styles verwenden) vollständig serverseitig gerendert werden können, bedeutet dies, dass sie unter Berücksichtigung der progressiven Verbesserung erstellt werden können. Obwohl "kann sein" und "was es tatsächlich fördert" unterschiedliche Dinge sind.