CSS-Architektur

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Stefan Tilkov: Hallo und herzlich willkommen zu einer neuen Episode des innoQ Podcasts. Heute zum Thema CSS Architektur, ein ziemlich schräger Titel, der zwei Begriffe zusammen mixt, die man normalerweise so nah beieinander vielleicht nicht erwarten würde. Dazu hab ich zwei kompetente Kollegen dabei, zum einen den Roman Stranghöner. Hallo Roman!

Roman Stranghöner: Hi, ich bin der Roman. Ich arbeite seit zwei Jahren bei der innoQ, bin halt Softwareentwickler und als Consultant unterwegs und habe da projekttechnisch meinen Fokus momentan auf Frontend, Frontend Entwicklung gelegt mit Ruby on Rails, und darüber hinaus CSS und Präprozessoren als mein Steckenpferd gewählt.

Stefan Tilkov: Und den Falk Hoppe haben wir noch dabei. Hallo Falk.

Falk Hoppe: Ja, ich bin der Falk, ich arbeite jetzt auch seit ein paar Jahren bei der innoQ und bin hier auch als Entwickler maßgeblich im Railsumfeld tätig und hab halt eben CSS und Co. als Hobby und Beruf, öfters auch mal im Handgemenge.

Stefan Tilkov: Ok. Dann erklärt mir doch um Himmels Willen warum ihr der Meinung wart, wir sollten diesen Podcast CSS Architektur nennen? Was um Himmels Willen hat das mit einander zu tun?

Falk Hoppe: Ja, das ist im Prinzip relativ einfach. Also es war halt immer so, dass die Leute einfach CSS so runter geschrieben haben und das in der Regel natürlich auf gar keinen Fall Softwareentwickler waren, sondern eher irgendwelche Designer und Co. und das halt definitiv auch eher ein Designtool war, aber es ja mittlerweile doch immer mehr Charakteristiken von einer richtigen Softwarearchitektur aufweist, bzw. eben komplizierter wird.

Stefan Tilkov: Ok. Was wäre das, was sind Beispiele für Dinge, die man in der Softwarearchitektur, bei klassischen Systemen findet und bei CSS auch beobachten kann?

Falk Hoppe: Ja also bei diesem unstrukturierten CSS hat man halt immer gemerkt, dass es sehr, sehr unwartbar wurde, weil man in der Regel z.B so etwas wie Codekommentare total vergessen hat. Die gibt es normalerweise nicht. Das ist schon mal so der klassische Punkt von so einem idiomatischem CSS, was man irgendwie auf einer idiomatischen Programmierschreibweise erwarten würde. Und ganz viele andere Codeconventions: Wie gehe ich mit Whitespaces und Tabs um? Was mach ich mit Formating, dass ich da konsistent bleib. Da gäbe es so diesen Nicolas Galagher mit idiomatic CSS, der ja immer gesagt hat, man soll eigentlich, egal wie viele Leute CSS schreiben, es aussehen lassen, als hätte es eine Person geschrieben. Dann gibt es im Prinzip diese größeren Abstraktionen, wie SOLID, die halt aus der Softwarearchitektur bekannt sind, deren Prinzipien im Prinzip auch im einzelnen auf CSS anwendbar sind. Vielleicht kann der Roman noch etwas dazu sagen.

Roman Stranghöner: Ja, genau, also das größte Ding, was man eigentlich so machen kann ist eigentlich der Punkt, der einem als erstes einfällt, ist irgendwie, dass man Dinge von einander trennt, die unterschiedliche Concerns betreffen. In der Regel, wenn man sich CSS so anschaut oder CSS schreibt, kann man relativ leicht Design von Struktur trennen, also man sollte eigentlich nicht daher gehen und anfangen in seinen CSS Klassen diese Dinge miteinander zu vermischen…

Stefan Tilkov: Moment, moment, lass mich da mal dazwischenquatschen. Ist nicht das Trennen von Struktur und Design schon passiert, weil man Struktur in HTML und Design in CSS macht? Davon sprichst du nicht, oder?

Roman Stranghöner: Nee, genau, ich spreche von Layout, also wie die Dinge angeordnet sind, ist etwas komplett anderes, als wie die Dinge aussehen. Sagen wir mal du hast irgendwie einen Blogpost, der besteht aus so einem Avatar, ein bisschen Text und vielleicht noch mit einem Link – damit man draufklicken kann – dann ist das was ich meine im Prinzip das Aussehen, das „Look and Feel” von diesem Blogpost. Das eine ist, was man quasi kapseln sollte und getrennt von dem wie es quasi auf der Seite eingesetzt wird in den Containern, wie es quasi „gelayoutet” wird. Genau, das man diese beiden Dinge von einander trennt.

Falk Hoppe: Klassische Attribute sind halt so Positionierungen gegen Farbe, sag ich mal. Das ist so das eine. Die Schriftfarbe hat überhaupt nichts damit zu tun, ob das Ding irgendwie oben links oder rechts unten klebt. Und so was sollte man halt definitiv trennen.

Stefan Tilkov: Ok. Das wäre Separation of Concerns, habt ihr noch andere Architekturaspekte, die man…

Roman Stranghöner: Also klar, DRY gilt natürlich genau so, wie in…

Stefan Tilkov: Don’t repeat yourself.

Roman Stranghöner: Genau, wie in der normalen Softwareentwicklung. Also man sollte natürlich eigentlich nicht hergehen und sein CSS künstlich aufblähen und einfach wahllos irgendwelche Properties durch die Gegend kopieren, sondern sich schon Gedanken darüber machen – wenn ich eine Komponente schreibe und ich vielleicht im Hinterkopf habe, noch weitere Subkomponenten zu schreiben – welche Dinge sind quasi für alle Subkomponenten gleich und die extrahiere ich dann im Prinzip raus in eine quasi abstrakte Oberkomponente von der ich dann im Prinzip über das extend erben lasse und hab damit da schon mal die Redundanz, die ich sonst irgendwie durch die Gegend kopieren würde, hätte ich damit schon mal rausgezogen.

Stefan Tilkov: Gib doch mal ein Beispiel für eine Komponente, das ist auch so ein Begriff, den wir ja eigentlich aus der Architektur kennen. Was bezeichnest du als Komponente?

