Transkript
Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcast. Heute habe ich mir die Joy eingeladen. Hallo, Joy!
Joy Heron: Hi!
Lucas Dohmen: Wir werden heute über „Intrinsic Design“ sprechen. Bevor wir das machen, Joy, für die Leute, die dich länger nicht gehört haben: Wer bist du und was machst du bei INNOQ?
Joy Heron: Ich heiße Joy Heron, arbeite als Senior Consultant bei INNOQ und bin Fullstack-Entwickler.
Lucas Dohmen: Dein Fokus war immer schon irgendwie auf dem Web, aber du hast so eine ganz besondere Liebe für CSS, richtig?
Joy Heron: Ich liebe CSS wirklich. Ich sage immer, es gibt zwei Technologien, die ich liebe und das sind Clojure und CSS.
Lucas Dohmen: Fehlen da nicht Tabellen?
Joy Heron: Tabellen… Lieben? Ich weiß nicht.
Lucas Dohmen: (lacht)
Lucas Dohmen: Ich habe dieses „Tabellen-Ding“ mal gemacht. Sie sind halt notwendig. Und ich mag eben auch HTML.
Lucas Dohmen: Okay, aber deine zwei Lieblingstechnologien sind CSS und Clojure?
Joy Heron: Genau, aber ich liebe das Web im Allgemeinen.
Lucas Dohmen: Okay, gut! Heute wollen wir uns ein bisschen auf deine CSS-Liebe konzentrieren und deswegen haben wir uns als Thema Intrinsic Design herausgesucht. Ich glaube, bevor man über Intrinsic Design sprechen kann, muss man vielleicht erst einmal über Responsive Design sprechen. Magst du ganz kurz erklären: Was ist Responsive Design und wieso brauchen wir das?
Joy Heron: Die beiden sind sehr verwandt miteinander. Die Idee ist die von Mobile First. Am Anfang der Entwicklung vom Web hat man sich einfach gesagt, dass man sich eine Ansicht für seine Webseite entwickelt und davon ausgeht, dass sie 900px breit ist und sich das nie ändern wird. Dann hat man festgestellt, als man es so gemacht hat, dass Menschen Webseiten gerne auf kleineren Geräten aufmachen und dass sie die Webseiten auch gerne auf größeren Geräten aufmachen. Als es vor allem sehr üblich geworden ist, dass man iPhones oder Smartphones hat, wo man gerne das ganze Web auf dem Handy bedienen möchte, wurde es wichtig, dass wir die Seiten so gestalten, dass sie nicht nur auf größeren Bildschirmen, sondern auch auf kleineren Bildschirmen funktionieren. Um das zu machen, ist es ist schwierig, wenn man mit einem großen Layout, also mit dem Großen anfängt und versucht es dann so umzubiegen, dass es auf kleinere Geräte passt. Die Idee von Responsive Design und Mobile First-Entwicklung ist, dass man mit der mobilen Ansicht anfängt. Wie würde es auf einem Handy aussehen? Und wenn man dann den Bildschirm größer zieht, oder auf unterschiedlichen Devices unterwegs ist, dann sieht die Seite irgendwie anders aus. Man kann die Elemente anders formatieren oder andere Elemente ein- und ausblenden oder die Inhalte mit einem anderen Layout formatieren. Das ist die Idee von Responsive Design.
Lucas Dohmen: Das heißt, es ist eigentlich eher eine Philosophie als eine bestimmte Entwicklungsmethode?
Joy Heron: Ja, auf jeden Fall. Das würde ich so sagen. Die Idee ist, dass man mit dem kleinen Bildschirm anfängt und dann versucht, die Elemente so auf größere umzugestalten, dass sie eben anders aussehen.
Lucas Dohmen: Diesen Weg gibt es ja jetzt schon seit einigen Jahren. Ich glaube, das Buch, in dem es zum ersten Mal beschrieben wurde, ist jetzt bestimmt schon zehn Jahre alt. Was macht jetzt Intrinsic Design aus, dass es etwas Neues ist? Wie unterscheidet es sich von den existierenden Ideen?
Joy Heron: Der Begriff Intrinsic Design kommt von Jen Simmons. Ich glaube, es gibt einige Videos auf Youtube zu dem Thema, aber ich bin mir nicht mehr sicher. Ich suche sie mal raus. Sie macht viel auf Youtube für Mozilla und hat damals einen Podcast gehabt und macht Talks zu dem Thema. Ich glaube, sie hat den Begriff erfunden, weil sie geschaut hat: Wie haben wir bis jetzt immer Responsive Design gemacht und wie machen wir es heute? Welche Unterschiede gibt es? Ich würde sagen, dass Intrinsic Design eine Weiterenwicklung von Responsive Design ist. Die Denkweise ist leicht unterschiedlich. Responsive Design, wie es am Anfang umgesetzt wurde, war, dass man z.B. eine Layoutansicht für ein Mobile-Device entwickelt hat. Man hat dafür wirklich drei bis vier Screens mit einem Designer zusammen entwickelt und gesagt: Auf Mobile sollen die Inhalte so aussehen, auf einem Tablet soll es so aussehen und auf einem großen Bildschirm soll es so aussehen.
Lucas Dohmen: Man hat also vier Designs für eine nicht unbedingt exakte Breite, aber für eine Range von Breiten.
Joy Heron: Genau. Dann hat man in CSS Breakpoints, media queries heißen sie in CSS. Man kann CSS-Regeln definieren, um bestimmte Regeln zu definieren, die nur ab einer bestimmten Seitengröße gelten oder wenn es kleiner ist als eine bestimmte Seitengröße. Das ist die Idee. Man hat drei oder vier unterschiedliche Layouts und man wechselt zwischen den Layouts mittels Breakpoints oder mittels media queries. Etwas anderes, was häufig passiert und durch die Idee von Responsive Design bei der Umsetzung bedingt ist, ist, dass HTML-Schnipsel dupliziert worden sind innherhalb der Seite. Vor allem die Navbar ist ein super Beispiel dafür. Auf Mobile möchte man, dass die Navbar ein komplett anderes Verhalten als auf einem großen Bildschirm hat. Deswegen hat man tatsächlich im HTML zwei unterschiedliche Navbar-Elemente und mit CSS kann man das eine ab einer bestimmten Seitenbreite einblenden. Oder eben anders herum. Anhand der Breite der Seite blendet man die Navbar ein, die man an der Stelle sehen möchte. So wurde es häufig für Responsive Design umgesetzt.
Lucas Dohmen: Was im Kundenprojekt bei mir auch die Erfahrung war, dass es beim Kunden so angekommen ist, dass man wirklich vier vollständig unabhängige Designs macht und dann nachher im Code merkt: Die Sachen haben wirklich überhaupt nichts mehr miteinander zu tun. Es ist dann super schwer es so umzusetzen, dass man nicht vier verschiedene HTML-Skelette ausliefern muss, die dann von CSS ein- und ausgeschaltet werden. Auch rein von der Wahrnehmung wie es funktioniert, ist es im Kopf der Leute so, dass es vier unterschiedliche Sachen sind. Da muss man viel mehr Denkarbeit reinstecken, damit es nachher auch wirklich funktioniert als CSS und HTML.
Joy Heron: Ja, genau.
Lucas Dohmen: Irgendwie erscheint es mir so, dass das jetzt die einzige Möglichkeit ist, die man so hat. Man muss irgendwie die Designs festlegen. Wie macht das jetzt Intrinsic Design anders, um das Problem zu lösen?
Joy Heron: Meiner Meinung nach – und das ist wirklich meine Meinung, also falls ich da Unrecht habe, könnt ihr mich anschreien und lieber nicht andere Menschen, die irgendetwas über Intrinsic Design gesagt haben. Für mich ist eine Seite mit Intrinsic Design umgesetzt worden, wenn es in der CSS-Datei keine media queries gibt, um das Layout anzupassen. Also ein reines Intrinsic Design. Ich werde am Ende vielleicht noch erwähnen, wo ich Ausanhmen sehe, aber das ist der Anfang. Wo ich sage: Ich möchte wirklich so wenig media queries schreiben wie möglich. Das Beispiel, dass ich sehr gerne mag, ist die Navbar. Man möchte mit HTML die Struktur der Navbar bestimmen, also funktional. Dafür gibt es das nav-HTML-Element und darin sollen Links oder eine Liste von Links enthalten sein. Dann möchte man dieses HTML so mit CSS stylen, dass es sich selbst so an die Bildschirmbreite anpasst, dass es richtig aussieht. Ganz ohne media queries kann man an manchen Stellen zwar nicht auskommen, aber das ist die Idee von Intrinsic Design. Man möchte, dass sich die Elemente auf der Webpage selbst anpassen anhand der Größe, die sie haben.
Lucas Dohmen: Das klingt jetzt erst einmal etwas abstrakt, finde ich. Grundsätzlich finde ich es nachvollziehbar, aber um es mir etwas konkreter vorzustellen, magst du mal eine Technologie nennen, mit der man Intrinsic Design gut umsetzen kann?
Joy Heron: Ja, CSS. (lacht)
Lucas Dohmen: (lacht)
Joy Heron: Von Anfang an, als das Web angefangen hat, war HTML immer sehr inhaltsbezogen. Es gibt diese HTML-Elemente, die haben einen Inhalt und in dem normalen HTML-Layout – und es gab nicht so viel Layout – war es so, dass man einfach Blöcke von Inhalten untereinadner gereiht hat. So hat es funktioniert. Es gab am Anfang keine CSS-Layoutmethoden in irgendeiner Form. Es gab dieses display: block und display: inline, was man vielleicht kennt, wenn man CSS macht. Mehr gab es damals nicht. Man hat andere Dinge verwendet, um das Layout hinzubekommen: Tabellen, vor einer langen Zeit. Dann gab es „Floats“, wo man vesucht hat, so ein Gitter mit Floats zu machen. Das war vor meiner Zeit und ich kenne es nur theoretisch. Als ich mit der Webentwicklung angefangen habe, gab es zum Glück schon „Flexbox“. Flexbox war eine neue Idee. Man wusste, dass man die Inhaltsblöcke normalerweise untereinander mit display: block anzeigt. Jetzt kann man zum Beispiel innerhalb von einer Section oder einem Container sagen: Ich möchte, dass alle meine Inhalte irgendwie nebeneiander angezeigt werden. Das kann man mit Flexbox machen. Dann kann man auf dem Parent-Element oder dem Container sagen display: flex. Das war eine neue display-Property. Was jetzt passiert, ist, dass der Browser weiß, dass es so ein Flex-Element ist. Bei allen unterschiedlichen Blöcken, die hier innerhalb des Flex-Containers landen, versucht der Browser sie nebeneinander zu platzieren. Dabei achtet er darauf, dass sie so viel Platz einnehmen, wie sie brauchen. Der Flexbox-Algorithmus scheint dabei Blöcke, die mehr Inhalt haben als andere, breiter anzuzeigen. Soweit diese Idee. Dann kann man noch für diesen Container flex-wrap einstellen. Im Regelfall möchte man, dass sie nebeneinander platziert werden, aber wenn sie nicht nebeneinander passen, dann können sie mit flex-wrap untereinander gereiht werden. Sodass sie dann untereinander sind.
Lucas Dohmen: Das ist aber eine Eigengeschaft vom Container. Also der Browser entscheidet, wo er dann den Zeilenumbruch macht. Man muss es gar nicht selber sagen, sondern das macht der Browser.
Joy Heron: Genau. Die Elemente haben auch Kontrolle, wenn man die Property flex-basis oder flex-grow anpasst. Es gibt so ein paar Dinge, mit denen ein Element sagen kann, dass es doppelt so groß sein will wie ein anderes. Der Browser wird versuchen, es zu berücksichtigen. Oder flex-basis drückt zum Beispiel aus, dass ein Element 50 rem oder 10 rem breit sein will, und wenn es nicht klappt, dann: Quetsch mich! So hat man etwas mehr Kontrolle. Wenn wir zurück zu der Navbar kommen und uns auf einer Desktopansicht vorstellen, dass die Links für die Navbar nebeneinander platziert werden, dann kann man sagen, dass die Navbar so ein Flexcontainer sein soll und die Links in dieser Navbar werden einfach nebeneinander platziert. Dafür muss man nur das display: flex auf dem Container machen. Wenn ich es aber kleiner ziehe – da gibt es Tricksereien, die man machen kann. „every-layout.dev“ ist da so eine Webseite, wo man sich diese CSS-Patterns ansehen kann, um so etwas hinzubekommen. Zum Beispiel wie Elemente, die normalerweise nebeneinander platziert werden, auf einem kleineren Bildschirm untereinander platziert werden können.
Lucas Dohmen: Das heißt also, ich habe die Möglichkeit, auf dem Container ein bisschen mehr zu beschreiben, wie die Inhalte angeordnet werden, aber ohne ganz exakt zu sagen, wie es funktioniert. Eher so eine lose Beschreibung.
Joy Heron: Genau. Das geht zurück auf das Wort Intrinsic: Intrinsisch. Per Default sind die Inhalte im Web, wenn man zum Beispiel einen Textabschnitt hat und der zum Beispiel in einem p-Element drin ist, dann hat das p-Element eine bestimmte Breite. Ich glaube, per Default hat es display: block, also 100% Breite. Wenn der Text aber nicht in diese 100% Breite passt, dann wird er gewrappt, sodass er auf die nächste Zeile verschoben wird. Wenn man den Viewport kleiner zieht, wird der Text gewrappt – das ist schon das richtige deutsche Wort oder?
Lucas Dohmen: Es gibt kein deutsches, glaube ich, aber ja. Oder „umbricht“.
Joy Heron: Er bricht um, genau! Der Text bricht dann um, wenn es nicht genug Platz gibt. So wie es von Anfang an war, mit solchen Textinhalten. Wir machen es jetzt mit Intrinsic Design und das ist genau das, was man grundsätzlich haben will: Man will, dass Inhalte, wenn sie genug Platz haben, so viel Platz einnehmen können, wie sie wollen. Aber wenn es nicht genug Platz gibt, dass man dann auch sagen kann, was passieren soll. Soll eine horizontale Scrollbar eingeblendet werden? Was vielleicht für eine Tabelle keine so schlechte Idee ist. Oder sollen die Elemente eine Flexbox sein und die Inhalte, wenn es nicht genug Platz gibt, untereinander anstatt nebeneinander angezeigt werden?
Lucas Dohmen: Also quasi: Man beschreibt einfach das Verhalten, das passiert, wenn man weniger Platz hätte?
Joy Heron: Genau.
Lucas Dohmen: Ob es dann zusammengedrückt wird oder ob es umgebrochen wird oder ob gescrollt wird und das beschreibt man einfach?
Joy Heron: Ja. Und ich persönlich mag auch diese Idee: Wir wollen nicht gegen das Web oder gegen HTML kämpfen. Also ich persönlich mag, wenn es keine Überlappungen gibt auf meiner Webseite. Das heißt, ich persönlich mag Drop-downs nicht. Also es gibt keinen Grund dafür, es ist eine Geschmackssache an der Stelle. Es gibt wirklich keinen Grund dafür, bitte sag nicht, Joy hat gesagt: Niemals Drop-downs verwenden. Das meine ich nicht. Aber ich persönlich, wenn ich so eine Seite sehe, bei der, wenn ich auf etwas klicke und anstatt dass so ein div in der Mitte meiner Seite eingeblendet wird, klappt stattdessen die ganze Seite auf – also die Inhalte waren schon im Float drin, aber die waren noch versteckt. Und die ganze Seite breitet sich dann aus, wenn ich dieses Ding ausklappe oder zuklappe, dann finde ich das persönlich cool. Das gefällt mir. Und das ist so diese Idee, dass die Inhalte gequetscht werden können. Ich mag auch zum Beispiel: Wir – du und ich – hatten zusammen einen Workshop vorbereitet und wir haben so eine Beispielanwendung gemacht und da haben wir es so gemacht, dass die Navbar auf größeren Bildschirmen links war. Und beim Hovern ist die Navbar so „rausgerutscht“ von der linken Seite. Du hast die Icons links gesehen und wenn du darauf gehovert hast, dann wurde die Navbar breiter und du konntest dann die Texte von den Elementen sehen. Und dabei habe ich es so umgesetzt, wenn das passiert ist, wurden die Inhalte rechts von dem Browser gequetscht. Dass nicht diese Navbar so rausgerutscht ist und mit den Inhalten überlappt hat, sondern die rechte Spalte wurde dann von dem Browser gequetscht. Das finde ich persönlich irgendwie spannend und da finde ich: Kämpfe nicht gegen das Web. Wir wissen, all diese Dinge sind nur Blöcke mit Text darin, dass wir keine Desktop-App, so eine native App bauen, bei der wir Drop-downs und was weiß ich haben, sondern dass sie eigentlich alle nur Blöcke mit Text sind und wenn ich irgendwie die Breite anpassen muss, dass ich das einfach machen kann.
Lucas Dohmen: Genau. Ich glaube, wir sollten auf jeden Fall diese Anwendung mal verlinken in den Shownotes, weil solche Sachen vielleicht ein bisschen einfacher zu sehen sind, wenn man das mal anklicken kann.
Joy Heron: Ja, wahrscheinlich.
Lucas Dohmen: Aber grundsätzlich: Das Interessante daran ist ja auch, dass sich diese Navi dann auch auf einem ganz kleinen Viewport noch einmal ganz anders verhält.
Joy Heron: Die Navbar?
Lucas Dohmen: Ja, in dem Beispiel.
Joy Heron: Ja, genau. Und das ist genau die Stelle, an der ich sage… Wie kann ich das sagen? Also zur Zeit gibt es ohne media queries keinen Weg zu sagen, auf kleineren Bilschirmen… In dem Fall, bei dem, was wir gemacht haben, da sollte die Navbar auf Mobile unten sein, ein Sticky sein, damit du daran näher mit dem Daumen in Kontakt kommen kannst, also treffen kannst mit dem Daumen, deswegen unten, das Menü. Und um das dann nachher umzuswitchen, damit es auch rechts ausgerichtet ist, dafür braucht man heute eine media query. Aber genau dafür sind media queries auch gemacht, meiner Meinung nach. Also media queries, das heißt, dass ich anhand von der Viewport irgendwelche Regeln definieren kann, also dass sich das anpasst.
Lucas Dohmen: Genau. Aber würdest du sagen, dass das dann an der Stelle eigentlich kein Intrinsic Design mehr ist, weil man dann ja quasi schon mehr Kontrolle übernimmt, als man das im Rest tut von dem Intrinsic Design?
Joy Heron: Ich finde, das ist ein Beispiel, wo media queries genau richtig eingesetzt worden sind. Aber ich bin mir nicht sicher. Ich glaube, wenn man Intrinsic Design so definiert, dass ich halt eben diese zweite Navbar nicht brauche, also dass ich nicht zwei unterschiedliche Navbars auf meiner Seite habe, sondern dass ich die einfach umstyle, dann denke ich schon, dass das in die Richtung geht, sage ich mal so. Genau.
Lucas Dohmen: Ja, ich meine, es heißt ja auch nicht unbedingt, wenn man Intrinsic Design macht, dass man dann quasi davon nie eine Ausnahme machen kann.
Joy Heron: Ja, genau.
Lucas Dohmen: Es kann ja durchaus sein, dass man an so einer Stelle sagt, an der Stelle ergibt es Sinn, diese Regel zu brechen und das anders zu machen.
Joy Heron: Und deswegen: Für mich ist eben diese Denkweise das, was wichtig ist. Also grundsätzlich möchte ich meine Seite und meine Inhalte so gestalten, dass sie sich selber anhand von der Größe, die sie zur Verfügung haben, ausrichten lassen. Aber man muss auch wissen, wann es Ausnahmen dazu gibt. Wann brauche ich eben eine media query. Und dann, wenn man eine media query braucht, dann finde ich das eigentlich nicht schlecht, eine zu verwenden. Und genau für den äußeren Rahmen von der Anwendung, wenn ich eben die Positionen von der Navbar switchen muss, genau dafür wird so etwas gebraucht. Also du könntest die Navbar auch oben haben, wie es ja üblich ist, also ein übliches Pattern im Web. Und dann könntest du da, glaube ich, ziemlich gut herumkommen, das wäre theoretisch möglich.
Lucas Dohmen: Aber das heißt ja, an der Stelle ist es eigentlich auch so, dass man quasi versucht, so ein bisschen das Pattern, das man aus iPhone-Apps oder aus Android-Apps kennt, dass unten eine Navigationsleiste ist, weil da der Daumen ist… Das ist dann ja auch ein Punkt, wo man über das Gerät oder die Bedienungsart und -weise redet. Das heißt, da ist ja vielleicht auch ein guter Punkt zu sagen, das ist kein intrinsisches Design, sondern hier müssen wir ein bisschen mehr auch auf das bestimmte Device eingehen, weil man es anders verwendet.
Joy Heron: Und wie gesagt, ich glaube, das ist genau das, wofür media queries gedacht waren und da ich eben dieses HTML nicht dupliziere, sondern es anders ausrichte, finde ich das immer noch ein gutes Pattern. Also ich glaube nicht, dass die Idee von Intrinsic Design war, dass man einfach Pragmatismus aus dem Fenster wirft. Das glaube ich nicht. Und ich glaube, wir sind noch in der Entwicklung. Also was ich noch nicht angesprochen habe, ist CSS Grid. Und CSS Grid, das kam nach Flexbox, das kann man jetzt heutzutage verwenden, es ist großartig. Ich kann zum Beispiel mit CSS Grid sagen: Auf einem Container, display: grid. Also nicht display: flex, wir hatten Flexbox davor, aber display: grid. Und dann kann so mit grid-template-areas oder mit grid-template-rows oder -comlumns, auf jeden Fall kann man ein Gitter definieren. Und das Coole an CSS Grid ist eben auch diese Idee, dass wenn ich mein Grid definiere, der Default ist, wenn ich die Elemente dann innerhalb von diesem Container habe, dass sie einfach platziert werden in meinem Grid, in meinem Gitter. Und da ist es so, zum Beispiel wenn ich ein Gitter machen würde mit drei Spalten: Der Normalfall ist, dass jedes Element, das dann nachher in dieses Gitter kommt, eine Spalte breit ist. Dann würden die drei Elemente, die ich da rein mache, einfach nebeneinander platziert werden. Und dann, wenn es eben nicht genug Platz gibt, dann würde das anfangen, die zweite Reihe zu befüllen. Man kann sehr viele coole Dinge damit machen, aber was ich wirklich so elegant daran finde, ist, dass wir für die Elemente selber nichts mehr schreiben müssen: Der Default-Fall ist, dass das eine Spalte einnimmt. Und ich kann das bestimmen, zum Beispiel kann ich sagen grid-column: span 2 und dann würde mein Element zwei Spalten einnehmen anstatt einer. Und das funktioniert so. Aber wenn jemand so Bootstrap mal gekannt hat oder so, diese Grid-Frameworks von unterschiedlichen CSS-Frameworks, da war es immer so, dass du wirklich irgendwie die Grid-Klasse drum herum machen musstest und dann musstest du für jedes Element sagen, wieviele Spalten…
Lucas Dohmen: Wie breit bist du.
Joy Heron: Also bei Bootstrap sind zum Beispiel zwölf Spalten in meinem Gitter und ich muss bei jedem Element sagen, wieviele Spalten soll es an der Stelle einnehmen. Und das ist einfach sehr viel Code, den ich schreiben muss. Und das andere ist bei CSS-Grid, du brauchst nicht mehr so diese Verschachtelung von HTML-Elementen. Sondern es ist wirklich so, wenn ich ein Element habe, zum Beispiel möchte ich das Layout für meine Seite bestimmen, und ich sage display: grid… Das ist, was ich in diesem Beispiel gemacht habe. Ich habe mit grid-template-areas wirklich gesagt, wo ich möchte, dass die Inhalte auf Mobile angezeigt werden. Und dann kann ich den Elementen sagen, du gehörst zu dieser Area, dieser Grid-Area Navbar oder so. Dieser Grid-Area Content. Du gehörst dazu. Und auf größeren Bildschirmen kannst du dann sagen, okay, ich ändere mal das Grid, dass die Areas an unterschiedlichen Stellen sind. Und das Layout wird dann angepasst.
Lucas Dohmen: Ja.
Joy Heron: Und was es auch gibt bei CSS Grid und das ist auch so ein bisschen dieses Intrinsic Design: Da, wo ich wirklich sagen kann, ich möchte ein, ich glaube, es heißt Implicit Grid definieren für meine Elemente. Ich möchte eigentlich, dass meine Elemente immer so zwischen 15 rem und – keine Ahnung. Also du kannst sagen, dass meine Spalten ungefähr so breit sind. Und dann kannst du auch mit einem Implicit Grid sagen, ich möchte einfach, dass dieses Gitter aufgebaut wird, aber so viele Spalten auf meinen Bildschirm passen, wie passen. Also dass, wenn es nicht mehr genug Platz gibt für drei Spalten, dass ich dann plötzlich nur zwei Spalten habe und die Elemente werden entsprechend angepasst.
Lucas Dohmen: Also ist es so, dass quasi das Grid selbst flexibel ist und sich auch noch einmal anpasst?
Joy Heron: Ja, genau.
Lucas Dohmen: Also anders als bei dem typischen Bootstrap-Grid, bei dem ich dann irgendwie sagen würde, auf Mobilgeräten hat dieses spezielle Element 12 Breite bei kleinem Bildschirm oder so etwas, wo man sehr, sehr viel mit media queries arbeiten muss?
Joy Heron: Ja, genau. Und das ist die Stelle, was ich sagen wollte, mit Grid, weil du eben Gitter definierst. Und wenn du explizit sagst, ich möchte drei Gitter haben, dann wird es dir ein Grid machen mit drei Gittern, egal wie groß die Bildschirmbreite ist. Und deswegen braucht man mit CSS Grid an einigen Stellen noch media queries, weil man manchmal eher die Kontrolle über das Gitter haben möchte, was völlig legitim ist. Dann möchte man sagen, auf Mobile gibt es nur eine Spalte und auf einem Desktop gibt es fünf, zum Beispiel. Und das ist völlig legitim und das kann ich sehr einfach mit media queries machen und dafür ist es gedacht. Aber so eine Sache ist, dass das noch auf den Viewport beschränḱt ist. Das gefällt mir daran nicht so. Weil eine Sache zum Beispiel ist – vielleicht kennen wir das aus der Mobile First-Entwicklung – dass wir auf Mobile einfach ganz viele Kästchen untereinander haben. Also wir haben keine Breite. Dann platzieren wir einfach alles eins nach dem anderen untereinander und wenn ich den Bildschirm größer mache, dann möchte ich das Layout anders machen. Aber es gibt als gutes Beispiel das Sidebar-Layout. Ich weiß nicht, wer das kennt, aber wenn ich das Fenster groß genug ziehe, werden meine zwei Blöcke, die vielleicht oben und unten waren, jetzt nebeneinander platziert und das obere ist eben meine kleine Sidebar. Und diese Sidebar wird nicht so breit, aber der Hauptinhaltsbereich wächst dann entsprechend und nimmt so viel Platz, wie er braucht. Das Ding ist, dass aber auf einigen Viewport-Größen dieser Hauptinhaltsbereich sehr schmal sein kann, auch wenn der Viewport so breit ist, dass, ja… Das ist halt schwierig zu erklären in einem Podcast. Es kann immer noch sehr schmal sein, auch wenn mein Viewport groß ist, das ist es.
Lucas Dohmen: Also auch wenn der Viewport breit ist, könnte es sein, dass einzelne Spalten dann trotzdem dünner sind?
Joy Heron: Genau. Und das ist da, wo es dann einfach schwierig ist, wenn ich sage, ich möchte Inhalt in diesem Hauptinhaltsbereich platzieren. Das ist da, wo ich sehr oft zur Flexbox greife, weil ich es da sehr einfach so bestimmen kann, dass die Inhalte sich anhand von der Größe anpassen. Denn da weiß ich, diese Komponente, die ich schreibe, dieses HTML-Element, das ich schreibe, das kann sich selber anpassen an die Größe. Dann ist es egal, wenn es in einem Hauptinhaltsbereich ist und dieser Hauptinhaltsbereich eben in einigen Fällen vielleicht ein bisschen schmal ist.
Lucas Dohmen: Okay. Heißt das, dass du die Flexbox eher auf einzelnen Elementen einsetzt und CSS Grid eher auf dem Gesamtlayout?
Joy Heron: Das mache ich sehr gerne, wenn ich die Gelegenheit habe. Und ich glaube, es gibt sehr viele Usecases. Zum Beispiel dieses Implicit Grid ist auch etwas, bei dem die sich selber an die Inhaltsgrößen anpassen. Ja, das würde ich so sagen. Es gibt natürlich Ausnahmefälle, bei denen man media queries macht. Aber genau dann, wenn die Inhalte selber, also da, wo ich das CSS schreibe – wenn ich nicht weiß, ob sie in einem Kontext eingesetzt werden, wo sie klein sind, auch wenn der Bildschirm breit ist, dann sind media queries ein ungeeignetes Mittel, um das Layout von dieser Komponente anzupassen.
Lucas Dohmen: Ja, verstehe.
Joy Heron: Aber ich habe noch ein bisschen Hoffnung. Also was Menschen sich wünschen seit sehr langem, das ist, dass man so etwas wie element queries oder container queries hat. Also wir haben media queries, die sich auf die Viewport-Größe beschränken. Ich würde mir wünschen, dass ich so eine element query habe, bei der ich sagen kann, dieses Element, möchte ich so umbiegen, wenn so viel Platz oder so wenig Platz vorhanden ist.
Lucas Dohmen: Also unabhängig davon, wie breit der Bildschirm ist, aber wieviel Platz das Element an sich bekommen hat, richtig?
Joy Heron: Genau. Aber das ist nur ein Traum. Da gibt es, glaube ich, Performance-Bedenken. Ich hoffe nur, dass es irgendwann kommt.
Lucas Dohmen: Ja. Ich finde, man wünscht sich das halt auch immer dann, wenn man ein wirklich wiederverwendbares Komponentending baut, das man dann manchmal vielleicht in einem Footer dranpackt, manchmal vielleicht irgendwo mittenrein, manchmal in den Header. Und da braucht es einfach verschieden viel Platz und dabei hilft einem der Viewport gar nicht, das zu entscheiden.
Joy Heron: Ja, genau. Aber es läuft in die richtige Richtung.
Lucas Dohmen: Cool. Ja, das war doch ein super Überblick, Joy.
Joy Heron: Ich würde noch eine Sache sagen als Ergänzung. Nicht als Ergänzung, eigentlich als Abschluss: Ich glaube, man sollte niemals Layout mit JavaSript machen.
Lucas Dohmen: Ja!
Joy Heron: Und der Grund ist nicht nur, dass CSS das einfach viel besser kann, denn das kann es, sondern es ist auch so eine Performance-Sache. Also wenn du jetzt irgendwie JavaSript-Layouting-Zeug machst – ich weiß jetzt nicht, warum man das heutzutage machen würde – aber wenn, ist es bestimmt nicht… Es muss irgendwie so einen Listener auf dem Window haben, wann Dinge sich anpassen, was weiß ich, und dann feuert es ganz viel Code und so, keine Ahnung, aber das ist wegen Performance… Also das andere, bei diesen CSS-Layout-Utilities, also Flexbox, Grid, diese Dinge, zu denen wurden sich sehr viele Gedanken und auch sehr viel Arbeit gemacht und es wurde sich sehr viel Zeit genommen, damit sie feststellen konnten, dass wie diese Dinge funktionieren, dass sie die Performance von dem Browser nicht zu sehr auslasten. Deswegen: Sie funktionieren super und wenn du Layout brauchst, bitte, bitte, bitte nimm CSS-Grid oder Flexbox oder so etwas und nicht irgendein JavaSript-Zeug.
Lucas Dohmen: Okay. Das war, glaube ich, ein gutes Schlussplädoyer. Alles klar. Genau, super. Dann danke ich dir für diesen tollen Überblick über Intrinsic Design, Flexbox und Grid, alles in Einem. Und den Hörerinnen und Hörern sage ich mal: Bis zum nächsten Mal! Ciao.
Joy Heron: Tschüss.