Transcript
Lucas:
Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcast! Heute habe ich mir die Joy eingeladen. Hallo Joy!
Joy:
Hallo!
Lucas:
Und wir reden heute über „Container Queries“. Das ist ein Thema, auf das hat sich die Joy schon ganz lange gefreut. Oder Joy?
Joy:
Ja, sehr lange!
Lucas:
Genau, deswegen wird es jetzt höchste Zeit, das mal im Podcast ausführlich zu besprechen. Aber bevor wir damit anfangen, Joy und ich haben im Vorgespräch uns so ein bisschen unterhalten, dass es jetzt so die dritte CSS Folge ist im Podcast und uns interessiert da so ein bisschen euer Feedback. Ist euch das jetzt ein bisschen zu viel CSS? Oder habt ihr vielleicht sogar ein Thema in dem Bereich CSS oder auch Web allgemein, über das ihr unbedingt mal was hören wollt? Wir wären da sehr an eurem Feedback interessiert! Und für die Leute, die sagen: „CSS ist doof!“, die können natürlich diese Folge auch einfach überspringen. Oder genau diese Leute sollten vielleicht die Folge hören. Das müsst ihr aber dann selber entscheiden. Okay. Gut Joy. Container Queries. Also ich glaube es gibt kein Feature in der Geschichte von CSS Specs, auf das die Leute so lange gewartet und gehofft haben wie dieses. Bevor wir erklären was genau das ist, können wir ja erstmal darauf eingehen: Was ist das Problem, was gelöst wird? Also was können wir bisher nicht und was ermöglicht uns das jetzt zu tun?
Joy:
Ja, das können wir gerne machen. Also tatsächlich haben wir das in der Folge zu „Intrinsic Design“ schon angesprochen. Also ich glaube in der Folge zu „Intrisic Design“, wir können das wahrscheinlich verlinken in den Shownotes, haben wir darüber diskutiert. Also was man zum Beispiel heutzutage nicht machen kann. Und unter anderem… ich glaube in der Folge, da kann man dann im Transkript nachgucken. Aber ich glaube, ich habe da gesagt: „Ich brauche unbedingt Container Queries!“. Das war so Teil von dem, was ich gesagt habe. Und… Aber was das ist, ist wenn ich CSS schreibe, kann ich das mit der aktuellen Implementierung, kann ich CSS… also unterschiedliches CSS je nach Viewport schreiben. Zum Beispiel, ich kann sagen: Also meine Komponente soll so irgendwie… soll sich vertikal ausrichten, aber wenn der Viewport größer ist als 600 Pixel, dann sollte sie sich horizontal ausrichten. Das geht heutzutage schon. Aber was es nicht gibt, ist, dass wenn ich zum Beispiel eine Komponente schreibe und ich möchte, dass die Komponente irgendwie mehrere Darstellungen hat und dass sie irgendwie, wenn sie in einem also kleinen Bereich ist, dass sie sich vertikal ausrichtet und auf größeren, dass sie sich horizontal ausrichtet. Ich kann das nicht kontextbezogen machen mit dem aktuellen CSS. Das heißt, wenn ich zum Beispiel eine Komponente schreibe und ich diese Komponente auf einem schmalen Bereich auf… also in der Sidebar platziere zum Beispiel in einem CSS-Layout, dann kann ich in CSS nicht herausfinden: Wie viel Platz hat meine Komponente eigentlich? Ich kann wissen, also wieviel Platz hat der Viewport? Ah, der ist 1200 Pixel breit! Aber die Komponente selber ist in einem kleineren Kontext als die Gesamtbreite des Bildschirmes. Und das ist dieses… Also das ist das, was Container Queries ermöglicht. Und der Grund, warum man sich so doll darauf freut ist, dass… man landet eben immer wieder an diesem Punkt, wenn man CSS entwickelt. Man denkt vielleicht: „Ach, das könnte man irgendwie alles rumtricksen, da muss ich nicht…“. Aber das ist immer irgendwie… fühlt sich falsch an. Du schreibst eine Komponente und du denkst: „Ja, ich möchte das irgendwie schauen: Wenn es nicht viel Platz gibt, dann ist das vertikal ausgerichtet, wenn viel Platz ist, ist es horizontal ausgerichtet, wenn es wirklich viel Platz gibt, dann kann ich eine andere Darstellung wählen“. Aber da machst du das entsprechend des Viewportes, aber dann setzt du die Komponente so in einem schmalen Kontext ein und merkst, das passt nicht. Und das ist irgendwie so sehr frustrierend. Genau.
Lucas:
Ja. Ja, ich glaube das ist ja auch so eine Sache, die erst intuitiv nicht logisch erscheint, dass auf einem größeren Bildschirm Dinge auf einmal weniger Platz haben. Aber das kennen wir glaube ich alle. Einfach, wie du gesagt hast, an so einer Seitenbar, die dann vielleicht zu einer vollen Breite wird oder sowas, dass dann tatsächlich auf einmal weniger Platz da ist. Und das andere ist, was glaube ich auch ganz wichtig ist für viele Leute, ist auch Wiederverwendbarkeit, oder? Wiederverwendbarkeit von Komponenten in verschiedenen Kontexten. Dafür sind die auch sehr praktisch. Okay, gut. Jetzt stelle ich mir das jetzt irgendwie erstmal ganz naiv so vor, wahrscheinlich ist das so wie ein media query für den gesamten Bildschirm. Da sage ich jetzt einfach nur: Diese media query ist für deine eigene Breite, was ist denn daran so schwer? Aber wir können ja vielleicht erstmal erklären, was muss ich denn schreiben, damit das funktioniert? Also was brauche ich dafür?
Joy:
Ja, also es ist tatsächlich ein sehr schweres Problem. Wenn man sich das überlegt, wie man Layout machen würde. Also wie man irgendwie… also das Layout von etwas berechnet, es ist tatsächlich ein rekursiver Prozess. Also wenn wir uns also überlegen… also HTML ist eine Baumstruktur. In der Informatik sind ein Baum, also es hat einen Elternknoten und einen Kinderknoten und dann, das geht so weiter durch den ganzen Baum durch. Und um das Layout von dem Elternknoten zu berechnen, muss ich dem irgendwie die Größe und die Position und alles von den Kinderkomponenten schon berechnet haben, damit ich weiß als Elternkonten, wie groß bin ich? Also das ist ein rekursiver Prozess, wo man sich überlegt: Wenn ein Kind-Element sich so… also plötzlich breiter wird, dann geht das den ganzen Baum wieder hoch und das Layout von allen Elternknoten müssen sich neu berechnen und wenn der Elternknoten halt so einen Sibling-Knoten hat, also etwas was unterhalb… also etwas, was danach kommt, dann verschieben sich die Sibling-Knoten, die folgen und das geht halt den ganzen Baum wieder hoch. Also tatsächlich, es gibt ein Buch, das heißt das „Web Browser Engineering“-Buch, da versuchen diese… also die Entwickler da, einen Webbrowser in Python nachzubauen und erklären zum Beispiel in einem Kapitel, wie Page Layout eigentlich berechnet wird. Und wenn man das liest, merkt man: Ach, das ist halt eben nicht so ein naiver‚lass uns das mal Brute-Forcen, sondern es ist schon ein recht komplexes Konstrukt.
Lucas:
Ja, auf jeden Fall. Ich meine man muss sich ja überlegen, dass man auf jeden Fall dafür sorgen muss, dass man das terminiert. Nicht dass irgendwie, das Kind wird breiter, weil die Eltern breiter werden und dann sagen dann die Eltern: „Ah, jetzt habe ich ja mehr Platz und jetzt werde ich doch wieder schmaler“ und dann…
Joy:
„Jetzt habe ich meinen Platz, jetzt breite ich mich aus!“ Und dann die Kinder denken: „Ah, jetzt habe ich mehr Platz und dann breite…!“ Also irgendwie. Also man kann so sich… Also wenn man sich so überlegt, dass CSS ein rekursiver… also nicht CSS. Also Layout ist ein rekursiver Prozess. Und wenn man sich überlegt, welche Konstellationen man irgendwie… also diese Nicht-Terminierung, hinkriegen könnte mit CSS. Wenn zum Beispiel ein Kind-Element sagen würde: „Ich bin immer zehn Pixel breiter als mein Elternknoten“ zum Beispiel und man das irgendwie nicht auf eine Art und Weise berechnet, dass das terminiert, ja, es wäre schlimm. Ich finde halt… Also eine Sache, die ich… das ist eine Randsache, aber ich muss es nur leider erwähnen. Also einige Menschen meinen, CSS ist keine Programmiersprache, weil es keine Rekursion kann und ich finde diese Aussage so witzig, weil die Sprache wurde wirklich so entwickelt, damit es keine Rekursion erlaubt. Weil Rekursion tödlich wäre. Und dann… Also das ist eins von den Features, also das ist wirklich so im Sinne von CSS, ist das wirklich ein Feature von der Sprache.
Lucas:
Ja. Ich erinnere mich auch noch daran, als die Leute angefangen haben, dieses Servo Engine zu schreiben, also der die zukünftige Engine von Firefox werden sollte, da haben die ja viel darüber berichtet, wie sie dafür sorgen wollen, dass das Layouting parallelisiert werden kann. Also dass du quasi Multithreating haben kannst für das Berechnen des Layouts und wie kompliziert das halt ist. Und ich glaube, deine Gedanken gerade haben schon ein bisschen geholfen das sich ein bisschen vorzustellen, weil umso länger man drüber nachdenkt, umso erstaunlicher ist es, dass es so gut funktioniert. Also da scheint schon einiges dahinter zu stecken. Also es ist irgendwie auch klar, dass man sich diesen Spec jetzt nicht über Nacht mal schnell ausdenken und implementieren konnte, sondern das hat halt einfach lange gedauert bis es sowohl benutzbar ist als auch schnell. Das ist ja quasi die Herausforderung gewesen. Okay.
Joy:
Ja, genau. Also wir sollten vielleicht den… bevor alle sich freuen: Es ist tatsächlich aktuell nur in einem Browser implementiert. Das ist in Chromium und das hinter einem Flag. Also falls jemand sich zu doll gefreut hat und denkt: „Jetzt kann ich Container Queries sofort verwenden!“, es ist halt fast da. Noch nicht ganz, aber fast.
Lucas:
Aber man kann es ja zumindest schonmal selber ausprobieren für ein Spielprojekt oder für was auch immer. Ich glaube dafür ist die Zeit reif.
Joy:
Ja, das ist eine gute Idee!
Lucas:
Aber lasst uns auf das „ab wann kann ich das benutzen?“, lasst uns darauf ein bisschen später mal eingehen. Erstmal lass uns erklären was jetzt ist. Also was kann ich jetzt tun? Wie funktioniert das?
Joy:
Das kann ich gerne machen! Also ich würde eigentlich einen Schritt zurückgehen und etwas über CSS Containment erzählen, bevor ich über Container Queries erzähle. Weil CSS Containment ist tatsächlich… Also Container Queries sind tatsächlich eine Erweiterung von CSS Containment, deswegen kommen sie eben so aus der Ecke. Und was CSS Containment ist, es ist tatsächlich ein Feature, was ich, als es rauskam, ich glaube das war letztes Jahr, fand ich das ein bisschen langweilig. Was es bedeutet, dass ich ein CSS Property in mein CSS schreiben kann und ich kann zum Beispiel „contain layout“ sagen. Das erzählt dem Browser, dass alles innerhalb des Elementes… ist quasi da drin enthalten und beeinflusst andere Dinge nicht auf der Seite. Dann gibt es sowas wie „contain size“ und dann sagt das, dass die Kinder-Elemente die Größe des Elterns nicht beeinflussen kann. Und da gibt es auch „contain paint“ zum Beispiel, da sagt… also nichts wird außerhalb dieser Kachel so gezeichnet. Ja.
Lucas:
Okay. Kannst du bevor wir da weiter drauf eingehen nochmal kurz ein Beispiel geben für etwas, wo… weil das ja irgendwie intuitiv nicht logisch erscheint, was könnte denn ein Kind sein, was nicht im Layout von meinem Element enthalten ist? Also…
Joy:
Ja, das kann ich sagen. Also das bedeutet… Also mit CSS wie es aktuell ist, wenn ich CSS implementiere für meine Seite, ist… also bevor Containment rauskam, war es möglich quasi… also das Layout war, der Kontext war die ganze Seite. Das hieße, wenn ich eine Komponente geschrieben habe, da konnte ich halt beliebig viele HTML-Komponenten, also HTML-Kinder in diese Komponente schreiben und dann war das so… also du kannst mit „position“ arbeiten. Das ist der Trick. Also mit „position absolute“ kannst du ein Element absolut positionieren in dem Kontext drum rum. Also per Default, wenn man „position absolut“ nimmt, der positioniert das an… also irgendwo… also der positioniert das Element innerhalb des Bodies. Also wenn man nichts anderes CSS schreibt. Dann kannst du zum Beispiel „position absolute top 0“ schreiben und der positioniert das wirklich auf der… also ganz oben an der Seite mit Position…, also Top 0. Also das es null Pixel von der Top ist. Was man so länger machen konnte, war immer… also mit position, es gibt nicht nur „positon absolute“, sondern es gibt auch „position relative“. Und mit „position relative“ könntest du zum Beispiel sagen: Ich möchte so irgendwie ein Sternchen immer fünf Pixel von den… also irgendwie in den oberen Rechtecken von meiner Komponente positionieren. Egal wo meine Komponente ist. Und jetzt kann es sein, dass dieses Sternchen das letzte HTML-Element in meiner Komponente ist, aber es sollte irgendwie oben in diesem Rechteck positioniert werden. Was ich dann machen kann ist, ich kann für meine Komponente sagen „position relative“ und dann der „position absolute“ kann ich zum Beispiel „top 5 pixel, right 5 pixel“. Dann würde es immer oben rechts in der Ecke positioniert werden, dieses Sternchen. Was contain layout, wenn ich das jetzt sage… also das hat eine implizite „position relative“. Ich glaube nicht, dass man das zusätzlich da angeben muss, ich glaube das ist implizit. Und das bedeutet, dass wenn ich… die Dinge innerhalb dieses Elementes können nicht außerhalb dieses Elementes positioniert werden. Weil das ist eben ein anderer Punkt. Wenn wir diese Einschränkung nicht geben, ist das Layout komplexer zu berechnen, kann man sich vorstellen. Wir wissen tatsächlich nicht, ob die Kinderelemente, wenn sie so absolut positioniert sind, eigentlich innerhalb von mir oder außerhalb irgendwo anders auf der Seite positioniert sind? Und mit diesem Contained Layout, das ist jetzt so eine Einschränkung, wenn ich Dinge innerhalb von diesem Kontext habe, kann ich die absolut positionieren, innerhalb des Kontextes. Ich kann so irgendwie „bottom 0“ sagen, um das irgendwie unterhalb der Komponente… also in dem Layout-Kontext da unterhalb von dem Dings zu positionieren. Aber ich kann den nicht mehr absolut in der ganzen Seite positionieren.
Lucas:
Verstehe! Also okay, das heißt also erstmal, dass dieses Containment eigentlich keine Features hinzufügt, sondern grundlegend jetzt erstmal den Browser dabei hilft schneller zu arbeiten, weil er bestimmte Fälle ausschließen kann, oder?
Joy:
Genau! Und ich glaub die Idee… Also ich kenne nicht alle Hintergründe hinter CSS Containment, aber die Idee war, dass wir Optimierungen machen können. Zum Beispiel, ich glaube es gibt „contain content“ oder so. Ich glaube, das ist eine Zusammenfassung von Layout und Paint mindestens, vielleicht Size auch. Ich weiß nicht, man muss da nachgucken. Aber das kann zum Beispiel, man kann das einschalten zum Beispiel, wenn ich… für jeden Artikel auf meiner Seite kann ich „contain content“ sagen. Dann weiß ich, alles ist inhaltlich so innerhalb von meinem Container eingeschränkt und der Browser kann da viel optimieren tatsächlich. Weil wenn der Artikel noch nicht im Viewport ist, dann muss er das gar nicht rendern. Also da kann der berechnen: Okay, also jedes von diesen Artikeln, also wenn es irgendwie eine ganz lange Seite ist und ich viele Artikel auf der Seite habe, dann kann ein Browser sehr viele Optimierungen machen. Also sagen: Wenn der Artikel nicht im Viewport drin ist aktuell und ich weiß das, dann kann ich dieses Rendering von diesem Artikel einfach rauslagern und das später… also wenn ich merke, dieser Artikel ist fast da und also dieses Scrollen ist fast da, da kann ich das on the fly irgendwie zeichnen zu einem späteren Zeitpunkt. Ja.
Lucas:
Ah cool!
Joy:
Es ist eine Optimierungssache und das ist, was ich als es rauskam, das war genau meine Reaktion: „Ah, irgendwie cool, dass es das gibt, aber werde ich das verwenden?“. Das ist irgendwie… Weil das ist eine, für mich war das so: „Oh, das ist vielleicht, wenn ich… Vielleicht ist das eine verfrühte Optimierung, wenn ich das ständig einbaue“.
Lucas:
Das stimmt!
Joy:
Ich mag verfrühte Optimierungen grundsätzlich nicht und dann war ich so: „Okay, vielleicht wenn ich schon eine Seite habe und ich merke irgendwie es ist langsam, dann kann ich das einschalten. Aber wer weiß?“
Lucas:
Ja, aber obwohl das ja schon gar nicht so einfach ist so einen Performance Test für CSS zu machen. Also zumindest habe ich das jetzt noch nie gemacht tatsächlich, die Layout Performance von meiner Seite zu testen. Aber vielleicht sollte man das mal ausprobieren.
Joy:
Vielleicht.
Lucas:
Keine schlechte Idee!
Joy:
Ich meine, so in der Regel, wenn man eine Seite nur aus HTML und CSS hat, dann ist die Performance meistens nicht problematisch, muss man zugeben.
Lucas:
Ja, das würde ich auch sagen! Außer man macht vielleicht ein wirklich sehr komplexes Layout.
Joy:
Das stimmt! Ich habe mal einen CodePen gemacht, wo ich rekursiv Grids ineinander verschachtelt habe mit CSS Grid und ich habe festgestellt irgendwie ab sechs Grids, also so Elemente, die einen CSS Grid beinhalten, wenn man die zu tief, dann…
Lucas:
Wird es schwierig.
Joy:
Der Browser meckert auch irgendwann.
Lucas:
Okay, das ist gut zu wissen! Okay, gut. Also wir haben jetzt irgendwie eine neue Metainformation, die wir an ein Eltern-Element mitgeben können, um zu sagen, wie die Kinder die Größe und das Layout des Eltern-Elements beeinflussen, richtig?
Joy:
Genau!
Lucas:
Okay und wie hilft uns das jetzt für die Container Queries?
Joy:
Ja, also das… Also Container Queries sind tatsächlich eine Erweiterung von Containment. Also das Spec ist von Miriam Suzanne und das können wir verlinken in den Shownotes und der Spec ist eigentlich eine Erweiterung von CSS Containment. Und was das tut ist, dass das in dem „contain“-Statement, also da wo ich den „contain“ definiere, kann ich jetzt… also es gibt zwei neue Keywords. Das ist „inline-size“ und „block-size“. Also inline-size ist die logische… also die logische Breite und block-size ist die logische Höhe von dem Element. Und…
Lucas:
Darf ich dich da kurz nochmal unterbrechen Joy?
Joy:
Ja!
Lucas:
Kannst du kurz sagen was du mit logische Höhe und logische Breite meinst?
Joy:
Ja, kann ich! Also ja, ich kann was dazu erzählen. Was das ist, ist: Wir sind in Deutschland und wir haben eine Schrift, die von links nach rechts geht. Deswegen also denken wir sehr oft in links-rechts oder oben-unten. Aber es gibt unterschiedliche writing modes. Also es gibt zum Beispiel: In Chinesisch wird von oben nach unten geschrieben und ich weiß nicht, ob die links nach rechts machen oder rechts nach links. Das muss ich noch nachgucken. Aber es gibt eben unterschiedliche Kulturen, die unterschiedlich schreiben und als CSS geschrieben worden ist, haben wir zum Beispiel immer… also wir haben implizit immer so eine… also dieses links nach rechts, oben nach unten Gedanken schon drinnen. Deswegen haben wir so margin top, margin bottom, margin left, margin right. Und wenn Flexbox eingeführt wurde, die haben eine Entscheidung gemacht, das nicht zu machen, sondern sie haben stattdessen diese logischen Begriffe dafür verwendet. Also wenn ich zum Beispiel, anstatt zu sagen: ‚Das ist nach irgendwie rechts‘ Also diese… Sorry, das ist so ein bisschen… Also die logischen Sachen sind ein bisschen schwer mündlich zu erklären.
Lucas:
Ja, das stimmt.
Joy:
Aber die Idee ist, die inline Richtung ist die Richtung in der ich schreibe und die block Richtung ist die Richtung in der ich… also in der die Zeilen also eins nach unten kommen. Deswegen ist block Höhe und inline eher die Breite. Und das coole ist, dass in moderneren Versionen von CSS kann ich das ändern. Ich kann sagen: Also ich schreibe mein CSS, ich verwende jetzt logische Properties, anstatt diese anderen „left, right, top, bottom“. Und was ich dann machen kann, ist, ich kann… also wenn ich den writing mode ändere, also ich kann sagen: „Jetzt bin ich in einer…“ Also ich schreibe eine Seite und das soll für Chinesisch gut aussehen, da ist die Ausrichtung von meiner Seite anders. Und dann kann ich die ganze… also für alles was in diesem Bereich ist, da kann ich die writing-Richtung ändern und dann werden diese… dann werden die Kacheln automatisch, alles was ich geschrieben habe, wenn wir diese logische Properties gemacht haben, die werden sich einfach anpassen und richtig ausgerichtet sein.
Lucas:
Aha, okay. Sehr cool! Also das heißt also, das ist jetzt auch erstmal wieder was, einfach ein Umdenken damit wir einfach auf verschiedene Schreibweisen eingehen können.
Joy:
Genau!
Lucas:
Und wir waren dahin gekommen, weil du gesagt hast, es gibt jetzt inline-size und dann habe ich dich in diese kleine side note geführt. Also wir haben jetzt inline-size und block-size als neue contain-Regeln und genau… Was sagen die denn aus?
Joy:
Also, ja genau. Also wenn man „contain layout inline-size“ schreibt, zum Beispiel in einem Element, so ein Main-Element, was ich dann machen kann ist, dass ich so einen Container Query schreiben kann. Und der Syntax ist sehr ähnlich wie ein media query, da kann ich zum Beispiel „@container (min-width: 25rem)“ schreiben und da drin also ein CSS für meine Komponente schreiben. Also da kann ich zum Beispiel… Und wenn diese Komponente…. der Trick dabei ist… Also das fühlt sich genauso wie ein media query an. Der Trick dabei ist, dass wenn die Komponente zum Beispiel in dem Main landet, dann gibt es dieses Containment für den Main und dann weiß dieser Container… Also zusammen mit diesem container query, wie zu berechnen… also dass diese Styles so angewendet werden können. Und der Trick dabei ist, dass wenn ich den Aside… Also wenn ich einen Main habe und einen Aside und der Aside ist meine Sidebar, dann kann ich für den Aside auch ein Layout inline-size machen und einen anderen containment block für den Aside haben. Und wenn diese Komponente, wofür ich die Container Query geschrieben habe, wenn der in dem Aside auftaucht, dann würde der sich auch also eben anpassen anhand von der Breite, dem Platz, den er zu Verfügung hat.
Lucas:
Okay. Also ich versuche das nochmal kurz in meine Worte zu fassen, ob ich das richtig verstanden habe. Das heißt also, wenn ich sage „@container“ und dann eine Breite angebe mit „min-width“ beispielsweise, dann habe ich da darin einen Selektor „.component“, dann bezieht sich diese min-width auf das nächste Eltern-Element, was ein „contain“ hat?
Joy:
Genau!
Lucas:
Okay.
Joy:
Ich habe das tatsächlich noch nicht ausprobiert, das sollte ich nochmal ausprobieren. Also meine Erwartung wäre, wenn zum Beispiel der Container… Ich weiß es nicht, ob der Body zum Beispiel eine implizite Containment hat. Wenn ja, dann würde sich das ähnlich wie ein media query verhalten möglicherweise. Aber das muss ich noch nachschlagen, ob das der Fall ist.
Lucas:
Okay. Cool! Das heißt also, muss dieses „contain“, muss das also sowohl „layout“ haben, als auch dann entweder „inline-size“ oder „block-size“, oder…?
Joy:
Ja, das ist mein Verständnis. Also ich muss sowohl wissen, dass nichts innerhalb dieses Elementes irgendwie ausrückt und auch, ich muss wissen, dass die Breite… also ich glaube Size… es ist eine Erweiterung von einem Size. Also Size bedeutet, dass die Kind-Elemente eigentlich die Größe von den Eltern nehmen und die können die Größe des Elternteils nicht beeinflussen. Also es ist, ich glaube gleich für inline-size und block-size, nur dass es eben in diese Achse geht und der ist eingeschränkt auf die Breite auf der inline-size, aber das heißt, der ist nicht eingeschränkt gegebenenfalls, der muss nicht eingeschränkt sein auf der block-size, auf die Höhe.
Lucas:
Aha, okay. Verstehe! Und das heißt aber in dieser Regel kann ich dann wieder beliebige Dinge tun. Also ich könnte auch sagen: Es wird der Background red. Also es muss nicht unbedingt irgendwelche Layout Sachen sein, sondern da habe ich wieder den vollen Kasten aus CSS-Regeln, die ich benutzen kann?
Joy:
Genau, ja!
Lucas:
Cool!
Joy:
Genau, es fühlt sich genauso wie ein media query an, es sieht auch ähnlich aus. Es ist nur, dass es eben jetzt Ahnung hat von dem Kontext, in dem er ist. Das ist der Unterschied.
Lucas:
Okay. Gut, dann vielleicht für die Leute, die sich noch nicht so superviel mit CSS beschäftigt haben: Was ist denn, wenn ich jetzt dieses „@container“ dahinschreibe und mein Browser kann das gar nicht? Geht der dann kaputt? Wirft der einen Fehler? Oder was passiert dann?
Joy:
Das ist eine sehr gute Frage! Die Antwort ist „nein“. Also CSS ist tatsächlich eine Sprache, die progressive enhancement sehr gut kann und das bedeutet, wenn ich etwas neues in CSS habe und die Browser das noch nicht kennen, werden sie das einfach ignorieren. Und ich glaube, das ist einer der Gründe warum wir… also ich mag… Es gibt einen Tweet von dem Andy Bell von Picalilli, der hat so einen sehr guten Tweet, wo er eben so ein Video macht von irgendwie einem Layout, was er für Internet Explorer 11 gemacht hat glaube ich und das war… der kann noch nicht Grid und konnte noch nicht die neusten Layout-Sachen. Aber sein Layout ist so schick, dass wenn die Benutzer das sehen, dass sie gar nicht wissen, dass es nicht das allerbeste ist. Und der nennt das „minimum viable experience“. Also wenn wir CSS schreiben, wenn wir Layouts schreiben: Unsere Default Komponente kann so schick sein und wenn es gut genug ist, dann merken die Benutzer nicht, dass da irgendwas nicht das allerbeste sein könnte. Da könnten wir uns vorstellen, wenn wir so unterschiedliche… Also ich glaube, ich hab so ein paar Beispiele, die ich rausgefunden habe, wo das irgendwie so erzählt wird, wie man das macht und da wird so eine card oft genommen als Beispiel. Dass ich eben so eine Karte habe und wenn ich das auf dem Handy habe, sollten alle Dinge so vertikal ausgerichtet sein und wenn ich irgendwie ein bisschen mehr Platz habe, dann horizontal und so weiter uns so fort. Und wenn dieser Basis-Style von der card gut genug ist, dann spricht nichts dagegen, das einfach zu lassen für Browser, die Container Queries noch nicht können.
Lucas:
Okay, cool! Ja, also ich glaube das ist einfach nochmal wiederholt für die Leute, die sich da vielleicht noch nicht mit beschäftigt haben, weil das ist glaube ich wichtig zu wissen. Aber darauf aufbauend noch die Frage: Kann ich… Also sagen wir jetzt mal die Feature Flag wird entfernt und in Chrome ist das jetzt für alle verfügbar, die den aktuellen Chrome haben, ab wann kann ich das denn dann benutzen in meinem Webprojekt?
Joy:
Also es… Die Antwort ist wie immer: Es hängt davon ab. Also ich bin der Meinung, wenn wir quasi dieses Versprechen von progressive enhancement glauben, sobald das eben in einem Browser verfügbar ist und das, was in den Container Queries nicht notwendig ist für die Benutzbarkeit von der Komponente, dass wir das durchaus einführen können. Also man muss natürlich je nach Kontext schauen, wie sich das ergeben wird. Ich glaube, das hängt davon ab, also manchmal irgendwie, wenn man merkt: Dieses Feature, es ist wichtig, dass das in allen Browsern funktioniert. Dann gibt es andere Mittel. Da sind viele Dinge noch zu tun, also wir haben ja… Ja. Also da gibt es so ein paar unterschiedliche Dinge, die man heutzutage schon tun kann. Aber ich glaube, sobald es in einem Browser da ist, also in Chrome, dann… ich glaube wir können das verwenden. Wir sollten nur immer schauen, dass wir diesen Fallback haben, der gut genug ist, dass er in anderen Browsern unterstützt wird.
Lucas:
Okay. Also wir sollten auf jeden Fall erstmal immer die Komponenten-Regel schreiben, die nicht in dem „@container“ drin ist und gucken, dass die schonmal einigermaßen gut aussieht quasi.
Joy:
Genau!
Lucas:
Okay. Cool! Super Joy! Da habe ich heute auch direkt etwas neues gelernt. Dann danke ich dir für diesen tollen Überblick, außer du hast noch irgendwas, was du noch gerne über Container Queries erzählen möchtest?
Joy:
Nein, ich glaube das war es. Also wir können auf jeden Fall verlinken zu ein paar guten… also Tutorials und Guides, die es jetzt gibt.
Lucas:
Auf jeden Fall! Das findet ihr dann alles in den Shownotes. Ja und dann sage ich vielen Dank! Und dann sage ich auch schonmal bis zum nächsten Mal! Tschüss Joy!