Speaker: Sebastian Reiners
Je größer ein Web-Projekt wird, umso komplizierter und nervenaufreibender wird die Wartung und erst recht die Änderung des bestehenden CSS. Jeder der schon einmal zwei Wochen vor dem Live-Gang das Web-Frontend komplett umstellen durfte oder ein in die Jahre gekommenes (und entsprechend gewachsenes) Stylesheet überarbeiten sollte, wird wissen wovon hier die Rede ist.
In diesem Vortrag werden kleine und größere Tipps gegeben, wie man solchen Situationen begegnet, sie unter Kontrolle behält und bestenfalls von vorneherein vermeidet. Der Fokus wird dabei auf dem Aufbau wartbarer Stylesheets, der Nutzung von CSS-Frameworks wie Bootstrap, CSS-Preprocessing mittels Less und der Integration ins Build-Management liegen.
2. Worum soll es gehen?
• Was haben Schmetterlinge und CSS gemeinsam?
• Was macht ein wartbares CSS aus?
• Was kann mir die Arbeit erleichtern?
• Bekomme ich das alles in meine Projektabläufe
integriert?
02.09.15 Herbstcampus 2015 2
3. Kleine Ursache ...
09.09.2015 Herbstcampus 2015 3
Wir haben die Webseite im Vorstand
präsentiert.
Die hätten das Ganze lieber in wärmeren
Farben. Mit wesentlich mehr Blautönen!
4. Kleine Ursache ...
09.09.2015 Herbstcampus 2015 4
Ja, aber ...
Und die Navigation soll statt oben an
der linken Seite sein.
Aber in 2 Wochen ist der Livegang!
5. Kleine Ursache ...
09.09.2015 Herbstcampus 2015 5
Das weiß der Vorstand. Deshalb muss
das auch diese Woche fertig werden,
damit sie nochmal drüberschauen
können.
Außerdem ist Blau keine warme Farbe!
6. ... und große Wirkung
• Der Schmetterlings-Effekt
• vom Flügelschlag zum Wirbelsturm
• kleine Änderungen an der Gestaltung => komplexe
Änderungen am CSS
09.09.2015 Herbstcampus 2015 6
8. Größere Projekte?
• Nicht nur umfangreiches CSS
• sondern auch:
• Projekte mit mehreren Leuten
• CSS mit häufigen Änderungen
• CSS in mehreren Varianten
09.09.2015 Herbstcampus 2015 8
9. Was sind die Ursachen?
• CSS ...
• ... wird häufig stiefmütterlich behandelt
• ... ist eine Arbeit die "nebenher" erledigt wird
• ... wird häufig unterschätzt
• ... wird genau so komplex werden wie jeder andere Teil
des Sourcecode
09.09.2015 Herbstcampus 2015 9
10. kurze Begriffsklärung
Aufbau von Regeln:
a:hover {
text-decoration: underline;
}
09.09.2015 Herbstcampus 2015 10
Selektor
Eigenschaft Wert
Eigenschafts-Deklaration
Regel
12. Dateistrukturen für CSS
• Basis Stylesheet (Reset, Einzelelement CSS)
• Layout (ggf. Unterscheidung Desktop/Mobile)
• Module (klar separierbare oder wiederkehrende
Elemente)
• Status (Gestaltung der Module in versch.
Zusammenhängen)
• Theming ("kundenspezifische" Einstellungen)
09.09.2015 Herbstcampus 2015 12
13. Dateistrukturen für CSS
• bestimmte Dateien nur laden, wenn sie benötigt werden
• bei Mobile Stylesheets
• bei sehr komplexem CSS für einzelne Module
09.09.2015 Herbstcampus 2015 13
14. Organisation in den Dateien
• Regeln thematisch sortieren
• mit Kommentaren
• Andere Sortierungen unhandlich
bis unsinnig.
• Ständige Frage: Gehört die Regel
noch in diese Datei?
09.09.2015 Herbstcampus 2015 14
15. Aufbau der Regeln
• Regeln sollten ...
• ... nicht redundant sein
• ... wiederverwendbar sein
• Selektoren sollten ...
• ... sich nur nach guter Überlegung direkt auf HTML
Elemente beziehen
• ... möglichst wenig IDs enthalten
• ... nicht überspezifisch sein
09.09.2015 Herbstcampus 2015 15
div#mySpecialContainer > div#mySpecialSubContainer {
background-color: #999;
color: #222;
border: 1px solid #922;
}
16. Aufbau der Regeln
• Klassen sollten ...
• ... semantisch benannt sein
• Eigenschafts-Deklarationen sollten ...
• ... alphabetisch sortiert sein
• ... Kurzschreibweisen benutzen
• ... auf !important verzichten
• ... nicht in style-Attribute geschrieben werden
09.09.2015 Herbstcampus 2015 16
17. Objektorientiertes CSS
• Möglichkeit der CSS Strukturierung
• überträgt OO-Prinzipien auf HTML/CSS
• wiederverwendbare Komponenten
• konzeptioniert durch Nicole Sullivan
09.09.2015 Herbstcampus 2015 17
18. Objektorientiertes CSS
• Was ist ein "Objekt" in OOCSS?
• Verbund aus:
• HTML
• CSS
• zugehörige Elemente (bspw. Bilder)
09.09.2015 Herbstcampus 2015 18
19. Objektorientiertes CSS - Grundprinzipien
• Trennen von Struktur und Gestaltung
• wiederholte Styles herausziehen
• Klassen zur Benennung von Objekten und
Komponenten
• Container von Inhalt trennen
• keine "ortsabhängigen" Styles
• stattdessen eigene Klasse
09.09.2015 Herbstcampus 2015 19
21. Beispiel-Objekt
09.09.2015 Herbstcampus 2015 21
<div class="panel panel-warning">
<div class="panelheading">
<h3>Überschrift im Panel</h3>
</div>
<div class="panelbody">
<p>Und hier steht dann ...</p>
</div>
</div>
22. OOCSS – Pro und Contra
Pro:
• Wiederverwendbare Strukturen
• erheblich kleineres CSS
• bessere Verteilbarkeit im Team
Contra:
• leicht größeres HTML (Classitis)
• bricht mit Prinzip der Kaskadierung
09.09.2015 Herbstcampus 2015 22
23. Über CSS hinaus
• Dokumentation, auch für das Stylesheet!
• auch wenn man alleine arbeitet
• aufwändigere Erklärungen nicht im CSS!
• Festlegung von Coding Guidelines
• Was gehört wo hin?
• Code Formatierung
09.09.2015 Herbstcampus 2015 23
24. Immer wieder neu...
• Muss ich bei jedem Projekt immer wieder von vorne
anfangen?
• vorgefertigte Stylesheets
• fertiger Werkzeugkasten
09.09.2015 Herbstcampus 2015 24
25. CSS Frameworks
• Bieten vorgefertigte Lösungen
• Erstellung von Grids
• Formatierung von typischen Elementen
• Buttons
• Tab-Leisten
• ...
• automatische Anpassung für Mobile Browser
09.09.2015 Herbstcampus 2015 25
26. Frameworks - Vorteile
• sind sehr robuste Stylesheets
• kümmern sich idR. schon um Cross-Browser Probleme
• sehr schnell anwendbar
• gemeinsame Grundlage für alle Beteiligten
• nehmen einem "Basisarbeit" ab
09.09.2015 Herbstcampus 2015 26
27. Frameworks - Nachteile
• häufig ein eigenes Look & Feel
• setzen bestimmten Stil voraus
• sind oft "mehr als man braucht"
• da häufig Multi-Purpose
• Kollisionsgefahr mit eigenem CSS und JavaScript (sofern
schon etwas besteht)
• jeder muss das Framework kennen
09.09.2015 Herbstcampus 2015 27
28. Frameworks - Einsatz
• Ich benutze Frameworks wenn ...
• ich schnell ein Ergebnis brauche
• keine besonderen Anforderungen an das Aussehen
gestellt werden
• ich Arbeit abgenommen bekommen möchte
• ich noch am Anfang des Projektes stehe
09.09.2015 Herbstcampus 2015 28
31. "Aber CSS ist doof ..."
• CSS wirkt manchmal etwas unvollständig
• hat eine nicht ganz intuitive Syntax
• bspw. Wiederholungen in Selektoren
• bei bestimmten Änderungen sehr schlecht handhabbar
09.09.2015 Herbstcampus 2015 31
32. "Aber CSS ist doof ..."
• Was wenn man eine Skriptsprache hätte, die all das
kann, was man möchte?
• Was wenn man über diese ein CSS generieren könnte?
• CSS Preprocessor
• {Less}
• Sass (Syntactically Awesome Stylesheets)
• Myth (CSS the way it was imagined.)
09.09.2015 Herbstcampus 2015 32
33. {Less} – Ein Preprocessor
• in JavaScript geschrieben
• kann als Script in HTML eingebunden werden
• oder über Node.js ausgeführt werden
• {Less} Skripte sind eine Obermenge von CSS
• alles aus CSS ist in {Less} gültig
09.09.2015 Herbstcampus 2015 33
34. Was bietet {Less}?
• Variablen
• Nesting
• Verschachtelung von Klassen
• Vererbung und Mixins
• Funktionen und Operationen
09.09.2015 Herbstcampus 2015 34
36. Preprocessing - Vorteile
• forciert DRY Pattern im CSS
• teilweise intuitiver
• leichtere Änderbarkeit
• führt zu besser organisiertem CSS
• zumindest im Quellcode
09.09.2015 Herbstcampus 2015 36
37. Preprocessing - Nachteile
• Eine weitere Schicht an Komplexität
• fehleranfälliger
• erschwert Debugging
• generiertes CSS kann "explodieren"
• "von Hand" kann besser sein
09.09.2015 Herbstcampus 2015 37
38. Wann benutze ich das?
• für Theming wie geschaffen
• um umfangreiche Stylesheets sauber strukturieren zu
können
• auch nachträglich einführbar
• für das Plus an Komfort
09.09.2015 Herbstcampus 2015 38
39. Gutes CSS sicherstellen
• Habe ich automatisch ein gutes CSS, wenn ich das alles
mache?
• Vielleicht Ja. Wahrscheinlich Nein!
• Noch wesentlich mehr Fehlerquellen, auf die man achten
sollte.
• gerade in großen Projekten
09.09.2015 Herbstcampus 2015 39
40. Was sind das für Fehler?
• inhaltliche Fehler
• Eine kleine Auswahl:
• fehlende Fallback-Werte bei neueren CSS Features
• CSS Hacks
• Box-Sizing und daraus resultierende Probleme
• übermäßiger Gebrauch von Web-Fonts
09.09.2015 Herbstcampus 2015 40
41. Kann ich das abfangen?
• Überprüfung mit Developer Tools
• Code-Reviews
• Regelmäßige Überprüfung mit CSS Lint
• ist konfigurierbar
• nicht jede Regel macht in jedem Fall Sinn
• zumindest einmal vor dem Live-Gang das fertige
Stylesheet überprüfen
• besser: in die Build-Umgebung einbinden
09.09.2015 Herbstcampus 2015 41
42. Die Buildumgebung
• Kann ich das auch automatisch machen (lassen)?
• {Less}
• CSS Lint
• Als Maven-Plugin verfügbar
• Sehr einfach über Grunt
• "normale" Umgebung der Tools ist idR. Node.js / Grunt
• für alle Vorteile: Grunt aus Maven ansteuern
09.09.2015 Herbstcampus 2015 42
43. Fazit
• Tagelanges Probieren erspart mir Stunden an Planung!
• Vieles kann auch bei bestehendem CSS nachträglich
eingeführt werden:
• Modularisierung
• Einsatz eines Preprocessors
• Qualitätssicherung
09.09.2015 Herbstcampus 2015 43
44. Fazit
• CSS wird immer Änderungen unterworfen sein.
• gerne auch zu unmöglichen Zeitpunkten
• Ich muss den Änderungen mit Struktur begegnen.
• Woanders plane ich ausgiebig. Warum nicht auch bei
CSS?
09.09.2015 Herbstcampus 2015 44
Zuerst die Funktionalität. Ums Aussehen kannst Du dich nachher kümmern! => und dann is es zu spät
CSS wird Stück für Stück erweitert, je nachdem wie die Anwendung entwickelt wird => komplexe Lösungen die einfacher hätten sein können
Ich muss da ja nur die Abstände ein wenig erhöhen => Und dann verrutscht alles => Das führt zu Punkt 4
Vom Großen zum Kleinen
Wichtigkeit von Reset betonen
Mandanten-spezifisch näher erläutern!
ALLES ALS MÖGLICHKEITEN, ALS ORIENTIERUNG
Wiederverwendbares und immer wiederkehrendes in eigene Klasse auslagern
Beispiel mit input[type=button]{} => Was wenn man auf <button> wechselt?
nicht ".redText" sondern ".errorText"
Der einzige der in Style-Attribute ins HTML schreibt ist der JavaScript Interpreter im Browser!
ERSTE HINWEISE GINGEN SCHON IN DIESE RICHTUNG
Konzept ist nicht unbedingt neu, allerdings durch Nicole Sullivan erstmals so konsequent durchdacht und formuliert
Auch bereits bekannte Prinzipien aus anderen Bereichen
Struktur & Gestaltung: -> gemeinsame Styles in eine Klasse herausziehen (Bsp. Hintergrund von Widgets und Tabs)
Container & Inhalt: -> Inhalte nicht von den Containern abhängig machen
Auch bereits bekannte Prinzipien aus anderen Bereichen
Auch bereits bekannte Prinzipien aus anderen Bereichen
Auch bereits bekannte Prinzipien aus anderen Bereichen
Verweis auf das Reset Stylesheet
Konfigurierbarkeit von Bootstrap erwähnen!!
2. sofern das Framework ein eigenes Aussehen mitbringt
3. sei es, dass ich mich mit CSS nicht ganz so gut auskenne oder dass ich die Zeit anderweitig benötige
YAML: Yet another multicolumn layout (nicht Markup-Sprache zur Datenserialisierung)
Man merkt was diese Preprocessor wollen!
Ein erweitertes CSS um die Features, die man schon immer gebraucht hat.
zuerst in Ruby
Ich kann mit Variablen (und generell mit Zahlen) auch Berechnungen anstellen.
Erschwertes Debugging: das was im Browser ist, entspricht nicht mehr dem Quellcode
Explodieren: Durch wiederholte Vererbung, Includes u.ä. können 10 Zeilen Less Code zu über 200 im CSS anwachsen
=> Theming: Bootstrap macht das über Less
da passieren zwangsläufig irgendwann Flüchtigkeitsfehler oder Sachen werden aus Bequemlichkeit heraus gemacht
nur eine Auswahl an Fehlern!
neues CSS Features: RGBA-Farben
Box-Sizing, Web-Fonts: Problematik erläutern
CSS Lint: ebenfalls mit Beteiligung von Nicole Sullivan => daher auch stark in Richtung OOCSS
Grunt aus Maven => Verweis auf Svens Vortrag
Wann ist es zu spät Qualitätssicherung einzuführen? Eigentlich nie!
Sei sie automatisiert oder vielleicht auch einfach in Form von REVIEWS, wie ich sie sonst bei Quellcode auch mache
Behandeln wir CSS bitte wie anderen Quellcode auch