11. Mein modularer Ansatz

Die Grundphilosophie der objektorientierten Projekte gefällt mir. Denn sie wenden den Blick auf die Seitenbestandteile und verstehen eine Webseite als Addition einzelner Objekte. Mit einigen Details der Nomenklatur stehe ich allerdings auf Kriegsfuss. Insbesondere mit dem Ansatz, immer Klassen an Stelle von Elementen im CSS anzusprechen, kann ich mich nicht anfreunden.

Da erfahrungsgemäß nicht jeder Entwickler immer in der gleichen Art und Weise seine Projekte erarbeiten kann, gehe ich von einem gemeinsamen Blick auf die CSS-Entwicklung aus, der uns auf unterschiedlichen Wegen zum gleichen Ziel bringen kann: qualitativ gute, modulare Webseiten.

Meine Grundsätze bei der Entwicklung von Webseiten sind Folgende:

• Im Zentrum meiner Arbeit stehen einzelne Module, keine kompletten Webseiten.
• Die Module sind eigene kleine Universen.
• Es gibt nur wenige globale Styles.
• Es gibt eine Trennung zwischen Layout und Design.
• Jedes Modul sollte ohne Probleme auch an einer anderen, sinnvollen Stelle des Layouts platziert werden können.
• Elemente beeinflussen sich zwischen Modulen nicht.
• Semantik ist und bleibt Teil des HTML. Es werden die für den Zweck passenden Elemente genutzt.
• Zu Beginn des Projektes sollte man sich entscheiden, ob das Differenzieren von Designdetails im HTML-Code stattfinden kann oder nur über das CSS laufen soll.
• IDs sind für exakt zwei Sachen gut: Formularelemente und wichtige Strukturbereiche des Layouts. Für Letztere schreibe ich sie auch möglicherweise in mein CSS.

Ich ergänze diese Grundregeln noch durch zwei persönliche Regeln:

• Ein Framework hält mir lästige, immer wiederkehrende Probleme vom Hals: es definiert einen Basis-Codestil, ermöglicht die schnelle Lösung der grundlegenden Layoutaufgaben und bietet eine erste Dokumentation.
• Ich nutze einen Präprozessor, damit ich effizient und modular arbeiten kann. Wenn ich es mir aussuchen kann, dann nutze ich Sass.

Wähle Deine Waffen weise

Ich bin immer wieder irritiert, wenn jemand postuliert, ich solle keine IDs oder Inline-Styles nutzen. Beides sind normale Bestandteile des CSS-Standards. Sie sind deshalb nicht per se besser oder schlechter, als Klassen oder ausgelagerte Styles. Es kommt immer auf den Einsatzzweck an. Wir müssen uns Gedanken über Vor- und Nachteile des eigenen CSS-Ansatzes machen. Und so kann es sein, dass wir zielgerichtet Inline-Styles nutzen, weil sie der sinnvollste, sicherste und schnellste Weg zur Zielerreichung sind.

Ich hatte vor Jahren in einem Projekt Teaser mit Hintergrundbildern umgesetzt. Diese Hintergrundbilder sollten von Redakteuren editiert werden können. Selbstverständlich kamen deshalb Inline-Styles zum Einsatz. Techniken müssen nicht immer zu 100% in einem Projekt genutzt werden. Manchmal sind sie punktuell hilfreich. Deshalb ist eine globale Verteufelung einzelner Techniken wenig sinnvoll.

Es ist aber auch wenig sinnvoll, seine komplette Webseite mit Inline-Styles zu versehen. Denn dann muss man immer die Templates modifizieren, wenn man an einem Style eine Änderung vornimmt. Und - noch viel wichtiger - kann man nicht vom Caching einer externen CSS-Datei profitieren. Zudem sind manche Techniken wie die Nutzung von Pseudoelementen mit Inline-Styles nicht möglich.

Einzelne HTML-Dateien

