Die Entstehung von Atomic CSS: Ein Interview mit Thierry Koblentz

Ich habe Thierry Koblentz, den Erfinder von Atomic CSS, interviewt, um die Geschichte und den Hintergrund zu verstehen, die zur Entstehung des beliebten CSS-Frameworks geführt haben. Thierry, der jetzt im Ruhestand ist, verfügt über umfassende Erfahrung im Schreiben von CSS in großem Maßstab und hat zuvor als Front-End-Entwickler bei Yahoo! gearbeitet.

Lassen Sie uns in die frühen 2000er Jahre zurückblicken: Wie sind Sie in die Webentwicklung eingestiegen, insbesondere in das Schreiben von CSS, um Ihren Lebensunterhalt zu verdienen?

Thierry Koblentz: Ich habe mir HTML, CSS und JavaScript selbst als Hobby beigebracht, nachdem ich 1997 in die USA gezogen war.

Damals benutzte ich FrontPage und verließ mich stark auf Newsgroups für Anleitungen. Ich wurde schnell zu einem Stammgast in den Macromedia NewsGroups und bei CSS-Discuss. Schon früh vertrat ich die Philosophie des Web Standards Project und interessierte mich sehr für Barrierefreiheit. Jahrelang war Front-End für mich nichts weiter als ein Hobby (mein eigentlicher Beruf war Antiquitätenhändler). Ich erstellte gelegentlich eine Website, aber ich schrieb und veröffentlichte hauptsächlich (viele) Artikel und teilte Techniken, die ich gelernt oder „entdeckt“ hatte.

Das zahlte sich 2007 in Form eines Anrufs von Yahoo! aus, die fragten, ob ich beim Reparieren und Erstellen von Stylesheets für den Website-Builder-Template von Yahoo! Site Solutions (YSS) helfen könnte. Die Stellenbeschreibung: kein HTML, kein JavaScript, nur CSS! Und das eine Menge!

Wie sah Ihr Joballtag bei Yahoo! aus?

TK: Meine Rolle bei Yahoo! hat sich im Laufe der Jahre stark verändert.

Mein erster Job war es, Stylesheets (à la CSS Zen Garden) für das YSS-Template zu erstellen. Anschließend habe ich das Markup und die Styles der YSS-Website neu geschrieben, kurz bevor YSS nach Bangalore (Indien) „verschifft“ wurde – wohin ich mit meinen Kollegen zur „Wissensvermittlung“ geschickt wurde.

Nebenbei bemerkt: Die Herausforderung, Stylesheets auszutauschen, um verschiedene Designs für YSS zu erstellen, zwang uns, eine *leichtgewichtige* (nicht-JS) Lösung zum Ändern der Videogrößen im laufenden Betrieb zu finden; und so kam ich zu „Creating Intrinsic Ratios for Video.“

Nach YSS hatte ich die Möglichkeit, nur an Projekten zu arbeiten, die *von Grund auf* neu gestartet wurden (Neufassungen oder anderweitig), und ich wurde immer stärker in Yahoo! FE involviert. Ich habe viele interne Dokumente bearbeitet und erstellt (z. B. CSS Coding Standards); am Einstellungsprozess teilgenommen (wie jeder andere in meinem Team); Code-Review-Sitzungen geleitet; CSS-Kurse und Workshops gegeben; auf FED London gesprochen; anderen Teams mit HTML/CSS/Barrierefreiheit geholfen; war an Entscheidungen bezüglich der Technologieeinführung beteiligt (z. B. Bootstrap oder kein Bootstrap); Bibliotheken erstellt; interne Papiere rezensiert; Vorschläge geschrieben usw.

Eine weitere Randbemerkung: Während meiner acht Jahre bei Yahoo! habe ich vielleicht weniger als 100 Zeilen JavaScript geschrieben. Und wenn ich meinen Job nicht gekündigt oder verloren hätte, dann dank Lingyan Zhu und Renato Iwashima; sie haben mir unermüdlich geholfen, wenn es darum ging, meine Umgebung einzurichten oder mit der Kommandozeile umzugehen (denn bis heute bin ich darin schrecklich).