Roman Stranghöner: Es gibt in der CSS-Welt mittlerweile durch diverse Architekturkonzepte mehrere Begriffe dafür. Also es gibt sowohl Komponente, es gibt Modul, es gibt aber auch das CSS-Objekt, die alle im Wesentlichen irgendwie das selbe meinen, nämlich ein Ding auf meiner Webseite. Also wenn ich mir jetzt vorstelle, ich hab so eine Webseite – wir können den Blogbeitrag vielleicht nochmal nehmen als Beispiel oder den Blogpost – dann wäre das zum Beispiel eine Komponente, die kann wieder aus anderen Komponenten bestehen, wie z.B. einem Portrait, also so einem Portraitbild in einem Avatar oder vielleicht irgendwelche Metaangaben. All das wären Komponenten. Klar, irgendwann macht es natürlich keinen Sinn mehr, das noch unnötig weiter aufzusplitten, aber eigentlich sollte man dazu übergehen diese Dinge zu identifizieren, die man da auszeichnen möchte mit CSS und die zu extrahieren und im Prinzip da das Layout dann auch rauszuhalten.

Falk Hoppe: Genau, das kann man halt ganz gut, also es gibt dieses BEM-Principle im Prinzip, das ist von den Jandex-Leuten, von dieser Suchmaschine aus Russland. BEM ist im Prinzip ein Akronym für Block Element Modifyer. Das geht im Prinzip darum, dass man das ein bisschen so ganz klassisch wie in solchen Design-Buden macht und sich eigentlich sein Layout erst mal und diesen Designentwurf, den man von diesem Grafikdesigner bekommt, also zeichnet im Prinzip erstmal die Blöcke ein von Elemente, die man so klassifizieren kann. Ich hab da mein Anmeldeformular mit Login-Maske und ich hab da oben mein Logo, das irgendwie zum Menü sich verhält. Ich hab sowas wie einen Header, einen Footer, so diese klassischen Großkomponenten Also eine Komponente kann auch sowas sein wie eine Containerkomponente, die andere Komponenten enthält. Oder halt eben was elementares, was keine anderen Komponenten enthält. Dann gibt es halt Elemente, das wäre jetzt so was wie z.B. wenn ich ein Anmeldeformular hab, dann besteht das ja aus verschiedensten Kleinstelementen, wie zum Beispiel dem Inputfield oder dem Submit-Button und solche Dinge sind dann halt eben Elemente. Und dann gibt es auch noch so was wie einen State, der Status, der geändern werden kann, das wäre eben über so einen Modifyer. D.h., ich hab so etwas wie einen Tab zum Beispiel, so ein Tabbing. Und das ist im Prinzip so ein Architekturkonzept, wo man halt wirklich sieht, dass die Leute auch so. Also es klingt ja erstmal so banal und einfach, aber dass so was nicht gemacht wurde vorher und dass das jetzt mittlerweile so eine gewisse Verbreitung findet, das man so was tut und das ist auch sehr gut so.

Stefan Tilkov: Warum findet man CSS denn so ätzend, also warum gibt es diese starke Abneigung gegenüber CSS, von der ich mich auch nicht völlig freisprechen kann? Ich renne zwar immer durch die Gegend und erzähle, das CSS total toll ist, aber wenn ich dann selber irgendwas damit zu tun habe, ist es schon immer so eine experimentale Informatik, die man da betreibt. Liegt das daran, dass man es einfach nicht genug kann oder was ist der Hauptgrund?

Falk Hoppe: Also ich würde sagen, ja es liegt daran, dass man es nicht gut kann. Das hat aber natürlich auch einen Grund, das ist halt immer noch so, das CSS der Second-Class-Citizen ist. Keiner hat eigentlich Lust CSS zu machen. Es ist halt immer so, das im Projekt CSS auch eher eine minderwertige Rolle hat und man dann nur einen Frontend-Entwickler dafür anstellt, der nachher irgendwie so ein bisschen das CSS schön machen darf. Und der richtige Entwickler natürlich viel viel wichtigere Aufgaben hat und die natürlich auch viel viel mehr Anspruch haben und für die man viel viel mehr Wissen braucht.

Stefan Tilkov: Und für die er auch viel mehr Geld bezahlt kriegt.

Falk Hoppe: Genau und dementsprechend macht der aber auch nie CSS. Das heißt der kriegt überhaupt keine Routine in dieser Technologie und weiß einfach auch in der Regel fast nichts. Also in der Regel weiß man immer nur die untersten oder die oberen zehn Prozent – so ein bisschen Eisbergsprinzip. Und dann läuft man natürlich auch in jede pitfall rein, die die Sprache eben mitbringt.

Stefan Tilkov: Was ist denn ein guter Startpunkt um sich damit mal auseinander zu setzten?

Falk Hoppe: Also für mich war es auf jeden Fall das CSS-Zen-Garden-Buch. Das ist schon relativ alt, ich weiß gar nicht, 2001, 2002 irgendwie so was. Kommt mit einer großen Webseite daher, die ein Layout in ganz ganz verschiedenen Designs hergestellt hat und im Layouting auch sehr sehr explizit betrieben hat, wo halt diese ganzen Positionierungsfragen innigst geklärt werden. Sehr gutes Einsteigerbuch, die Website ist auch gerade neu relaunched worden. Es ist wirklich immernoch empfehlenswert. Also auch wenn natürlich auch nicht mehr alles irgendwie hochmodern und Co. ist, ist es aber wirklich ein gutes CSS Grundlagen-Buch.

Roman Stranghöner: Dann gibt es noch, vielleicht ergänzend dazu: ich selbst hab mir das immer so ein bisschen – also ganz früher – noch irgendwie selbst ein bisschen angeeignet und dann später wenn man dann auch im Projekt oder noch davor versucht oder von den Kollegen noch das ein oder andere gesagt bekommt – was dann auch noch ganz cool ist, ist dieser Beginnersguide zu CSS und HTML. Das hat ich neulich mal rausgesucht für einen Praktikanten von uns. Das ist im Prinzip so ein kleines Projekt von einem Entwickler oder von einem Designer namens Shay Howe. Und der hat im Prinzip so einen halbinteraktiven Kurs auf seiner Website, der ist auch frei, den kann mal einfach mal so machen. Den gibt es einmal in der Geschmacksrichtung Beginner und Advanced und da gibt es dann halt unterschiedliche Lektionen, die auch quasi durch alle Dinge, die man so im CSS-Umfeld mal sehen kann, die werden da auch haarklein erklärt und richten sich auch tatsächlich an Anfänger. Und der Advanced-Teil wäre dann vielleicht so etwas, den man als Entwickler mit Vorkenntnissen vielleicht mal machen kann, genau. Um diese Routine vielleicht mal ein bisschen besser reinzukriegen und die Dinge mal zu sehen, an denen man sonst so oft scheitert, wie gerade so Positioning und Boxmodel…