Wenn es mir das Projekt erlaubt, schreibe ich meinen Frontendcode in kleine HTML-Schnipsel, passend zu den kleinen Sass-Schnipseln. Ich konzentriere mich zuerst auf die Entwicklung der Module, indem ich sie innerhalb eines selbstentwickelten, schlichten Styleguides betrachte und kontrolliere. Erst in einem späteren Schritt entstehen ganze Seiten, in denen die einzelnen Module dann zusammen wirken. Auch hier arbeite ich selbstverständlich mit den Includes. Da ich meine Arbeit normalerweise an andere Entwickler weiterreiche, die mein HTML dann in Templates für ihr CMS überführen, verzichte ich auf die Nutzung einer Templatesprache. Das würde zu unnötigen Verständnisschwierigkeiten und Reibungsverlusten führen. Mittlerweile spiele ich allerdings mit dem Gedanken, Handlebars einzusetzen, um die Erstellung von Iterationen einzelner Module zu erleichtern.

Taskrunner

Vor einigen Jahren habe ich mir die Nutzung von Grunt angewöhnt. Es ist toll, welche Funktionsvielfalt ein solcher Taskrunner bietet. Immer wieder ergänze und überarbeite ich mein bisheriges Setup. Ich versuche mich dabei aber zu beschränken, denn man kann sich sehr schnell vor lauter Begeisterung in der Arbeit mit Grunt verlieren.

Ein mir sehr wichtiger Task ist dabei php2html. Mit dessen Hilfe werden alle meine kleinen PHP-Dateien, die ich zum Testen und zur Demonstration entwickelt habe, in HTML-Dateien umgewandelt. Diese kann ich dann an Kunden und Kollegen weitergeben, denn nicht jeder hat ganz selbstverständlich einen Webserver auf dem eigenen Rechener laufen oder weiss damit umzugehen. Für ein Projekt, bei dem keine dynamischen Inhalte erstellt oder nachgeladen werden müssen, ist die Auslieferung reiner HTML-Dateien viel sinnvoller, als den PHP-Interpreter zu nutzen.

Schnipsel im CSS dank Präprozessoren

CSS zu programmieren war schon lange der Wunsch vieler Entwickler. Präprozessoren eröffnen diese Möglichkeit. Sie ermöglichen zudem, ein Stylesheet in viele kleine Einzeldateien zu unterteilen und für die Ausgabe einer einzigen Datei zu importieren. Dieser Prozess läuft nur in der eigenen Entwicklungsumgebung ab und birgt deshalb nicht die sonst zu erwartenden Performancenachteile einer Aufsplittung von CSS in viele Einzelteile.

Es gibt ein paar unterschiedliche Präprozessoren. Neben dem Platzhirsch Sass gibt es im Wesentlichen noch LESS und Stylus. Aber auch PostCSS kann man so nutzen, dass die vorgenannten komplett ersetzt werden. Die grundlegenden Vorgehensweisen und Erkenntnisse gelten für alle Projekte. Sie unterscheiden sich in Details der Syntax und in wenigen Fähigkeiten. Ich konzentriere mich im Weiteren auf Sass.

Variablen

Variablen sind der schnellste Nutzen, den man aus der Verwendung von Präprozessoren ziehen kann. Die Auslagerung designrelevanter Details wie Farben, Abstände, Schriftarten und -größen ermöglicht es uns, sehr schnell eine Modifikation des gesamten Auftrittes vorzunehmen. So sind kleine Designanpassungen oder gar Themes in Windeseile realisiert.

Aufteilung des CSS in viele einzelne Module

Ich nutze Sass im Wesentlichen, um mein CSS so optimal und effizient wie möglich modularisieren und abstrahieren zu können. Das tue ich bspw. indem ich nicht an einer großen, sondern an vielen kleinen, spezialisierten CSS-Dateien arbeite. Diese importiere ich dann in eine zentrale Datei, die dann wiederum von Sass in eine CSS-Datei gewandelt wird. In dieser zentralen SCSS-Datei stehen idealerweise nur Verweise auf importierte Modul- sowie Konfigurationsdateien.

Durch die starke Modularisierung - jedem Modul eine eigene Datei - kann ich einzelne Bestandteile eines Projektes wiederverwenden. Diese vielen kleinen Einzelteile machen es auch einfacher, im Team an einem gemeinsamen CSS zu arbeiten. Jeder Entwickler bekommt seine Modul-Datei(en) zugewiesen und kommt dadurch den Kollegen nicht in die Quere.