Welche gängigen Praktiken beim Schreiben von CSS waren zu dieser Zeit verbreitet?

TK: In den Anfängen gab es weder Bibliotheken noch veröffentlichte Methodologien; es war der Wilde Westen, alles war erlaubt: „nicht-semantische“ Klassen, IDs, CSS-Hacks, bedingte Kommentare, Frames, CSS-Ausdrücke, „JS-Sniffing“, Design hauptsächlich für Internet Explorer usw. Auf meiner alten Website hatte ich sogar diesen Kommentar

<!--MSIE5 Mac needs this comment -->

Alles war erlaubt und alles wurde missbraucht, da wir nur eine begrenzte Auswahl an Werkzeugen hatten, aber viel leisten mussten.

Aber die Dinge hatten sich dramatisch verändert, als ich zu Yahoo! kam. Entwickler aus Großbritannien waren starke Befürworter von Webstandards und ich schreibe ihnen zu, dass sie maßgeblich beeinflusst haben, wie HTML und CSS bei Yahoo! geschrieben wurden. Semantisches Markup war Realität und CSS wurde nach dem Prinzip der Trennung der Zuständigkeiten (SoC) bis ins kleinste Detail geschrieben (was mir manchmal zu übertrieben war).

YUI hatte CSS-Komponenten, aber noch kein CSS-Framework. Es gab eine interne CSS-Bibliothek (genannt Lego), aber ich musste sie nie benutzen. Methodologien und Bibliotheken wie OOCSS, SMACSS, ECSS (Shoutout an Ben), BEM, Bootstrap, Pure und andere folgten kurz darauf.

Was führte zur Idee von Atomic CSS?

TK: Bevor YSS nach Indien verlegt wurde, fragte mein Manager, Michael Montesano, ob es einen Weg gäbe, damit das neue Team in Bangalore das Stylesheet nicht bearbeiten müsste und somit *Risiken von Brüchen reduziert werden*. Ich schätze, die Erfahrung mit dem YSS-Template (zahlende Kunden beschwerten sich über kaputte Seiten) machte ihn ziemlich paranoid, wenn es um Änderungen an einem Stylesheet ging.

Also erstellte ich ein „Utility-Sheet“ im Geiste meiner ez-css-Bibliothek – ein Sheet, das es Entwicklern ermöglichen sollte, ihr Styling zu erreichen, *ohne dass sie Regeln in einem Stylesheet bearbeiten oder hinzufügen müssen*.

Ein paar Jahre später fragte mich Michael, damals Direktor für Engineering, ob ich die Homepage von Yahoo! mit ausschließlich Utility-Klassen neu gestalten könnte, wohl wissend, dass wir wieder einmal nicht für die Wartung der Website verantwortlich wären. Wir sprachen darüber, Utility-Klassen *über* semantische Klassen zu stellen, etwas, das es meines Erachtens zu dieser Zeit noch nicht in diesem Umfang gab. Es war ein sehr kühner Schritt.

Diese groß angelegte Übung entwickelte sich schnell zu einem Proof of Concept, der die vielen Vorteile des Stylings *über Markup* zeigte. Es erfüllte so viele Anforderungen, dass beschlossen wurde, dieses „statische“ Stylesheet (Stencil genannt) für die Neugestaltung des Yahoo! My Home Page-Produkts zu verwenden.

Was waren die leitenden Prinzipien bei der Entwicklung von Atomic CSS (ACSS) und wer waren die beteiligten Personen?

TK: Unsere statische Stencil-Bibliothek war ein großartiges Werkzeug, um einen Designstil aufzuerlegen/durchzusetzen – von dem wir dachten, dass Yahoo! ihn für alle seine Eigenschaften übernehmen würde. Wir erkannten schnell, dass dies nicht geschehen würde. Jedes Yahoo!-Designteam hatte seine eigene Vorstellung von der perfekten Schriftgröße, dem perfekten Abstand usw., und wir erhielten ständig Anfragen, sehr spezifische Stile zur Bibliothek hinzuzufügen.