Stefan Tilkov: Da muss ich gleich noch mal was fragen.

Roman Stranghöner: Ja, das sind so die Stichpunkte, die jedes Mal Bauchschmerzen verursachen.

Stefan Tilkov: Ich hab aber noch ein paar Achitekturmuster ausgebuddelt von denen ich nicht weiß, ob ihr sie kennt – so was wie OOCSS oder SMACSS.

Roman Stranghöner: SMACSS, ja.

Stefan Tilkov: Was verbirgt sich dahinter?

Roman Stranghöner: Das sind diese vorhin schon mal angesprochenen Architekturkonzepte zu denen auch BEM zählt, also halbwegs zumindest. Das sind keine Frameworks in dem Sinne, sondern eigentlich ist das so ein Zusammenschrieb von Best Practices. Also was sollte man so beachten, wenn man modulares und skalierbares CSS schreiben will. Skalierbar meint in dem Kontext eher, das Projekt wächst und wird größer und bleibt dadurch dann trotzdem wartbar. Also nicht im Sinne von vielleicht irgendwelchen Hardwareanforderungen die skalierbar sein sollen. Genau, und diese Konzepte basieren zum Teil auf den Dingen die wir eben schon genannt haben. Also dieses: „Wir gucken erst mal, was für Komponenten haben wir überhaupt, wir indentifizieren erstmal diese Dinge und dann nehmen wir so was wie eine Naming-Convention her um das quasi in unserem CSS zu manifestieren, um ihm Struktur zu geben.” Und da gibt es diese drei besagten Ansätze – ich hab ehrlich gesagt nur Ahnung von SMACSS, weil ich das Buch gelesen hab von dem Jonathan Snook. Und der kategorisiert im Prinzip CSS in fünf Teile. Das sind einmal Base-Styles, das sind Layout-Styles, das sind Modul-Styles, das sind State-Styles und das sind Theming-Styles. Und diese Base-Styles sind im Prinzip das, was Falk vorhin schon mal erwähnt hat, nämlich dieses Basissetup auf meine Elementselektoren. Also das ich jetzt sage, das meine „h1” und meine „p” und meine „a” irgendwie eine bestimmte Farbe haben sollen – immer, in der gesamten Anwendung. Da muss man allerdings sehr aufpassen, weil einem da es sehr schnell passieren kann, dass einem die Kaskade von CSS sehr schnell in den Rücken fährt. Also da ist auf jeden Fall Vorsicht angebracht, aber das ist eine Kategorie, nicht diese ganz allgemeinen Dinge, die ich in CSS schreibe. Und darauf aufbauend kommen dann im Prinzip schon die Modul-Styles, das sind genau die, von den wir eben gerade auch gesprochen haben – also Modul, Komponente, CSS-Objekte im Fall von OOCSS. Die heißen überall ein bisschen anders, aber meinen eigentlich im Prinzip alle das gleiche. Und diese Module, die können halt wiederum States haben. Ob jetzt durch Pseudo-Selektoren ausgelöst oder durch Javascript können diese Module im Prinzip in verschiedene Zustände versetzt werden. Am Beispiel von diesen Tabs gibt es natürlich den Zustand active oder nicht active, das wäre so ein Beispiel. Und für sowohl die Module selbst als auch für diese States gibt es halt Namenskonventionen. Bei SMACSS ist das so, dass man den Modulnamen – also erst kommt der Modulname, dann kommt im Prinzip durch ein Minus getrennt der Submodulname – also wenn ich noch weitere Untermodule dazu hab, trenne ich die davon durch ein Minus und dann trenne ich nochmal den Modifyer durch ein Minus-Minus da hinten dran. Und so kann ich dann in meinem HTML im Prinzip diese Klassenselektoren alle hintereinander hängen und hab dann das gewünschte Ergebnis ohne das ich mir Abhängigkeiten in meinem Markup irgendwie einkaufe. Also ich bin quasi elementagnostisch, ich arbeite nur mit Klassen und kaufe mir dafür, dass ich im Prinzip mein Markup auch austauschen kann und ich vor allen Dingen diese Module wieder verwenden kann an anderen Stellen. Ich muss mich nicht darum kümmern, dass auf einmal mein „h1” innerhalb meines Moduls auf einmal kein Modul mehr ist, sondern „h2”, „h3” oder sonst irgendwas.

Falk Hoppe: Und dadurch, dass man halt eben diese Komponenten diesen Klassennamen auch von den Submodulen vorbehält, hat man halt ein sehr sehr sauberes Name-Spacing. Man kommt nicht in die Gefahr, dass man auch Seiteneffekte zwischen Komponenten erzeugt. Das ist auf jeden Fall ganz angenehm, das ist natürlich ein gewisser Overhead den man so im Markup und der CSS-Struktur halt mit sich führt.

Roman Stranghöner: Ich glaub von Profis wird das auch gerne als Classitus bezeichnet. Das ist halt immer dann sinnvoll, wenn man halt noch nicht so CSS versiert ist und einem diese Kaskade eigentlich eher in die Karre fährt, als das sie einem hilft. Dann ist man mit der Nummer auf jeden Fall immer safe und macht sich nichts kaputt.

Falk Hoppe: Genau, das ist also bei OOCSS ist es im Prinzip viel weniger restricted eigentlich. Also da geht es auch wirklich, das ist eher ein bisschen wie BEM. Das ist halt also diese Grundprinzipien, dass es auch eher auf Reusability ausgelegt ist und auch halt eben diese Trennung von Structural- und Visual-Styles hat, aber im Grunde ist SMACSS halt so ein bisschen das, was OOCSS und BEM vorher gemacht haben, plus hinzugefügt von ganz ganz vielen eigenen Ideen die der so hat. Die sind noch nicht mal alle unstrittig, also der ist auch ein ganz großer Verfechter davon IDs dadrin zu empfehlen oder die Verwendung von dem Important-Flag, was so ziemlich alles andere in der Kaskade überfährt, wenn es zuerst definiert wurde und sowas würde ich z.B. überhaupt nicht – also ich empfehle jedem sowas important überhaupt nie zu verwenden. Also das darf eigentlich meiner Meinung nach nie in Produktionscode gelangen. Und bei IDs ist das fast genauso, also das finde ist fast immer die schlechteste Idee, wenn man mit CSS arbeitet, weil die halt eben auch eine sehr hohe Spezifizität mit sich bringen.

Stefan Tilkov: Bei solchen Sachen fällt es mir immer relativ schwer, ich lese das, ich lese solche Diskussionen, solche Argumente, ich verfolg das irgendwie, und lese dann: „Ja das ist schlecht!”, aber ich hab noch nie ganz kapiert, warum? Warum ist das schlecht – Spezifizität – zuviel davon zu haben?