Ich versuche bei der Aufteilung der Dateien, jedem Modul seine eigene SCSS-Datei zu geben. Ich gebe der SCSS-Datei dann den Namen des Moduls. Darüber hinaus werden die Regeln für das Layout in eine eigene SCSS-Datei gepackt. Ich erstelle keine Dateien für einzelne Breakpoints, wenn ich eine responsive Seite erstelle. Stattdessen schreibe ich die notwendigen Mediaqueries immer an den Teil des Moduls, der verändert werden soll. Das erleichtert mir die Suche beim Debuggen oder bei einer notwendigen Veränderung.

Die Zuweisung von Mediaqueries geschieht dabei über ein kleines Mixin, das mir Schreibarbeit wegnimmt. Zudem lagere ich die Werte der Breakpoints als Variablen aus. Sie können somit zentral angepasst werden.

 1 // Das Mediaquery-Mixin
 2 
 3 @mixin mq($dimension, $breakpoint, $breakpoint2:false\
 4 ) {
 5     @if $dimension == min {
 6 		@media screen and (min-width: $breakpoint) {
 7 			@content;
 8 		}
 9 	} @else if $dimension == max {
10 		@media screen and (max-width: $breakpoint) {
11 			@content;
12 		}
13 	} @else if $dimension == min-max {
14 		@media screen and (min-width: $breakpoint) and (max\
15 -width: $breakpoint2) {
16 			@content;
17 		}
18 	}
19 }

Beispiel einer Verzeichnisstruktur

In meinem Sass-Ordner befinden sich grundsätzlich folgende Elemente:

 1 sass/
 2   _config.scss
 3   _modules.scss
 4   _mixins.scss
 5 
 6   config/
 7     _colors.scss
 8     _mediaqueries.scss
 9     _modules.scss
10     _project-basics.scss
11 
12   mixins/
13     _forms.scss
14     _helpers.scss
15     _lists.scss
16     _mediaqueries.scss
17     _navigation.scss
18 
19   modules/
20     _fonts.scss
21     _forms.scss
22     _helpers.scss
23     _layout.scss
24     _lists.scss
25     _navigations.scss
26     _normalize.scss
27     _page-footer.scss
28     _typography.scss
29     fonts/
30       _svg-icons.scss
31     forms/
32       _buttons.scss
33       _form-cnt.scss
34       _text.scss
35     lists/
36     navigations/
37       _breadcrumb.scss
38       _main-navigation.scss
39 
40   styles.scss

1. Es gibt eine styles.css, deren Inhalt von Projekt zu Projekt identisch bleiben kann, da darin nur Dateien importiert werden, die ihrerseits wieder Dateien importieren: _config.scss, _modules.scss und _mixins.scss.
2. Ein Ordner mit Mixins. Sollten diese aus unterschiedlichen Quellen kommen, werden sie in Ordnern separiert. Platzhalter habe ich mittlerweile abgeschafft. Früher waren sie auch in diesem Ordner. Alle Mixins werden in der Datei _mixins.scss importiert.
3. Der Ordner modules enthält alle Module. Darin platziere ich auch eventuelle Framework-Dateien, die ich modifiziere. Das Framework selber soll in seinem Ordner unverändert bleiben, damit ein Update ohne größere Nebeneffekte möglich ist. Die Benennung der Moduldateien sollte im Wesentlichen selbsterklärend sein. In Dateien wie _layout.scss und _helpers.scss sind allgemeine Regeln gesammelt. Dateien für konkrete Module werden möglichst mit deren Klassennamen benannt(z.B. _page-footer.scss).
4. Auch im Ordner modules können sich Unterordner befinden. Deren Inhalte werden dann in einer Datei importiert. Die Datei modules/_lists.scss importiert also alle Inhalte aus dem Ordner modules/lists/.

Insbesondere der letzte Schritt, Dateien aus Unterordnern noch einmal in einer speziellen Datei zu importieren, erscheint Ihnen vielleicht übertrieben. Ich sehe darin den Vorteil, einen schnelleren Überblick zu bekommen. Bei der Suche nach importierten Listen-Dateien werde ich nicht von Dateien anderer Art abgelenkt. Aber grundsätzlich können Sie natürlich alle Module in der _modules.scss oder gar der styles.scss importieren. Ich bevorzuge den auf den ersten Blick umständlicheren Weg.

Module erstellen