Diese Situation war nicht aufrechterhaltbar, also beschlossen wir, ein Tool zu entwickeln, mit dem Entwickler *ihre eigenen Stile im Handumdrehen erstellen* können, während die atomare Natur der Autorenschaftsmethode beachtet wird. Und so entstand Atomizer. Wir hörten auf, uns Gedanken über das Hinzufügen von Stilen – CSS-Deklarationen – zu machen, und konzentrierten uns stattdessen darauf, ein reiches Vokabular zu schaffen, um Entwicklern eine breite Palette von Stylingmöglichkeiten zu bieten, darunter unter anderem Media Queries, Nachfahrenselektoren und Pseudoklassen.

Mit ACSS konnten Entwickler frei verwenden, was sie wollten; daher konnten Teams unterschiedliche Designstile und Stilrichtlinien verwenden, während sie exakt dieselbe Bibliothek nutzten. Und es gab einige sofortige Vorteile, die neu für die Art und Weise waren, wie Entwickler Stile zu schreiben gewohnt waren. Sie mussten sich nicht mehr darum kümmern, die Seite mit ihrem Styling zu beschädigen, oder sich um das Schreiben von Selektoren zum Stylen ihrer Komponenten kümmern.

ACSS wurde in erster Linie entwickelt, um die Probleme von Yahoo! zu lösen und in der Yahoo!-Umgebung zu funktionieren.

Die beteiligten Personen bei Atomic CSS waren Renato Iwashima, Steve Carlson und ich. Renato und Steve entwickelten Atomizer.

Welche Missverständnisse haben Menschen über CSS, wenn sie CSS nicht für große Unternehmen schreiben?

TK: Als ich 2007 zu Yahoo! kam, lernte ich schnell, wie riesig eine Codebasis sein kann. Es gab Teams, die an vielen Orten/Zeitzonen arbeiteten; eine Vielzahl von Produkten; Hunderte von gemeinsamen Komponenten; Code von Drittanbietern; A/B-Teststrategien; Skalierbarkeit als Anforderung; unterschiedliche Skriptrichtungen; Lokalisierung und Internationalisierung; verschiedene Release-Zyklen; komplexe Deployment-Mechanismen; Tonnen von Metriken; Altlasten aller Art; strenge Coding-Standards; Build-Prozesse; Politik; und noch mehr Politik; usw.

Das meiste davon war für mich völlig neu und ich musste lernen, ob und wie sich das auf die Art und Weise auswirken könnte, wie ich CSS schrieb. Ich begann, alle meine Überzeugungen zu überdenken und herauszufordern, da viele Techniken oder Methoden, die für mich gängige Praxis waren, für komplexe Anwendungen ungeeignet oder zumindest kontraproduktiv zu sein schienen.

Ein „Realitätscheck“ betrifft die Stil-Abstraktion. Wir alle haben Artikel gelesen, die besagen, dass die Zuordnung einer M-10-Klasse zu margin: 10px keine gute Idee ist, da dies bedeutet, *sowohl das HTML als auch das CSS zu bearbeiten*, um das Styling zu ändern. Leider passiert das in großen/komplexen Projekten

• Designer: Ich möchte einen Abstand von 15px haben
• Entwickler: Okay, das sind M-3x (5px-Schritt)
• Designer: Sicher, was auch immer!
• Entwickler: Erledigt!
• Designer: Eigentlich sind 15px ein bisschen zu viel, können Sie es auf 12px ändern?
• Entwickler: Nein, das haben wir nicht, es sind entweder 10px oder 15px.
• Designer: Tut mir leid, das funktioniert für mich nicht. Können wir M-3x auf 12px ändern?
• Entwickler: Nein! Das können wir nicht tun, weil andere Teams erwarten, dass M-3x 15px sind.
• Designer: Okay, versuchen Sie, einen Weg zu finden, denn wir wollen, dass der Rand 12px beträgt. 15px ist zu viel und 10px zu wenig.
• Entwickler: (Verdammt das!)