Falk Hoppe: Ja, der Punkt ist halt so ein bisschen der: ich hab ja Cascading Style Sheets, d.h., ich wende mehrere Regeln auf gleiche oder ähnliche Elemente an. Das kann man natürlich durch so einen Ansatz wie bei SMACSS, durch dieses name-spacing versuchen zu minimieren, aber irgendwo tu ich das immer. Und wenn ich jetzt irgendwo ein Stil mit einer sehr sehr hohen Spezifizität anbringe, dann kann ich den an späterer Stelle nicht mehr gut überbügeln. Wenn ich jetzt z.B. ein Framework includiere – nehmen wir jetzt sowas wie Bootstrap, Twitter-Bootstrap – und die bringen ganz ganz viele Styles mit, die ich auch nehmen möchte, dann möchte ich aber trotzdem z.B. von einem Button, der irgendwie important ist oder Active oder sonst irgenwas, möchte ich ja die Farbe ändern. Hätten die den jetzt aber mit einer sehr hohen Spezifizität angebracht, weil der auf irgendeiner ID gemappt ist – ein sehr abstruses Beispiel schon klar – kann ich den im Prinzip mit meinem Code nicht mehr überfahren. Also versuch ich einer späteren Stelle das Verhalten von einer Komponente zu ändern, weil ich noch mal einen Modifyer angebracht hab zum Beispiel, ist das bei ID immer sehr schwierig und deswegen ist also die Verwendung auf jeden Fall eher nachteilig.

Roman Stranghöner: Ja, also es schaukelt sich…

Stefan Tilkov: Also mit anderen Worten, wenn sozusagen in dem was ich benutze schon das spezifischste, denkbare benutzt wurde, dann muss ich überlegen, noch irgendwas spezifischeres zu finden.

Roman Stranghöner: Ja, genau. Es schaukelt sich dann halt hoch.

Stefan Tilkov: Ah, verstehe. Und dann muss jemand, der das wieder überschreiben will, braucht es noch spezifischer.

Roman Stranghöner: Ja, genau.

Stefan Tilkov: Und schreibt dann irgendwann important dran um zu sagen, dass das jetzt zwar eigentlich…

Roman Stranghöner: Ja. Je mehr Entwickler an so was beteiligt sind, desto schlimmer wird es in der Regel. Wenn man nicht ein Auge darauf hat.

Falk Hoppe: Genau, bei Smax ist es so, das diese Module zum Beispiel möglichst kurze Selektorketten haben sollen und dadurch haben die aber wenig Spezifizität, also weil die ja nur einen dieser Modulnamen tragen und daher empfiehlt er für diese Verwendung von Modulen das Important-Flag, weil er natürlich dann mit diesen Modulen diese Spezifizität erschlagen kann.

Stefan Tilkov: Verstehe. OK. Wie geht ihr denn vor? Also wenn ihr jetzt was Neues startet, wenn ihr jetzt ein neues Projekt startet und da anfangt das CSS aufzubauen. Ich nehme jetzt mal nicht das einfache Beispiel, man benutzt irgendein fertiges Framework – sowas wie Bootstrap – sondern ihr geht jetzt wirklich selbst dabei vor, der Kunde kann das oder will das auch, möchte seine eigene Identität, womit startet ihr?

Roman Stranghöner: Also ich würde mittlerweile dazu übergehen als Allererstes so ein Styleguide festzunageln. Also sowas, wie dieses idiomatic CSS, was der Falk vorhin schon erwähnt hat, also irgendeine Art von Codeconvention. Das ist mal das Allererste. Damit es nämlich genau so ist, dass der Code so aussieht als wäre er von einer Person geschrieben worden, das erleichtert schon mal viel. Am Besten nimmt man sich dann noch irgendein Tool, was das quasi validiert – ich glaub so was gibt es noch nicht, aber das wäre ganz cool, wenn es so was gäbe. Genau. Und dann, wenn man das quasi festgenagelt hat, sorgt man in der Regel dafür, dass man, wenn man in die Browserwelt geht, einen glattgebügelten Zustand hat. Glattbügeln kann man so was, indem man entweder einen Reset benutzt, ein CSS-Reset, das quasi dafür sorgt, dass in sämtlichen Browsern das Default-Styling auf 0 gesetzt wird. So ein Browser bringt ja in der Regel für nicht gestyltes HTML Default-Styling mit, also was quasi dafür sorgt, dass die Headlines zum Beispiel unterschiedlich groß sind, dass Links dieses geile Blau kriegen. Und …

Stefan Tilkov: Ja, das erkennt zumindest jeder als Link

Roman Stranghöner: Genau. Aber eigentlich: das Schlimme daran ist, dass das für jeden Browser irgendwie unterschiedlich ist und eigentlich, wenn man mit einem Projekt startet, möchte man bei 0 anfangen. Also bei 0 im Sinne von ich möchte eigentlich nicht anfangen, irgendwelche Dinge zurückzudrehen und gleich zu machen in meiner Anwendung. Eigentlich will ich das nicht, ich will das vorher schon geklärt haben, dass man quasi bei einem einheitlichen Stand anfängt und dazu kann man halt entweder den Reset nehmen – der Reset macht im Prinzip genau das, er setzt alles auf 0.

Stefan Tilkov: Das ist, um das zu erklären, eine CSS-Datei, die ich einfach…

Roman Stranghöner: Genau, das ist eine CSS-Datei, die man importet und dann sorgt das dafür, dass sämtliche Styles auf 0 gedreht werden. Ich glaub davon gibt es auch zwei Varianten, der eine ist der Meyer-Reset und den anderen kenne ich ehrlich gesagt nicht.

Falk Hoppe: Ich weiß auch nur, dass es einen anderen gibt, aber das ist im Grunde auch egal, welchen man da benutzt.