In einem ersten Schritt identifiziere ich gleichartige Module innerhalb eines Projektes. Das funktioniert natürlich dann besonders gut, wenn das Design schon mehr oder weniger fertig vorliegt. Doch eigentlich ist dieses alte Vorgehen, dass der Frontendentwickler die Brocken vom Designer zwecks Umsetzung hingeworfen bekommt, nicht mehr zeitgemäß. Angesichts der Notwendigkeit responsiver Umsetzung müssen Design und Frontendentwicklung vielmehr parallel laufen. Und so kann es passieren, dass zusätzliche Iterationen zu einem schon existierneden Modul hinzukommen.

Da ich mich in solchen Situationen auch schon hin und wieder über meine eigenen Entscheidungen geärgert habe, versuche ich nun mittlerweile, vorsichtiger vorzugehen:

1. Klassennamen sollten relativ abstrakt sein. Zu konkrete Funktionszuweisungen können stören, wenn das gleiche oder ein ähnlich aussehendes Modul in einem anderen Sinnzusammenhang benutzt wird.
2. Die Inhalte von Modulen sollten sich ändern können, ohne dass es das Modul beschädigt. Ein Teasercontainer muss mit einem Video, einem Suchfeld oder einer Liste bestückt werden können.
3. Manchmal muss man mutig entscheiden, das prinzipiell gleiche Modul doppelt vorzuhalten. Insbesondere bei Suchfeldern für unterschiedliche Zwecke, die evtl. manchmal per JavaScript erweitert werden.

Ein konkretes Beispiel für den ersten Punkt hatte ich in einem Projekt, in dem ich dachte, alle Inhaltsmodule schon zu kennen. In diesem Projekt gab es bislang ein Selectfeld und das war ein Sonderfall, da es mittels “typeahead” dynamisiert wurde. Das JavaScript vergab selber viele Klassen, sodass ich keine eigene mehr ausdenken musste.

Als dann die Anforderung für zwei Selectfelder zur Auswahl von Datum bzw. Zeit kam, schrieb ich alle Styles der Klasse .date-time zu. Ich dachte schliesslich, es gäbe keine weiteren Selectfelder. Nach ein oder zwei Wochen wurde ich eines besseren belehrt. Nun sollte auch die Auswahl von alternativen Adressen in einem Selectfeld abgehandelt werden. Das Styling sollte dem von Datum und Zeit gleichen. Glücklicherweise nahm der Entwickler, der meine Module in eine Angular-Applikation implementierte, die Änderung der Klasse leicht. Es war trotzdem ein Zeichen, dass ich nicht gut genug nachgedacht hatte. Von Anfang hätte hätte die Klasse abstrakter lauten müssen, bspw. .select. Damit wäre Klasse unabhängig vom Inhalt geblieben. In diesem konkreten Falle wäre es auch ein hilfreicher Hinweis gewesen, welches Element gerade neu gestaltet wird.

Kapselung der Module für sich selber

Namen für Module zu finden ist schwer. Sie sollten abstrakt genug sein, dass sie frei für unterschiedlichste Inhalte verwedent werden können. Abstrakte Varianten wie .box-1 und .box-2 sind aber auch schwer zu nutzen, denn ohne eine häufige Referenz auf eine Art Dokumentation benötigt man für die Anwendung der Klassen ein prima Gedächtnis.

Der Name des Moduls sollte auch der Name der SCSS-Datei sein, ebenso der Name der Include-Datei (HTML). Im CSS sollte vor dem Namen des Moduls nichts stehen. Das Modul steht für sich allein und ist dadurch transportabel. Es kann allerdings Situationen geben, in denen es geboten ist, diese eiserne Regel aufzubrechen. Ein Beispiel:

Für ein Projekt gibt es einheitliche Stile für Buttons. Die großen Buttons werden überall auf der mobilen Seite genutzt. Über sie gelangt man von Seite zu Seite der Applikation. Es gibt insgesamt sechs verschiedene Seitentypen, die sich unterschiedlichen Abständen der Inhalte zu den Browserrändern niederschlagen. Auf mindestens einer dieser Seitentypen hat der große Button einen größeren horizontalen Margin, als sonst. Und dieser unterscheidet sich zudem von den anderen Elementen auf diesem Seitentyp.

Wollte man der bisher propagierten eisernen Regel folgen, müsste man mit einem Modifikator dafür sorgen, dass der Browser eine geringere Breite oder größere horizontale Margins besitzt.