Um ein solches Problem vorherzusagen, muss man die Absicht des Designers hinter seiner Anfrage verstehen: Wird der Stil wegen seiner Abstraktion gewählt, z. B. primäre Farbe, oder wegen seines spezifischen Werts, z. B. ein Rand von 15px in unserem Fall M-3x? Wenn es eine Stilrichtlinie gibt, um Designprinzipien durchzusetzen, dann sind Klassen wie M-3x möglicherweise in Ordnung, aber wenn Designteams *jeden beliebigen Stil* anfordern können, dann ist es viel sicherer, sich von Namenskonventionen fernzuhalten, die zu mehrdeutigem Styling führen. Meiner Erfahrung nach führt alles Mehrdeutige früher oder später zu Brüchen.

Sich auf die Struktur eines Dokuments oder einer Komponente für ihr Styling zu verlassen – über Kombinatoren wie > oder + – klingt nach einem sauberen Ansatz für die Erstellung eines Stylesheets, ignoriert aber die Tatsache, dass man in einer komplexen Umgebung keine spezifische Markup-Struktur oder Konstruktion als unveränderlich annehmen kann.

Sie denken, z-index ist kompliziert? Denken Sie noch einmal darüber nach, wenn Sie nicht einmal den Geltungsbereich des Stacks besitzen, in dem sich Ihre Komponente befindet. Das ist eines der komplexesten Probleme, die in einem großen Projekt angegangen werden müssen, bei dem Teams für verschiedene Teile der Seite verantwortlich sind. Ich habe einmal einen Vorschlag dazu geschrieben.

Qualifizierende Selektoren – wie input.required vs. .input.required – mögen gut und semantisch aussehen, erzeugen aber eine unnötige Spezifitätsebene – wie 0.1.1 vs. 0.2.0 – und verhindern Markup-Änderungen; zwei Dinge, die leicht vermieden werden können, indem man sicherstellt, dass man seinen Selektor nicht qualifiziert.

Sich auf den universellen Selektor, *, zum Stylen des globalen Geltungsbereichs verlassen? In einem sehr großen Projekt könnte dies bedeuten, dass Sie die Komponente eines anderen stylen. Treffen Sie keine Styling-Entscheidungen für andere, es sei denn, Sie kennen deren Anforderungen.

Ich bin sicher, Sie haben gelesen, dass IDs schlecht sind und Spezifität böse ist, aber. tatsächlich. Hohe Spezifität ist nicht so sehr ein Problem wie die Anzahl der Spezifitätsebenen, die Ihre Regeln erzeugen. Es ist viel einfacher, in einer Umgebung zu stylen, in der nur zwei oder drei Ebenen existieren – wie 1.1.0, 0.1.0, 0.2.0 – anstatt in einer Umgebung, in der die Spezifität eher niedrig ist, aber einem „Jedem das Seine“-Ansatz folgt – wie 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2 usw. –, was in großen Projekten oft als Abwehrmechanismus dient, um Stile zu „sandkasten“.

Das blinde Befolgen von Ratschlägen aus der CSS-Community kann zu unangenehmen Überraschungen führen. Springen Sie niemals auf neue Techniken auf, die noch nicht praxiserprobt sind. Erinnern Sie sich an will-change? Und wissen Sie immer, was jeder von Ihnen verwendete Stil tut oder auslösen kann. Zum Beispiel kann position einen Stapelkontext und einen enthaltenden Block erzeugen, während overflow einen Blockformatierungskontext erzeugen kann.

Meiner Erfahrung nach reicht es nicht aus, CSS in- und auswendig zu kennen, um CSS für eine große Organisation effizient zu schreiben. Während meiner Zeit bei Yahoo! geriet ich oft in Widerspruch zu Leuten, mit denen ich Jahre zuvor übereinstimmte. Die Umgebung ist brutal und man muss sehr pragmatisch sein, um viele Fallstricke zu vermeiden. Wenn Sie das nächste Mal den Quellcode eines großen Projekts betrachten und etwas sehen, das für Sie keinen Sinn ergibt, denken Sie an diesen Tweet von Nicholas Zakas

Anstatt anzunehmen, dass Menschen dumm, unwissend und fehlerhaft sind, gehen Sie davon aus, dass sie klug sind, ihr Bestes tun und dass Ihnen der Kontext fehlt.

— Nicholas C. Zakas (@slicknet) 10. Februar 2013

Wie wurde Yahoos Übergang zu Atomic CSS intern aufgenommen?