Roman Stranghöner: Ja genau. Der Meyer-Reset ist da relativ populär. Und dann gibt es dem gegenüber stehend noch einen sogenanntes Normalize-CSS. Das ist auch von dem Nicolas Gallagher mitgeschrieben worden, den wir eben schon genannt haben. Und das geht eigentlich eher dazu über, das es diese „Diff” zwischen den Browserstyles im Prinzip angleicht. Also wenn der eine Browser jetzt sagen wir mal die „h1” auf – ich weiß nicht, was sind die Defaults-Styles – 18 Pixel oder was hebt, dann versucht man im Prinzip die Unterschiede zwischen diesen Browser-Styles anzugleichen, statt sie komplett zurückzudrehen. Also es ist irgendwie der etwas nettere Weg, wenn man da dran geht, also man macht nicht alles platt, sondern hebt es auf ein Level und den kann man glaub ich sogar selber bestimmen. Man kann das im Prinzip sogar noch anpassen. Genau, aber dann hat man im Prinzip sein Setup soweit, dass man auf einem Nenner anfängt und dann kann man beginnen. Im Prinzip auf einem beliebigen Architekturkonzept, die die wir gerade genannt haben – da kann man sich eins von auswählen, je nach dem was einem da so am besten gefällt. Man kann das auch theoretisch komplett selbst sich was überlegen, da spricht auch nichts gegen, was halt klar sein sollte ist, wie man es halt macht und das irgendwo dokumentieren und festnageln, das sich auch jeder dran hält.

Stefan Tilkov: Ich entnehme aus dem, was ihr so sagt, dass ihr das in verschiedene Dateien aufteilen würdet. Ihr fangt mit so einem Reset-CSS an und auch generell soll das alles modular wahrscheinlich verteilt sein. Was benutzt ihr für Tools um mit dem Zeug zu arbeiten?

Falk Hoppe: Ja also jetzt im Railsumfeld haben wir es natürlich relativ einfach, es hat dann schon einen CSS-Kompressor im Prinzip drin, der das Ganze dann nachher zusammenfügt. Also es macht halt auf jeden Fall Sinn das ganze nachher in eine Datei zusammenzufügen. Also wir haben halt grundsätzlich sowieso den Fall, dass das ja kaskadiert, d.h., ich kann das einfach hintereinander hängen – bis auf den 4096 Selektor-Bug im IE, bei dem man dann wieder Dateien aufspalten darf, wenn man das dann noch hat. Ich glaub vor IE8 oder IE9 oder was auch immer.

Roman Stranghöner: Acht, ja.

Falk Hoppe: Aber im Grunde ist es halt sinnvoll, das ganze – wie bei Java manchmal auch – eher in ein HTTP-Request zu verpacken, den man machen muss, damit man das CSS lädt.

Stefan Tilkov: Haben wir in der Frontend-Optimierung schon drüber gesprochen, dass man sowas macht.

Falk Hoppe: Genau, also es gibt das, wenn man jetzt nicht aus dem Railsumfeld kommt, gibt es das eigentlich für beliebige Sprachen mit beliebigen Tools. Man kann das auch an irgendwelche Webseiten hochladen und sich das komprimieren lassen, also was einem da auch immer am Herzen liegt.

Stefan Tilkov: Und sonst so zum Debuggen, zum Arbeiten, was sind so die typischen Werkzeuge, wenn man mit CSS herumfummelt den ganzen Tag?

Roman Stranghöner: Auf jeden Fall eigentlich würde ich behaupten Preprozessor, aber das ist definitiv ein Thema, was eine eigene Episode wert ist

Stefan Tilkov: Machen wir.

Roman Stranghöner: Aber das bietet einem im wesentlichen schon mal das Handwerkzeug, dass man diese Module und generell die Concernes auf verschiedene Dateien auslagern kann und das nimmt einem dieses ganze Zusammenstöpseln von den einzelnen Dateien im Prinzip ab.

Falk Hoppe: Ja ansonsten…

Stefan Tilkov: IDE

Falk Hoppe: IDE ist eigentlich fast egal, würde ich behaupten. Was mir immer am Herzen liegt ist, dass die IDE so was wie Zen-HTML kann. Das hat jetzt mit dem Buch nichts zu tun, sondern das hat damit zu tun, dass es eine schöne Auto-Vervollständigung für HTML und CSS bietet. Also man kann da sehr schnell das Zeug runterschreiben, ohne das man es irgendwie willkürlich auf Abstraktionsebene braucht.

Roman Stranghöner: Das heißt übrigens mittlerweile Emmet, für die Shownotes.

fk. Ja, verdammt. Ja, ich bin alt.

Stefan Tilkov: Gut gut. Und Browsertooling?

Falk Hoppe: Genau, Browsertooling ist nämlich das, worauf ich eigentlich auch drauf hin wollte. Früher war es immer der Firebug im Firefox der so das Tool war, um das man nicht herum gekommen ist. Also was man haben möchte ist, dass man das HTML inspizieren kann in einer Webseite wenn es geladen ist und dazu sieht, welche CSS-Regeln auf welches Element Anwendung finden und auch in welcher Reihenfolge, also welche Regel was überfährt. Man kann halt relativ gut sehen, zwischendurch, wenn irgendetwas nicht so aussieht, wie es aussehen soll, dass irgendeine andere Regel aus dieser Kaskade, die ich geladen hab, meine eigentliche Regel, die ich grad erwarte, überfährt. Da sieht man dann halt auch sehr schön, diese Implikation von Spezifikationen. Dass halt dann teilweise Regeln, an die man gar nicht mehr gedacht hat, dann doch wieder irgendwas kaputt machen. Und da ist auf jeden Fall Chrome DevTools mittlerweile natürlich ein ganz großer Faktor, also die haben sehr sehr viel aufgeräumt und machen da wirklich einen sehr sehr coolen Job. Und auch immer sehr schön natürlich, man kann das ganze Zeug auch im Browser editieren, also man kann auch direkt da Regeln hinzufügen und man kann die Chrome DevTools in den Ressources abspeichern, man kann wirklich die ganze Zeit dann requestübergreifend daran arbeiten und nachher zurück in die Anwendung portieren.

Roman Stranghöner: Darüber hinaus gibt es halt noch so was wie LiveReload und CodeKit. Das sind Tools, die dir im Prinzip den Browserrefresh abnehmen. Also das ist auch ganz nett und dann kann man den Browser im Prinzip auf seinen zweiten Monitor parken, arbeitet in seinem Editor der Wahl, drückt einmal auf Save und im Browser macht es Bupp.

Stefan Tilkov: Ich seh schon.

Roman Stranghöner: Ist alles aktualisiert.

Stefan Tilkov: Wertvolle Shownotes dieses Mal, dankeschön.

