Der Schmetterlingseffekt - CSS in größeren Projekten

520 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
520
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • NICHT NUR GROSSES, UMFANGREICHES CSS!
  • NICHT NUR GROSSES, UMFANGREICHES CSS!
  • 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
  • Der Schmetterlingseffekt - CSS in größeren Projekten

    1. 1. Der Schmetterlingseffekt CSS in größeren Projekten Sebastian Reiners open knowledge GmbH
    2. 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. 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. 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. 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. 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
    7. 7. Inhalt 1. Ausgangslage 2. Aufbau und Strukturierung 3. CSS Frameworks 4. CSS Preprocessing 5. Qualitätssicherung und Buildprozess 6. Fazit 09.09.2015 Herbstcampus 2015 7
    8. 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. 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. 10. kurze Begriffsklärung Aufbau von Regeln: a:hover { text-decoration: underline; } 09.09.2015 Herbstcampus 2015 10 Selektor Eigenschaft Wert Eigenschafts-Deklaration Regel
    11. 11. Gestaltungsfaktoren CSS • Dateiaufteilung • Sortierung / Aufbau der Regeln • Aufbau der Selektoren • Aufbau der Deklarationen 09.09.2015 Herbstcampus 2015 11
    12. 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. 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. 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. 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. 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. 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. 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. 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
    20. 20. Objektorientiertes CSS • Inhalt • HTML Elemente + direktes CSS • Container • komplexere Strukturen, die Inhalte gruppieren • Objekte • Container + Layout + Skin CSS 09.09.2015 Herbstcampus 2015 20
    21. 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. 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. 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. 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. 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. 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. 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. 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
    29. 29. Welche Frameworks gibt es? 09.09.2015 Herbstcampus 2015 29
    30. 30. Kurzes Beispiel Anhand von Bootstrap 09.09.2015 Herbstcampus 2015 30
    31. 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. 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. 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. 34. Was bietet {Less}? • Variablen • Nesting • Verschachtelung von Klassen • Vererbung und Mixins • Funktionen und Operationen 09.09.2015 Herbstcampus 2015 34
    35. 35. Kurzes Beispiel Wir machen was mit {Less}. 09.09.2015 Herbstcampus 2015 35
    36. 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. 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. 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. 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. 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. 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. 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. 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. 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
    45. 45. Fragen? 09.09.2015 Herbstcampus 2015 45
    46. 46. Vielen Dank Sebastian Reiners open knowledge GmbH www.openknowledge.de facebook.com/openknowledge twitter.com/_openknowledge

    ×