TK: ACSS wurde von unserem My Home Page-Team gut angenommen, aber außerhalb dieses Teams lief es nicht gut. Unsere erste Interaktion war mit dem Sports-Team in Santa Monica. Steve und ich waren in einem Konferenzgespräch und versuchten, die Entwickler davon zu überzeugen, dass das Nichtbefolgen des Prinzips der Trennung der Zuständigkeiten der richtige Weg sei und nicht zu Chaos führen würde.

Wir verwiesen sie auf einen Beitrag, den Nicolas Gallagher kürzlich geschrieben hatte, in der Hoffnung, dass ein Artikel von einem „Außenstehenden“ helfen würde, aber nein! Die Dinge liefen nicht gut und es gab viel Reibung. Das Hauptproblem war die Tatsache, dass die Bibliothek aus Utility-Klassen bestand, aber ihre *Syntax* nicht zur Erleichterung des Gesprächs beitrug.

Ich erinnere mich auch an ein Treffen mit dem Mail-Team, das dem Konzept von Atomic CSS nicht widersprach, aber einen eigenen JavaScript-Ansatz entwickeln wollte, um „einfache“ CSS-Deklarationen zu verwenden – da sie die ACSS-Syntax *nicht ertragen konnten*. In jedem Fall sprachen die *Daten* für die Bibliothek (~36% weniger CSS *und* HTML) für sich, so dass ACSS schließlich übernommen wurde. Und heute, über sieben Jahre später, verwenden Yahoo! Home Page, Yahoo! Sports, Yahoo! News, Yahoo! Finance und andere Yahoo!-Produkte immer noch ACSS.

Um besser zu verstehen, wie ein Ansatz wie ACSS Projekte mit hoher Komponentens Wiederverwendbarkeit unterstützen kann, kopieren Sie das Markup einer Komponente von Yahoo! Finance und fügen Sie es in Yahoo! News ein. Diese Komponente sollte aussehen, als gehöre sie zur Seite. Das liegt daran, dass ACSS diese Komponenten seitenunabhängig macht.

Wie entstand die Idee, Klammern für Klassennamen zu verwenden? Wurde die Syntax von der Funktionsschreibung inspiriert?

TK: Wir hatten – durch viele Iterationen – zwei Sätze von „Kandidaten“ für die Verwendung als Trennzeichen für Eigenschaftswerte identifiziert: Klammern, (), und eckige Klammern, [].

Renato erinnert sich, dass wir Klammern gegenüber eckigen Klammern wegen der Vertrautheit mit Funktionen in JavaScript gewählt haben, auch wenn dies mit den Kosten einer zusätzlichen Shift-Tastendruck verbunden war. Die ACSS- Syntax wurde so konzipiert, dass

• die automatische Generierung von Regeln durch Atomizer erleichtert wird
• Entwicklern die Möglichkeit gegeben wird, beliebige oder komplexe Stile zu erstellen, die sie wünschen
• die Lernkurve auf ein Minimum reduziert wird

Es sieht so aus

[<context>[:<pseudo-class>]<combinator>]<Style>[(<value>,<value>?,...)][<!>][:<pseudo-class>][::<pseudo-element>][--<breakpoint_identifier>]

Entwickler erstellen ihre Klassen nach der obigen Konstruktion. Die Kernsyntax basiert auf Emmet, einem beliebten Toolkit. Wir haben den Emmet-Ansatz übernommen, um Eigenheiten zu reduzieren, da Kernklassen explizite Eigenschaft/Wert-Paare und keine *beliebigen* Zeichenfolgen sind.

Wir haben auch ein Dutzend Hilfsklassen erstellt. Diese wenden mehrere Stil-Deklarationen an und sind entweder Abkürzungen, wie das Ausblenden von Inhalten für sehfähige Benutzer, oder Hacks, wie die Verwendung von .Cf für Clearfix. Und wir haben den Entwicklern durch die Verwendung einer Konfigurationsdatei, in der sie Variablen – wie .PrimaryColor –, Breakpoints und vieles mehr erstellen können, noch mehr Freiheit gegeben.