Roman Stranghöner: Ja. Was es im Nachgang noch an Tooling gibt, also wenn man dann quasi soweit ist, dass sein CSS quasi fertig ist, gibt es so was wie CSS Lint. Das ist im Prinzip so ähnlich wie JS Lint, lässt man einmal über sein CSS drüberlaufen und das sagt einem dann „Die und die Dinge solltest du vielleicht nicht tun.” Dieses Tool ist relativ umstritten, also bei vielen Dingen ist das relativ aggressiv, was viele allerdings nicht wissen ist, dass man das konfigurieren kann. Also die Regeln, die da geprüft werden, die kann man konfigurieren und dem entsprechend kann man tendenziell für sein Projekt auch die Regeln raussuchen die einem irgendwie am Herzen liegen oder die einem für wichtig erscheinen, wie z.B. 4096 Selektorennummer, die kann man damit auch prüfen lassen. Genau, das ist schon mal relativ hilfreich und dann gibt es noch ein anderes ganz nettes „Toolchen”, das ist CSSCSS, also das quasi doppelt hintereinander geschrieben, und das spuckt einem im Prinzip sämtliche Properties aus, die irgenwo doppelt verwendet werden und daran kann man dann auch noch mal sehen, wo quasi noch ein bisschen DRY-Bedarf ist, den man rausziehen kann und noch ein refaktorieren kann.

Falk Hoppe: Joa, das passt glaub ich.

Stefan Tilkov: Dann lasst mich doch mal ein bisschen switchen. Erklärt mir doch mal kurz, was Responsive Design ist und was das mit dem ganzen Thema zu tun hat.

Roman Stranghöner: Willst du, soll ich?

Falk Hoppe: Ja, ich kann den Einstieg machen, vielleicht. Also, es ist jetzt halt relativ modern geworden, dass man Seiten nicht mehr nur noch statisch ausliefert, die genau für ein Device eigentlich gemacht sind. Also man hat jetzt wirklich 15 Millionen verschiedene Monitorgrößen sowieso schon mal, dazu aber auch noch natürlich jetzt diese ganze Mobil-Area und Tablet-Area und Co. und auf jedem Ding hat man verschiedene Auflösung und verschiedene Pixeldichte und und und. Und da fällt als allererstes natürlich auf, dass die Webseiten ziemlich komisch und kaputt aussehen. Und da kommt so ein bisschen diese Responsivness rein, das im Prinzip die Webseite danach ausrichten soll, auf welchem Device sie angezeigt wird. Das heißt der Client bzw. der Browser erkennt: „Ich bin auf einer Breite von so und so und deswegen rendere ich folgende CSS Regeln auf das Element.” Und das führt natürlich dazu, dass man sehr schöne Webseiten bauen kann, die inhaltlich komplett anders repräsentiert sind, wenn sie auf einem kleinen Device, wie einem Handy angezeigt werden, als auf einem Device, was einen 27 Zoll Monitor mitbringt.

Stefan Tilkov: Und wie mach ich das mit CSS, Roman?

Roman Stranghöner: Also im Wesentlichen baut Responsive Web Design auf drei Dingen auf. Das erste ist im Prinzip, dass ich meine Elemente so auslege, dass sie quasi immer 100 Prozent der Breite ihres Containers haben. Das sorgt dafür, dass man ich sie tendenziell in jeden Container reinschmeißen kann und der Container sorgt im Prinzip da dafür, dass dieses Ding die entsprechende Größe hat. Und das zeigt sich z.B. ganz nett, wenn man diese Responsive-Websites im dem Browser zusammenschiebt, dann verändert sich in der Regel der Container in seiner Breite, weil er halt prozentual festgelegt wird auf 100 Prozent von wiederrum seinem Container und dadurch wird alles so halbwegs schön und fluid quasi zusammengeschoben. Das war früher irgenwie schon mal in – ich weiß garnicht in welchem Jahrzehnt – aber das sah halt alles relativ fürchterlich aus, weil alles im Prinzip auf 100 Prozent war und ab einer gewissen Breite ist das halt nicht mehr leserlich, besonders für Texte. Also gibt es die zweite CSS-Komponente die man benutzen kann, um das ganze ein bisschen einzudämmen, das sind Media-Querys, damit kann ich im Prinzip über bestimmte Ober- und Untergrenzen festlegen, wie etwas auszusehen hat. Und ich kann darüber zum Beispiel steuern, dass ich ab bestimmten Grenzen, wie – keine Ahnung – 480px in der Breite, so die typische iPhone-Breite, kann ich z.B. sagen, dass sich bestimmte Container anders anordnen soll.

Falk Hoppe: Oder verschwinden sollen.

Roman Stranghöner: Oder verschwinden sollen, genau. Und je breiter ich werde, ich kann halt für belibiege, sogenannte Breakpoints – das sind diese Punkte, wo ich im Prinzip definiere, wann mein Content irgendwie umbricht oder meine Elemente und sich anders verhalten sollen – kann ich darüber steuern, dass die Anwendung vernünftig aussieht und z.B. nicht so was eintritt wie, wenn ich meine Webseite auf einem 27 Zoll Monitor aufmache, dass dann im Prinzip der Content auf 100 Prozent der Breite hängt, sondern, da hab ich dann im Idealfall durch ein Grid gesteuert nur noch eine bestimmte Breite, in der der Content quasi dargestellt werden soll und wenn ich daran rumziehe, dann ändert sich diese Breite automatisch.

Stefan Tilkov: Und das dritte? Du sagtest was über drei Dinge.

Roman Stranghöner: Genau, dazu gehört dann auch, dass sich so was wie Images und generell Objekte, die ich embedde in meiner HTML-Seite – also das können sowohl Bilder als auch Videos als auch irgendwelche anderen Dinge sein, die quasi neben dem Text, neben dem eigentlichen Text in meiner Webseite hängen – , dass die natürlich auch das selbe Verhalten haben. Und das erreicht man indem man im Prinzip auf all diese Elemente das so genannte max-width Propertie auf 100 Prozent setzt und dann sorgt das dafür, das im Prinzip auch alles andere quasi mit skaliert.

Stefan Tilkov: Das ist immer so ein Argument, dass ich bei Kunden immer bringe, dass das, was man damit tun kann zwar eine gewisse Kompetenz erfordert – die ich zum Beispiel nicht habe, aber dafür gibt es ja andere Leute wie euch, die das tun – der Effekt ist aber mit fast nichts anderem so zu erreichen, also mit welcher anderen Technologie hat man diese Möglichkeit auf beliebigen Displays nicht nur einfach in der Größe zu skalieren, sondern auch mit dem Umbruch, mit den eingeblendeten, ausgeblendeten Dingen, mit der Schriftgröße, mit Änderungen von zentriert auf linkdbündig und oben, das ist einfach eine unglaublich mächtige Technologie.

Falk Hoppe: Ja, also im Idealfall, das sieht man z.B. bei der App Forecast.io – das ist so eine Webseite, die einen Wetterdienst anbietet – und die das ja so gemacht haben, dass die halt auch so eine installable App auf dem iPhone anbieten. Man kann quasi deren Webseite nehmen und die über den Homescreen als App hinzufügen und man auf einmal eine App auf dem iPhone hat. Also man kann die quasi installieren – also das ist jetzt natürlich irgendwie iPhone-spezifisch.