Zur Unterscheidung haben wir aber schon einen Ansatzpunkt: den “Seitentyp”. Er schlägt sich in einer Klasse auf einem Elternelement des Buttons nieder. Anstatt nun also den Button direkt zu formatieren, kann man die kleine Abweichung auch in Abhängigkeit zur Existenz auf einem Seitentypen machen. Je nachdem, was für das eigenen Templating passender ist.

In solchen Fällen sollte es sich aber immer um eng begrenzte Modifikationen handeln. Es gilt die gleiche Regel, wie bei Modifikatoren: möglichst nur eine Eigenschaftsdimension verändern.

Module auszeichnen

Als BEM bekannt wurde sträubte sich in mir alles, diese Methodologie zu nutzen. Schliesslich kann BEM in sehr langen Klassennamen resultieren. Mit der Zeit und mit der notwendigen Praxis haben sich meine Befürchtungen gegeben. Ich empfinde BEM noch immer nicht als “schön”, ich sehe aber meine Aufgabe auch nicht darin, schönen Code zu schreiben. Er soll vielmehr wartbar und für andere lesbar sein. Das wiederum bietet mir BEM. Mir sind dabei aber zwei Aspekte wichtig:

1. Wenn es eine zwingend einfache HTML-Struktur gibt (unverschachtelte Listen und Tabellen), dann verzichte ich darauf, jedem Element eine Klasse zu geben. Elementselektoren wurden genau für diesen Zweck erfunden.
2. Es gibt keine “Enkel”-Selektoren, nur eine 1:1-Beziehung zwischen dem Element und dem Modul.

Den ersten Aspekt hatte ich schon früher thematisiert. Als Beispiel dienten mir Naviagtionen. Einfache Navigationen würden von mir nur eine Klasse als Modul bekommen, die einzelnen Bestandteile würden über Elementselektoren gestaltet werden. Dadurch ist das HTML schlank. Kommen Subnavigationen hinzu, wird das CSS komplexer und zusätzliche Klasse kommen ins HTML. Das ist dem Anlass angemessen.

Den zweiten Aspekt möchte ich im Folgenden illustrieren. Nehmen wir uns beispielhaft einen Teaser vor:

 1 <div class="teaser">
 2   <header class="teaser__headercontainer">
 3     <h3 class="teaser__headercontainer__header">Übers\
 4 chrift</h3>
 5   </header>
 6   <div class="teaser__content">
 7     <p class="teaser__content__paragraph">Lorem Dinge\
 8 nskirchen und so weiter, ihr wisst schon ....</p>
 9   </div>
10   <footer class="teaser__footer">
11     <a href="linkziel.html" class="teaser__footerlink\
12 ">weiterlesen ...</a>
13   </footer>
14 </div>

Das Headerelement innerhalb des Teasers ist optional. Auf den ersten Blick ist es nicht notwendig. Möglicherweise erfüllt es seine Dienste, um Designdetails zu ermöglichen. Es kann also sein, dass eine zukünftige Iteration dieses Teasers (in einem anderen Projekt) ohne das Headerleement auskommen kann. Die Klasse am Überschriftenelement impliziert aber geradezu die Existenz dieses Headerelements. Durch die Benamung wird eine Struktur reflektiert. Exakt dies sollte durch BEM ja aufgelöst werden. Also sollten wir niemals “Enkelelemente” mit BEM erschaffen. Die korrekte Klasse wäre .teaser__header.

Auch der Absatz innerhalb von .teaser__content krankt an diesem Problem. Hinzu kommt, dass die Inhalte möglicherweise über einen Editor von einem Redakteur gepflegt werden sollen. Dies bedeutet natürlich, dass auch andere Inhalte als nur Absätze eingegeben werden könnten. Deshalb sollten für die Inhalte von .teaser__content nur Elementselektoren im CSS zum Einsatz kommen. So verhindern Sie, dass die Redakteure Klassen an Elemente fügen müssen.

Im Falle des Footers wird die korrekte Lösung deutlich. Der weiterführende Link bezieht sich in der Klassenbenamung nur auf das Modul und nicht auf seine konkrete Umgebung. Es wird uns dadurch ermöglicht, die Struktur zu verändern, ohne das Styling des Links zu beeinträchtigen. Die bessere Strultur sähe aöso folgendermaßen aus:

 1 <div class="teaser">
 2   <header class="teaser__headercontainer">
 3     <h3 class="teaser__header">Überschrift</h3>
 4   </header>
 5   <div class="teaser__content">
 6     <p>Lorem Dingenskirchen und so weiter, ihr wisst \
 7 schon ....</p>
 8   </div>
 9   <footer class="teaser__footer">
