Downloaden Sie, um offline zu lesen
Hochgeladen vonOPEN KNOWLEDGE GmbH
Der Schmetterlingseffekt - CSS in größeren Projekten
Das Dokument behandelt den Schmetterlingseffekt in CSS für größere Projekte, indem es auf die Bedeutung einer wartbaren CSS-Architektur und die Herausforderungen bei der Integration in Projektabläufe eingeht. Es werden Methoden zur Strukturierung und Organisation von CSS vorgestellt, darunter das Nutzen von CSS-Frameworks und Preprocessing, um effizientere und wiederverwendbare Stile zu schaffen. Zusammengefasst wird betont, dass eine sorgfältige Planung und Dokumentation notwendig ist, um langfristig erfolgreiche Projekte zu gewährleisten.
Weitere ähnliche Inhalte
![Tecnologia de la informacion[1]](https://cdn.slidesharecdn.com/ss_thumbnails/tecnologiadelainformacion1-120904172620-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Ähnlich wie Der Schmetterlingseffekt - CSS in größeren Projekten
Der Schmetterlingseffekt - CSS in größeren Projekten
- 1. Der Schmetterlingseffekt CSS ingrößeren Projekten Sebastian Reiners open knowledge GmbH
- 2. Worum soll esgehen? • 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.2015Herbstcampus 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.2015Herbstcampus 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.2015Herbstcampus 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ßeWirkung • Der Schmetterlings-Effekt • vom Flügelschlag zum Wirbelsturm • kleine Änderungen an der Gestaltung => komplexe Änderungen am CSS 09.09.2015 Herbstcampus 2015 6
- 7. Inhalt 1. Ausgangslage 2. Aufbauund Strukturierung 3. CSS Frameworks 4. CSS Preprocessing 5. Qualitätssicherung und Buildprozess 6. Fazit 09.09.2015 Herbstcampus 2015 7
- 8. Größere Projekte? • Nichtnur 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 dieUrsachen? • 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 vonRegeln: a:hover { text-decoration: underline; } 09.09.2015 Herbstcampus 2015 10 Selektor Eigenschaft Wert Eigenschafts-Deklaration Regel
- 11. Gestaltungsfaktoren CSS • Dateiaufteilung •Sortierung / Aufbau der Regeln • Aufbau der Selektoren • Aufbau der Deklarationen 09.09.2015 Herbstcampus 2015 11
- 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 denDateien • 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öglichkeitder CSS Strukturierung • überträgt OO-Prinzipien auf HTML/CSS • wiederverwendbare Komponenten • konzeptioniert durch Nicole Sullivan 09.09.2015 Herbstcampus 2015 17
- 18. Objektorientiertes CSS • Wasist 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
- 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. Beispiel-Objekt 09.09.2015 Herbstcampus 201521 <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 – Pround 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 • Bietenvorgefertigte 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
- 29. Welche Frameworks gibtes? 09.09.2015 Herbstcampus 2015 29
- 30. Kurzes Beispiel Anhand vonBootstrap 09.09.2015 Herbstcampus 2015 30
- 31. "Aber CSS istdoof ..." • 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 istdoof ..." • 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} – EinPreprocessor • 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
- 35. Kurzes Beispiel Wir machenwas mit {Less}. 09.09.2015 Herbstcampus 2015 35
- 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 ichdas? • 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 dasfü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 dasabfangen? • Ü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 • Kannich 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 Probierenerspart 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 wirdimmer Ä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.
- 46. Vielen Dank Sebastian Reiners openknowledge GmbH www.openknowledge.de facebook.com/openknowledge twitter.com/_openknowledge
Hinweis der Redaktion
- #8 NICHT NUR GROSSES, UMFANGREICHES CSS!
- #9 NICHT NUR GROSSES, UMFANGREICHES CSS!
- #10 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
- #13 Vom Großen zum Kleinen Wichtigkeit von Reset betonen Mandanten-spezifisch näher erläutern!
- #16 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?
- #17 nicht ".redText" sondern ".errorText" Der einzige der in Style-Attribute ins HTML schreibt ist der JavaScript Interpreter im Browser!
- #18 ERSTE HINWEISE GINGEN SCHON IN DIESE RICHTUNG Konzept ist nicht unbedingt neu, allerdings durch Nicole Sullivan erstmals so konsequent durchdacht und formuliert
- #20 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
- #21 Auch bereits bekannte Prinzipien aus anderen Bereichen
- #22 Auch bereits bekannte Prinzipien aus anderen Bereichen
- #23 Auch bereits bekannte Prinzipien aus anderen Bereichen
- #25 Verweis auf das Reset Stylesheet
- #28 Konfigurierbarkeit von Bootstrap erwähnen!!
- #29 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
- #30 YAML: Yet another multicolumn layout (nicht Markup-Sprache zur Datenserialisierung)
- #33 Man merkt was diese Preprocessor wollen! Ein erweitertes CSS um die Features, die man schon immer gebraucht hat.
- #34 zuerst in Ruby
- #35 Ich kann mit Variablen (und generell mit Zahlen) auch Berechnungen anstellen.
- #38 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
- #39 => Theming: Bootstrap macht das über Less
- #40 da passieren zwangsläufig irgendwann Flüchtigkeitsfehler oder Sachen werden aus Bequemlichkeit heraus gemacht
- #41 nur eine Auswahl an Fehlern! neues CSS Features: RGBA-Farben Box-Sizing, Web-Fonts: Problematik erläutern
- #42 CSS Lint: ebenfalls mit Beteiligung von Nicole Sullivan => daher auch stark in Richtung OOCSS
- #43 Grunt aus Maven => Verweis auf Svens Vortrag
- #44 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
- #45 Behandeln wir CSS bitte wie anderen Quellcode auch