Transkript

CSS-Architektur

Architekturaspekte von Cascading Style Sheets

Falk Hoppe und Roman Stranghöner sprechen mit Stefan Tilkov ĂŒber die Architekturaspekte von CSS.

ZurĂŒck zur Episode

Transkript

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.