10     <a href="linkziel.html" class="teaser__footerlink\
11 ">weiterlesen ...</a>
12   </footer>
13 </div>

Ein System erarbeiten, das alle intuitiv verstehen

Alle Systeme und Handlungsempfehlungen sind nur dann gut, wenn sie vom Entwickler verstanden und akzeptiert werden. Sie müssen in Fleisch und Blut übergehen können, damit keine Fehler und keine unnötigen Zeitverzögerungen entstehen. Bei der Arbeit im Team ist es zudem wichtig, dass sich alle an diese Spielregeln halten.

Sowohl für Einzelkämpfer als auch für ein Team sollten folgende Punkte geklärt und abgestimmt werden:

1. Welche einheitlichen Benamungsregeln sollen gelten?
2. Soll ein Namespace genutzt werden?
3. Wie soll der Code eingerückt werden? (Eine Zeile oder mehrere?)
4. Wie oft soll ins Versionierungssystem committet werden?
5. Kommentare auf alle Fälle, aber wie und was?
6. In welcher Sprache sollen Klassennamen und Kommentare verfasst sein?

Meine Antwortvorschläge sind folgende:

zu 1.: Ich empfehle BEM. Je nach Teamzusammensetzung nehmen Sie die ursprüngliche, strikte Version oder eine etwas aufgeweichte. Ich habe meine Gründe dafür oben beschrieben. Ich bevorzuge BEM, weil es einfach ist. Die Klassen müssen nicht zusätzlich kategorisiert werden (Base, Module, Theme usw.). Und es ist eine Art Industriestandard. Wenn neue Entwickler zum Team stossen ist es wahrscheinlicher, dass diese schonmal mit BEM gearbeitet haben, als mit SMACSS oder einer selbst ausgedachten Variante.

zu 2.: Namespaces sind dann hilfreich, wenn man mit einem Framework arbeitet oder die Arbeit anderer ergänzt. Sie verhindern ungewollte Kollisionen. Wenn sie genutzt werden, sollten sie sehr kurz sein. Am Besten nur zwei Buchstaben, gefolgt von einem Minuszeichen.

zu 3.: Ich habe früher versucht, eine Regel immer in einen Zeile zu schreiben. Bei breiten Monitoren ist das nicht schwierig. Darunter leidet allerdings die Übersichtlichkeit. Zudem ist es bei der Nutzung von Versionierungssystemen sinnvoll, jede Eigenschaft in eine eigene Zeile zu schreiben. So sieht man später bei einem Diff die wahren Unterschiede schneller auf einen Blick.

zu 4.: Ich committe oft. Ich committe immer, wenn ich eine Aufgabe abgearbeitet habe. Ich achte dabei nicht auf Fehlerfreiheit. Die kann man oft erst sehr viel später feststellen. Aber wenn ich bspw. ein Suchfeld erstellt habe, ein eigenes Modul also, dann committe ich dies. Idealerweise hat dieses Modul ein eigenes Ticket, das ich dann an den Anfang der Commit-Nachricht schreibe. Mein Commit geht primär lokal. Nicht jeder kleine Commit muss dann auch ins allgemeine Repo übertragen werden. Das kann auch später erst gesammelt geschehen.

zu 5.: Ich schreibe Kommentare immer dann in den Code, wenn ich den Eindruck habe, etwas erklären zu müssen. Die Zielperson bin ich selber in naher Zukunft aber logischerweise auch meine Kollegen oder noch unbekannte Personen. Eventuell genutzte Tricks dokumentiere ich, indem ich den Link zum Artikel in einen Kommentar schreibe. Ansonsten gerne auch Hinweise, wann eine bestimmte Klasse genutzt wird. Aber niemals Dokumentationen von HTML-Strukturen. In Mixins dokumentiere ich manchmal die Anwendung desselben im CSS. Ich nutze dabei immer den doppelten Slash als Kommentarzeichen, da diese von Sass nicht ausgegeben werden. Und Kommentare sind nur für Entwickler gedacht. Sie haben im produktiven CSS nichts verloren.