Stefan Tilkov: Ich glaube, das geht auf Android auch.

Falk Hoppe: Geht auf Android auch, stimmt. Aber man bekommt eine Webseite die sieht auf der App auch wirklich ganz anders aus. Die sieht halt aus wie eine App und im Browser sieht die halt aus wie eine Browserwebseite, und das ist halt fantastisch. Also ich kann ein bisschen mit CSS tun und schon hab ich quasi eine iOS App da liegen oder eine Android App. Das find ich schon sehr sehr ordentlich.

Roman Stranghöner: Wobei ein bisschen auch übertrieben ist. Dieses ganze Handling von Mediaquerys und Breakpoints setzen, das ist schon relativ aufwendig bis – man sollte sich schon sehr viele Gedanken darüber machen, wie man diese Dinger setzt. Also man sollte zum Beispiel eigentlich nicht dazu übergehen diese Breakpoints anhand von Device-Breiten, also Pixelbreiten von Device-Displays zu setzten, sondern eigentlich sollte man das so handeln, dass im Prinzip der Content entscheidet, wann etwas umbricht. Also man fängt eigentlich damit an erst mal das kleinst mögliche Device zu unterstützen, auf dem die Webseite angezeigt wird und auf Basis dieses Minimal-Styles fang ich dann an mit Mediaqueries obendrauf zu legen, im Sinne von Progressive Enhancement. Also ich schreibe dann im Prinzip Mediaqueries, die dann anfangen, sobald ich den Platz hab, die Breite der Container entsprechend auf diese Breite anzupassen und da setze ich diese Breakpoints auch so, wie es mir der Content erlaubt. Also wenn ich sehe, dass mein Content ab einer bestimmten Breite irgendwie blöd aussieht, dann setze ich da den Breaktpoint und nicht weil das iPhone bei 480px in der Breite hing.

Falk Hoppe: Das führt halt auch dazu, dass man gar nicht alle fünftausend verschiedenen Device-Breiten sich anschauen muss, sondern es funktioniert auf dem einen Ding einfach, weil der Content dafür ok aussieht.

Stefan Tilkov: Und man kann es auch auf dem großen Bildschirm ausprobieren, indem man einfach das Browser-Fenster kleiner macht.

Roman Stranghöner: Genau, das ist genau der Punkt, weshalb man diese Fluid-Geschichte in die Container einbauen muss, weil die nämlich im Prinzip die gesamte Strecke von einem Breakpoint zum anderen abfackeln. Das ist völlig egal, ob da jetzt zwischen noch irgendwie ein iPhone und ein iPad oder sonst irgendwas liegen. Dadurch, dass der Container im Prinzip prozentual in seiner Breite ist, wird das genauso, wie wenn ich den Browser zusammen schiebe, schön fluid abgedeckt und genau deshalb eben nicht beliebig viele Devices unterstützen, sondern das kriege ich geschenkt, wenn ich das mache.

Stefan Tilkov: Gut, also der interessante Teil des Podcast ist mal kurz vorbei. Ich muss nämlich die Gelegenheit nutzen um noch eine Frage loszuwerden, die mich wahnsinnig macht, wenn ich mit CSS rumfummel. Was mich nämlich immer in den Wahnsinn treibt ist diese verfluchte Positionierung. Also da gibt es irgendwie diese floats mit links, recht – ich weiß nie so genau, was die eigentlich tun. Ich fummel dann so lange damit rum, bis es dann so aussieht, wie ich es gerne hätte und dann floatet aber auch irgendwas, von dem ich nicht will, dass das floatet. Also schreibe ich da so ein
hin. Das tut das, aber das soll ich wohl irgendwie auch nicht benutzen, weil alle immer ganz allergisch reagieren, wenn ich das sage. Kann mir das jemand jetzt mal einfach ganz kurz und ganz bündig erklären, was ich da eigentlich tun müsste oder wie das funktioniert, dieses Sauzeug?

Falk Hoppe: Kurz und bündig kann ich versuchen. Also grundsätzlich ist es so, ob du floating left oder floating right schreibst, das hängt sehr davon ab, was du da tun möchtest, weil sich dann auch die Richtung deines HTML-Markups ändert, in welche Richtung was gerendert wird. Aber unabhängig davon ist zumindest diese Idee des br-Tags eine fuchtbare Idee. Ob es ein hr, br oder was auch immer ist, ist egal. Die Frage ist, wir wollen eigentlich, wir haben jetzt irgendwie dafür gesorgt, dass unser CSS unabhängig bzw. das unsere Darstellung unabhängig vom HTML-Markup ist, was wir wollen. Und jetzt gehen wir hin und bauen diesen Markup-Hack ein, um unser Styling zu reparieren. Das ist ja irgendwie furchtbar. Und was ich halt immer propagiere ist, dass wenn wir sowas haben, wie floatende Elemente. Also wir haben irgendwie sowas wie eine Bildergalerie, die verschiedene Bilder enthält, die irgendwie floaten sollen. Das können auch ungerade Anzahlen sein, also ich kann auch die letzte Reihe kann nur drei Bilder enthalten, dann macht es meistens Sinn, das Ding in ein wrappendes Container-Element zu packen. Oder meistens ist es da eh drin. Also es gibt irgendeine Komponente.

Stefan Tilkov: Ein div meinst du damit?

Falk Hoppe: Genau. Ein div oder eine section oder was auch immer. Und der kann man jetzt im Prinzip eine sehr schöne Eigenschaft verpassen, die dafür sorgt, dass sich das fast wie eine Komponente auch anfühlt. Also eine seiteneffektfreie CSS-Komponente. Es gibt die overflow-Eigenschaft, die spezifizieren soll, wie mit Content umgegangen wird, der aus dem Container ausbricht, wie z.B. zu große Bilder. Also ich hätte ein 6000Pixel Image oder so, was passiert damit? Es wird abgeschnitten, könnte ich z.B. sagen. Das ist nämlich dieses overflow-hidden. Und overflow-hidden hat aber auch die schöne Funktion, dass es auch floats cleart. Also ich brauche kein hr, was irgendwie nachfolgend kommt um ein clear: both zu machen, sondern ich kann sagen overflow-hidden und schon werden alle floats, die daraus ausbrechen, abgeschnitten. D.h. auch ein p-Element, was z.B. dahinter kommt – also das klassische Text-Element, was Bilder umfließen soll, sie floaten – würde dann auch einfach unten drunter gerendert.