Leute, die noch nie mit ACSS gearbeitet haben, werden sagen, dass die Syntax im besten Fall zu seltsam ist, aber Leute, die damit vertraut sind, werden sagen, dass sie *in vielerlei Hinsicht clever* ist.

Erzählen Sie uns, wie Ihr Artikel „Challenging CSS Best Practices“ für Smashing Magazine zustande kam?

TK: Ich hatte zuvor viele Artikel in verschiedenen Online-Publikationen veröffentlicht, daher war es für mich natürlich, einen Artikel über diesen „herausfordernden“ Ansatz zu schreiben.

Yahoo! sponserte im Oktober 2013 eine Front-End-Konferenz, auf der Renato einen Vortrag über unsere Lösung halten sollte, und ich versuchte, den Artikel vorher zu veröffentlichen. Ich entschied mich, ihn nicht im Yahoo! Developer Network zu veröffentlichen, da die Website keinen Kommentarbereich bot. A List Apart konnte ihn nicht rechtzeitig veröffentlichen, aber Smashing Magazine beschleunigte seinen Überprüfungsprozess, um den Artikel vor Ende Oktober veröffentlichen zu können.

Meine Wahl, einen Verlag mit Kommentarfunktion zu wählen, zahlte sich aus, da der Artikel über 200 Kommentare erhielt, was für mich, der auf sie antworten musste, sehr zeitaufwendig und frustrierend war.

Fühlt es sich seltsam an, dass der Artikel immer noch den Haftungsausschluss für die besprochenen Techniken enthält, obwohl er in der Branche mittlerweile weithin beliebt ist?

TK: Als der Artikel veröffentlicht wurde, sagte ich Vitaly [Friedman, Mitbegründer von Smashing Magazine], dass diese Notiz für mich wie eine Art Haftungsausschluss klang; dass sie die Leser davon abhalten würde, den Artikel zu lesen. Aber ich habe mich nicht wirklich dagegen gewehrt, da ich verstand, woher Vitaly kam. Ich finde es amüsant, dass diese Notiz immer noch da ist, obwohl diese Methodologie mittlerweile zum Mainstream geworden ist.

Wenn man bedenkt, dass Hindsight 20/20 ist, gibt es etwas, das Sie an Atomic CSS ändern möchten?

TK: Es gibt immer Raum für Verbesserungen, umso mehr, wenn man die Lösung als Pionier entwickelt hat. Man kann nicht auf das schauen, was andere getan haben, um aus ihren Fehlern oder Mängeln zu lernen. Man hat kein Material, das man verbessern könnte. Daher wäre es von uns anmaßend zu glauben, dass wir es beim ersten Versuch richtig gemacht haben.

Auf der Atomic CSS-Seite hatten wir viel Erfahrung, da wir ein „statisches“ Stylesheet über ein Jahr lang in einem großen Projekt entwickelt und verwendet hatten. Aber auf der dynamischen Seite – der Werkzeugseite – war es nicht so, als könnten wir uns dort viel Inspiration holen. Denken Sie daran, dass es *sechs Jahre* dauerte, bis andere Bibliotheken folgten.

Auf Französisch sagen wir: essuyer les plâtres.

Ein Fehler, den wir gemacht haben, war die Verwendung von „Atomic CSS“ als Titel für acss.io, denn wie John Polacek feststellte, schuf dies einige Verwirrung. Diesen Titel haben wir inzwischen geändert.

Das einzige Bedauern, das ich habe, ist, wie die Community Atomic CSS/ACSS im Laufe der Jahre behandelt hat, was kürzlich zu einem seltsamen Austausch führte, bei dem mir jemand erklärte, was „Atomic CSS“ bedeutet

Die Atomic CSS-Bibliothek [ACSS] verwendet zwar den Namen, aber ich denke, das ist irreführend, weil die Funktion, über die Sie sprechen, die dynamische Stilgenerierung ist. „Atomic CSS“ als allgemeiner Begriff bezeichnet kleine Selektoren als Atome, aber sie sind statisch.

Sprechen Sie davon, ausgelöscht zu werden. ;)

---

Ein großes Dankeschön an Thierry für die Teilnahme an diesem Interview und dafür, dass er uns erlaubt hat, es für die Community zu veröffentlichen.