zu 6.: Klassennamen und IDs sollten in Englisch verfasst sein. Sollte man Hilfe benötigen und sich an Stackoverflow wenden, helfen deutsche Klassennamen nicht viel. Englisch ist zudem kompakter und hat keine Umlaute. Ich gestehe aber ein, dass es mir schwer fällt, diesen Grundsatz über das ganze Projekt durchzuhalten.

Arbeit in einer Pattern Library

Wie ich oben schon erwähnte, habe ich in letzter Zeit meine Module isoliert in einer Art Pattern Library erschaffen. Oft wird in diesem Zusammenhang auch von Styleguides gesprochen.

Nachdem alle bislang existierenden Applikationen mir aus unterschiedlichen Gründen nicht gefielen bzw. nicht in meine Arbeitsweise passten, baute ich mir meine eigene Pattern Library. Sie soll für mich nur dreierlei können:

1. Die Module werden untereinander nach Typ auf eigenen Seiten sortiert. So habe ich bspw. alle Formulare oder Tabellen auf eigenen Seiten und sehe sofort, wenn es Konflikte zwischen Styles gibt.
2. Der HTML-Code des jeweiligen Moduls soll dargestellt werden. Zusätzlich dazu verzeichne ich noch den Pfad zum passenden Include, falls mein Kunde mit meinen Quelldateien arbeitet.
3. Es gibt optionale Notizen, die den Einsatz des HTML bzw. die Eigenheiten des CSS näher erläutern können.

Einer der Ausgangspunkte für meine Eigenentwicklung war Paul Robert Lloyds Pattern Primer. Für künftige Projekte überlege ich, meinen Workflow so zu verändern, dass ich mit Fractal oder Brad Frosts Style Guide Guide arbeiten kann.

Durch die Arbeit innerhalb einer solchen Pattern Library fokussiere ich mich auf das jeweilige Modul. Ich empfinde diese Arbeit als sehr effizient. Vor einigen Jahren war ich für das Frontend eines großen Schweizer Shops zuständig. Bis auf die Startseite, die wie immer eine Insellösung ist, habe ich alle zur Diskussion stehenden Unterseiten - etwa 20 - erst ganz zum Schluss erstellt. Dafür kombinierte ich dann die jeweiligen Grundlayouts mit den erstellten Modulen. Innerhalb kurzer Zeit waren viele Beispielseiten erstellt. Die einzelnen Module hingegen entwickelte ich ausschliesslich innerhalb meiner Pattern Library.

Da meine Arbeit normalerweise darin besteht, Backend-Entwicklern zuzuarbeiten und nicht selber an CMS-Templates zu schrauben, ist die Arbeit an einer separaten Pattern Library möglich. Die Backendentwickler nehmen sich meine beispielhaft entwickelten HTML-Schnipsel und überführen sie in Templates für ihr CMS. Eine Pattern Library kann aber selbstverständlich auch innerhalb eines CMS entstehen.

Eine tolle Übersicht über Styleguides und Pattern Libraries bietet styleguides.io. Dort findet man Tools, konkrete Beispiele und Artikel. Es lohnt sich, dort zu schmökern.

Lösung und Problem gleichermassen

Ich empfinde die Arbeit mit einer Pattern Library als große Hilfe und Erleichterung. Sie erlaubt mir die Konzentration auf die jeweiligen Module. Eine solche Arbeitsweise ist aber nicht die ideale Lösung für alle Beteiligten:

• Es ist nicht einfach, sich ein solches Modul im Kontext einer gesamten Seite vorzustellen.
• Designer ohne gute Kenntnisse in HTML und CSS werden Schwierigkeiten haben, ein neues Modul als schlichte Iteration eines bestehenden oder als konkrete Neuentwicklung einzustufen.
• Prototyping mit den bestehenden Modulen ist nur für Projektbeteiligte möglich, die sich gut mit der verwendeten Templatingtechnologie auskennen (oder bspw. mit Includes in PHP).

Ein Pattern Library kann man mit gutem Willen und ein wenig Arbeit zu einem echten Styleguide ausbauen. Denn wenn man dies nicht schon selber getan hat, fehlen zu den Modulen im Wesentlichen noch Übersichten über verwendete Farben, Schriften und Icons. Ein Styleguide in HTML hat den Vorteil, dass er im Zielmedium existiert. Die bisherigen PDF-Versionen sind vor allem hübsch. Hilfreich wären sie aber eher als HTML-Version.