Stefan Tilkov: Verstehe, also mache ich mein Markup, ein ordentliches, dann habe ich dieses Problem gar nicht und brauch nicht mehr…

Falk Hoppe: Genau!

Stefan Tilkov: Ok, damit kann ich leben. Und das zweite, dieses position-Ding. Da gibt es – ich weiß nicht – so viele Werte für, die alle irgendwas bedeuten, was extrem unintuitiv ist. Kann man das auch ganz kurz erklären oder?

Falk Hoppe: Also ich finde das natürlich ganz einfach und intuitiv.

Stefan Tilkov: Jah, schon klar.

Falk Hoppe: Also ich fang einfach vorne an. Es gibt grundsätzlich vier Attribute für das position: das ist static, fixed, relative und absolute. Und es gibt immer noch dann dabei die Eigenschaften top/bottom oder left/right, um das ganze zu positionieren. static ist im Prinzip das, was alle Elemente erstmal von Natur aus haben. Also die verhalten sich einfach ganz normal, wie sich Browser-Elemente verhalten sollen. D.h., die sind im Prinzip hintereinander im Browser angeordnet und rendern sich so, wie sie sollen. Dann gibt es dieses fixed, das kennen wir eigentlich alle. Das sind immer diese Menüs, unter denen der Content so weg scrollt. Also die bleiben halt fix.

Stefan Tilkov: Ah, die sind wirklich im Browserfenster sozusagen an einer bestimmten Stelle.

Roman Stranghöner: Genau.

Falk Hoppe: Genau. Und dann gibt es relative. Relative ist erstmal klein und niedlich und fast sinnlos, es verschiebt nämlich den Inhalt zu seiner eigenen Position. D.h., wenn ich irgendwie möchte, dass ein Logo doch ein paar Pixel weiter oben schwebt, relativ zu einem Text, der irgendwie daneben ist, dann kann ich sagen, das Logo soll sich zu seiner eigenen Position ein bisschen nach oben verschieben. Und dann gibt es das absolute und das absolute ist das, worüber eigentlich fast jeder stolpert. Also das ist genau das, was eigentlich jeder meint, wenn er das position-Attribute meint. Damit möchte ich im Prinzip erreichen, dass meine Komponente an eine gewissen Stelle positioniert wird. Nehmen wir jetzt nochmal dieses Post-Beispiel. Nehmen wir mal den Post, der klassischerweise oben links so einen Information-Bubble oder einen Datum oder sowas hat. Dann möchte ich, dass der immer fünf Pixel links oder nach oben außerhalb meines Blogposts schwebt. Das kann ich – grundsätzlich hätte ich jetzt so eine Struktur, wie ein h1 und darunter halt dieses div oder ein b, p oder sonst was mit dem Information-Bubble. Den kann ich jetzt ja erstmal mit float sowieso nicht dahin bringen und mit einem position:relative auch nicht so richtig, weil ich ja nicht weiß, z.B. wie lang die Überschrift wird. Also das Ding ist verschieden hoch.

Stefan Tilkov: Ja, ja, verstehe.

Falk Hoppe: Jetzt kommt position:absolute rein. Absolute bedeutet, ich bin absolute positioniert zum zuletzt positionierten Element.

Stefan Tilkov: Moment, absolut zum? Du meinst absolut-relativ?

Falk Hoppe: Ja, genau. Absolut-relativ. Das zuletzt positionierte Element ist irgendein Element, das nicht position:static hat. Äh ja, static. Jetzt komme ich schon selbst durcheinander. Static hat erstmal jedes Element, außer so ein bisschen der Body. Der Body ist so ein bisschen implizit ein relativ-Element. D.h., diese absolute Positionierung unsere Info-Bubbles würde sich am Body alignen. D.h., wenn wir den jetzt irgendwie sowas wie „top: 5px, left: 5px” beschreiben würde, würde der irgendwo oben links in der Browserecke kleben. Jetzt kann ich dann zum nächsten Trick greifen und sagen: Ok, diese Post-Klasse, die um meinen Blog-Post herum schwebt, der könnte ich jetzt eine relative Positionierung verpassen.

Stefan Tilkov: Relativ zu sich selbst. Relativ, 0 0. Ah, ok. Jetzt habe ich es sogar verstanden.

Falk Hoppe: Genau. Die ist nämlich gar nicht zu sich verschoben.

Roman Stranghöner: Also man verschiebt an sich den Ursprungspunkt, an dem man dieses mit absolute positioniert. Also von dem…

Stefan Tilkov: Ganz klar: absolut-relativ. Sehr logisch. Relativ absolut.

Falk Hoppe: Absolut-relativ, genau. Also es ist auch – eigentlich ist es total einfach. Und schwupps passiert es halt im Prinzip – also sobald man diese relative-Klasse hinzufügt wird auf einmal dieses „top: 5 5” sozusagen bzw. dieses „absolute: 5 5” verschobene Element zum Blogpost verschoben. Total einfach.

Stefan Tilkov: Habe ich es endlich auch verstanden. Gut, wir sind wegen meiner persönlichen Interessen über unsere normale Zeit raus gelaufen, deswegen würde ich gerne hier Schluss machen. Wir machen eine zweite Episode zum Thema Präprozessoren, weil das einiges ist, worüber wir da glaube ich reden können. Habt ihr jetzt noch ein abschließendes Statement zu CSS und Co.

Falk Hoppe: Also ich würde behaupten, ja. Für mich gehört CSS definitiv – also man muss das können. Also zumindest, wenn man Web-Entwickler ist. Es ist absolutes Basis-Werkzeug. Ich kann verstehen, dass gewisse Leute das nicht können, das ist aus diesen Gründen, die oben genannt wurden, total verständlich, aber es ist meiner Meinung nach falsch. Sollte sich jeder mal die Zeit nehmen. Und ich glaube, man braucht auch nicht viel Zeit.

Stefan Tilkov: Unterschreibst du?

Roman Stranghöner: Unterschreibe ich. Ich hab dem auch nichts weiter hinzuzufügen.

Falk Hoppe: Alles klar.

Stefan Tilkov: Dann danke ich euch für die äußerst lehrreichen Informationen, ich habe eine Menge gelernt. Finde ich gut, machen wir jetzt häufiger.

Falk Hoppe: Sehr gerne.

Roman Stranghöner: Sehr gerne.

Stefan Tilkov: Ich danke euch, tschüss an die Zuhörer. Bis bald.

Roman Stranghöner: Ciao.

Falk Hoppe: Ciao.