Wie wir bei Factorial CSS schreiben

„Gut“ ist ein sehr subjektiver Begriff. „Gut“ ist das, was für uns funktioniert. Beginnen wir damit, zu definieren, anhand welcher Merkmale ein CSS-Code unserer Meinung nach unsere Anforderungen erfüllt.

Es richtet sich in erster Linie an Menschen

Auch wenn der Code in erster Linie für Browser entwickelt wird, sind es doch Menschen, die ihn tatsächlich lesen und damit interagieren. Er ist weder voreilig optimiert noch übermäßig ausgeklügelt. Es ist von größter Bedeutung, dass er für Ihre Kollegen oder Mitwirkenden verständlich ist.

Das ist schlüssig und passig

Er wird gemäß einem vordefinierten Regelwerk verfasst, an das sich alle Mitglieder unserer Organisation halten. Dazu gehören Klammern, Doppelpunkte, Leerzeichen usw. Der Code sollte so aussehen, als wäre er von einer einzigen Person geschrieben worden.

Es hat nur minimale Seiteneffekte

Schlechtes CSS hat das Problem, dass es in andere Bereiche übergreift. Dies führt oft zu unnötigen Überschreibungen und einer Aufblähung des Codes. Könnte der Code unabhängig vom Kontext an beliebiger Stelle platziert werden? Würde dies zu Fehlfunktionen führen? Würde es Konflikte verursachen?

Es ist kombinierbar

Lässt es sich weiter aufteilen? Lässt sich daraus größere, komplexere Komponenten aufbauen? Ist es von außen konfigurierbar? Müssen die Nutzer die Details der Implementierung kennen?

Es ist wiederverwendbar

Löst es ein bestimmtes Problem vollständig? Wie viele Abhängigkeiten hat es? Lässt es sich in angemessener Weise abstrahieren? Könnte es als Modul veröffentlicht werden?

Was wir verwenden

Wir haben viele verschiedene Optionen ausprobiert: Ich persönlich habe über Semantik diskutiert, CSS nach den Webstandards geschrieben, LESS geschrieben, SASS geschrieben, SCSS geschrieben, Grid-Frameworks verwendet, Compass verwendet, Foundation verwendet, Inuit.css verwendet, Bootstrap verwendet. Was auch immer Ihnen einfällt – ich habe es wahrscheinlich schon verwendet. Jeder Schritt, den ich unternommen habe, hat mich unserem aktuellen Setup nähergebracht.

Methodik

Wir halten uns an die Designprinzipien und die Namenskonvention von SUIT CSS. Wir betrachten es größtenteils eher als Methodik denn als Framework. Im Grunde handelt es sich um Prinzipien der Informatik, die auf CSS angewendet werden.

Uns gefällt, dass …

• es das Problem der Stilkapselung löst.
• seine Komponenten und Hilfsfunktionen sehr robust und designunabhängig sind.
• es extrem modular ist. npm install  ist alles, was man braucht.

So wird es geschrieben:

.u-utilityName {} 
.ComponentName {} 
.ComponentName--modifierName {} 
.ComponentName-descendentName {} 
.ComponentName.is-stateOfComponent {}

Die SUIT-CSS-Namenskonvention

Das hat sich bei uns durchgesetzt. Sie ermöglicht es uns, unsere eigenen Komponenten zu entwickeln – mit der Gewissheit, dass wir uns auf klare Regeln stützen können. Wir haben festgestellt, dass sie uns bei unserer täglichen Arbeit äußerst hilfreich ist.

Preprocessing¹

Wir verwenden PostCSS, um unsere CSS-Dateien zu bündeln und zu verarbeiten. SASS ist ein wunderbares und in der Branche anerkanntes Tool, aber wir halten es für zu leistungsstark. CSS ist keine Programmiersprache. Die Erweiterung um eine nicht standardkonforme Obermenge kann leicht zu schlechtem Produktions-CSS führen, wenn Entwickler sich zu schlau anstellen.

Wir möchten so nah wie möglich an den W3C-Spezifikationen schreiben. Das bedeutet, dass wir uns auf eine minimale Anzahl von Prozessoren beschränken. Diese erleichtern uns die Arbeit, werden aber wahrscheinlich in Zukunft auch von den Browser-Anbietern implementiert werden²:

• postcss-import
• postcss-url
• postcss-custom-properties
• postcss-calc
• postcss-color-function
• postcss-custom-media
• postcss-pseudoelements
• autoprefixer

Von dieser Liste abzuweichen ist völlig in Ordnung. Es zwingt uns vor allem dazu, aktiv zu entscheiden, ob wir eine bestimmte Funktion benötigen oder nicht. Zum Beispiel: Es gibt Fälle, in denen wir so etwas wie „extends“ oder „Mixins“ benötigen würden, aber das sind die Ausnahmen. Regeln sind dazu da, gebrochen zu werden. Aber wir brauchen einen Grund, um dies zu tun.

Wie wir dies durchsetzen

Wir verfügen über eine gemeinsame Stylelint-Konfiguration mit einem festen Regelsatz. Diese erweitert die Konfiguration von SUIT CSS um eine benutzerdefinierte Sortierreihenfolge der Eigenschaften, die von codeguide.co inspiriert ist und sich stärker am Box-Modell des Browsers orientiert. Die Regelsätze werden über gulp-stylelint durchgesetzt. Zusätzlich verwende ich ein SublimeLinter-Plugin für sofortiges Feedback in meinem Editor³.

Alles zusammen: Die Arbeit mit SublimeText und dem aktivierten Stylelint-Plugin. Wenn man genau hinschaut, sieht man die roten Punkte und Statusmeldungen des Linters.

Fazit

CSS ist ein fast unbezähmbares Biest. Aufgrund der Natur des Internets unterliegt es ständigen Veränderungen. Was heute funktioniert, funktioniert morgen vielleicht schon nicht mehr. Unser Ansatz ist bestenfalls eine fundierte Prognose für die Zukunft. Das Problem der Stilkapselung könnte bald der Vergangenheit angehören. Manche fangen bereits damit an, CSS in JavaScript einzubinden. Vielleicht wird es eines Tages eine breite Unterstützung für Webkomponenten geben.

Die Fähigkeit, sich anzupassen und Spaß an den damit verbundenen Herausforderungen zu haben, macht unseren Job so faszinierend.

Weiterführende Literatur

• About HTML semantics and front-end architecture
• Scalable and Modular Architecture for CSS
• Object-Oriented CSS
• Responsive Design Workflow
• Atomic Design
• SUIT CSS

¹ Es ist uns völlig egal, wie Sie es nennen. ² Siehe caniuse, z.B. CSS custom properties. ³ In unserem Büro sind Editoren eine Frage der persönlichen Vorliebe.