Episode notes
Nach rund 20 Wochen Pause haben wir uns mal wieder zusammengesetzt und durch die aktuellen Browser-Releases gewühlt. Diesmal haben uns vor allem Firefox und Safari angeschaut, während Chrome eher im Hintergrund mitlief. EVENT-TIPP Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der…
Transcript
Read the transcript · about 16,320 words, follows along as you listen
Okay, also Anker-Positioning definitiv für alle, die sonst zu viel CSS schon können und sagen, ich muss noch ein bisschen mehr lernen. Da kann man sich reinfressen. Was wäre denn, wenn man CSS in React reinkriegen wollte? Wie würde man das tun? Netter Versuch, Herr Netzer, aber lassen Sie mal den Delling jetzt das mal richtig machen. Das wäre auch dann zur Navigation API erstmal alles, oder? Ich denke. Das Problem ist halt, es ist dringend notwendig gewesen. Und jetzt, wo es da ist, denkt man sich halt eben, es ist wie eine neue U-Bahn-Linie.
Mensch, warum gab es hier nicht schon immer? Okay, ich fahre jetzt damit. Hey, kurze Werbeansage von uns. Seit 2011 sind wir regelmäßig auf der Beyond Tellerrand, einer Konferenz für Kreative und Entwickler. Und sie inspiriert uns bis zum heutigen Tag. Das nächste Mal findet die Konferenz am 27. und 28. April 2026 in Düsseldorf statt. Tickets kosten 349 Euro, was für zwei Tage Konferenz mit dem Line-Up ein Schnapper ist. Und wir würden uns freuen, dich dort zu treffen.
Auf der Webseite beyondtellerand.com ohne Bindestrich gibt es alle Infos. Und noch ein Tipp. Gönnt euch ein Zimmer im Holiday Inn oder im New Tab neben der Venue. Denn abends kann man dort oft noch mit den Speakern und der Community an der Bar abhängen. Wir alle freuen uns, wenn du dabei bist. Und wer darüber hinaus noch Bock hat, dem gebe ich persönlich gerne eine Führung durch Düsseldorf inklusive Königsallee, Altstadt, Medienhafen und japanischem Viertel.
Revision 705. Wir sind heute zu zweit. Wir hätten aus dem Team den Peter. Hallo Peter. Moin, moin, moin. Ich bin der Shep und der Peter und ich, wir haben uns hier wieder zusammen gerauft, getelefoniert, gewideot. Weil wir nach 20 Wochen mal wieder so ein bisschen Browser-News, neue Features, neue Releases zusammen oder zusammen durchgegangen sind und so die Highlights rausgefischt haben, die wir gut fanden und über die wir sprechen wollen. Und davon gibt es nicht wenig, obwohl wir uns ja nur die Browser angeschaut haben, die keiner benutzt.
Also Chrome mit seiner Derivate haben wir ja ignoriert. Ja, das stimmt. Aber man muss auch sagen, Chrome fällt ja irgendwie jetzt immer unter den Tisch, während das ja früher andersrum war. Und ich glaube, das liegt einfach daran, dass irgendwie viele Devrails da weggegangen sind. Und auch diese, also früher gab es ja auch immer für jedes Release ein cooles Video, wo die so die neuesten Features gezeigt haben. Ich finde, das kommt so nicht mehr so gut rüber, während die anderen eben in dem Bereich so ihr Game aufs nächste Level gehoben haben. Ja, ich glaube auf jeden Fall.
Also definitiv macht der Herr Archibald da bei Mozilla bei allem anderen Blödsinn, den er verzapft. Aber er kriegt es auf jeden Fall kommuniziert, wenn da ein neues CSS-Feature ist, was es ist und wie es funktioniert. Ja, genau. Also das macht er echt super. Und natürlich hier Jen Simmons und Team machen das auch mega gut für Safari, also genau, und Chrome läuft halt so mit, das ist halt irgendwie so, wie so eine Katze auf dem Bauernhof, ist halt auch da.
Aber eigentlich ist so weitestgehend wartungsfrei, weil macht eh was sie wollen, sind eh die schnellsten alle zwei Gemeins, also eigentlich ja so genau, so wie das Kind, was keine Probleme macht, um das kümmert sich keiner, äh, genau, so ist es bei Chrome, also der macht auch Probleme, aber, oh ja. Genau. Also, was haben wir denn? Wir würden starten mit einem größeren Feature. Also, nicht, dass wir da jetzt die halbe Sendung darüber sprechen wollen, aber technisch ist es ein sehr aufwendiges Feature, was an dem lange gearbeitet wurde, nämlich Firefox unterstützt jetzt als finaler Browser-Engine Anchor-Positioning.
Ja, ist ja so ein Ding. Das gucke ich mir an. Ich sehe dann so die Demos, wo wild Sachen über den Bildschirm fliegen. Denk mir, das ist mega komplex. Die Spezifikation lese ich mir durch, wenn ich dazu komme. Aber ich muss sie mir gar nicht durchlesen, weil ich habe ja einen Podcast. Ja, das machen wir den eigentlich. Ich lerne ja auch immer von dir. So wie mit hier, was war das letzte Mal, mit den Disposables und so. Ja, und von unseren Gästen. Das ist ja der Grund, warum wir das hier seit 700 Revisionen durchstehen. Genau.
Ja, Anchor Positioning ist, Ich glaube, entstanden ist das eben aus diesem Bestreben von Open UI, also dieser Community Group, die zum einen bestehende Formular- oder Interface-Elemente stylebarer machen möchte und zum anderen wollen die auch mehr User-Interface-Primitive in die Browser bringen, mit denen man sich dann beliebige User-Interface-Pattern bauen kann. Und wenn man sowas hat wie ein Select mit einem Dropdown, das sich öffnet oder ein Date-Picker, irgendwie solche Dinge, dann.
Oder auch bei Popovers, wie wir sie eigentlich verstehen, also so als eine Art Tooltip, da haben wir ja immer den Bedarf daran, dass dieser erweiterte Kontext dazu sich quasi an dem Elternelement positioniert in irgendeiner Art und Weise. Ja, also der Default von Positionierung ist ja irgendwie ausgehend von der linken oberen Ecke von irgendeinem Kontextelement, dass man irgendwie explizit setzt über irgendwelche CSS-Magie mit Nebenwirkungen, die man vielleicht gar nicht beabsichtigt.
Und was man ja eigentlich wirklich irgendwie sagen möchte, ist ja so auf einer quasi semantischen Ebene, du gehörst zu dem. Genau, also schnapp sozusagen magnetisch an das andere Element dran. Also wir konnten das ja bisher schon lösen, indem wir so einen Wrapper um beide drum hatten, der irgendwie Position Relative hat und dann kann man per absolute Positionierung dann schon viel machen, aber manche Dinge eben auch nicht. Zum Beispiel, wenn ein Element irgendwie nah an der unteren Viewport-Kante ist, dann musste man da irgendwie sehr viel JavaScript draufwerfen, um dann dieses Andocken von unten nach oben sozusagen zu verlegen, damit dann wieder der gesamte Bereich sichtbar ist.
Also solche Sachen. und man braucht eben einen Wrapper, man hat nicht diese Möglichkeit, eine Beziehung zu definieren in CSS, eine Layout-Beziehung und das geht eben mit Anchor-Positioning, also es ist das eine, was Anchor-Positioning kann und das andere ist eben, Anchor-Positioning kümmert sich auch darum. Wenn das sozusagen angedockte Element am Viewport-Rand droht, abgeschnitten zu werden, dass es das dann nach definierbaren Regeln eben an andere Stellen andockt an das Element.
Genau. Und Anchor Positioning ist im Grunde... Und letztlich funktioniert das wie absolutes Positionieren, nur mit dem Unterschied, dass du dann zusätzlich ein Element mit einem Anchor-Name ausstattest, das ist das Eltern-Element, und dann diesem Kind-Element sagst, mit der Anchor-Funktion, es soll sich daran andocken. Und genau, das ist erstmal alles, was du brauchst und dann hast du Möglichkeiten zu definieren wo das andocken soll, also man möchte das ja vielleicht nicht da angedockt haben, wo es defaultmäßig landen würde, und das kann man auf zwei Arten und Weisen tun, die einfachste ist, es gibt sowas wie so ein also ähnlich wie bei Border Image gibt es so um das Elternelement herum gibt es acht Quadranten.
Und schon wird dann sozusagen gesliced an den Kanten des Elternelements und daraus entstehen dann eben um das Elternelement rum acht Bereiche, einer drüber, einer drunter, einer links, einer rechts und dann noch in den Ecken. Und du kannst halt dem angedockten Element dann sagen, bitte platziere dich eben so nah an das Elternelement, aber in diesem Sektor. Ja. Oder, also das ist halt die eine Möglichkeit. Die andere Möglichkeit ist, dass du diese Dinge nicht nutzt, sondern dass du eben dann top und so weiter, top, right, bottom, left nimmst und da aber Bezug nimmst auf die Position des Eltern-Elements.
Also du quasi sagst, platziere dich an die linke Kante von dem Entschleure-Element plus vielleicht irgendwie 10 Pixel oder was weiß ich. Genau, das ist das eine. Und dann hast du auch eben, wie gesagt, Einflussmöglichkeiten auf die Mechanik, wie der Browser entscheidet, wenn ein Element eben nah am Viewport ist und droht abgeschnitten zu werden, wo er es dann stattdessen hin positioniert. Also du kannst dem dann so quasi so Fallback-Positionen geben und sagen so, wenn die ursprüngliche oder die gewünschte, wenn das irgendwie nicht hinhaut, dann probiere als nächstes diese Position.
Und so kannst du das dann eben machen. Und ich glaube, das kannst du sogar auch noch in zwei verschiedenen Komplexitätsstufen tun. Es ist ein dickes Brett, das da gebohrt wird. Es gibt einen Artikel von Tarek Afif, glaube ich, heißt der, wo er noch auf so einem, also es gibt ja so, zum Beispiel, wenn du was sticky positionierst und du hast ein älteres Element, was ein Overflow hat, einen gesetzten Overflow, dann fuck dir das stickier, also dann geht das nicht mehr.
Und so ein bisschen sowas gibt es auch bei dem Anchor Positioning, also es ist einfach, es ist nicht zu vermeiden, weil die Layout Engine muss in einer bestimmten Reihenfolge arbeiten, um das eben umsetzen zu können und das Learning und, aus seinem Artikel ist, das Elternelement muss immer gelayoutet sein. Also wenn das fertig gelayoutet ist, dann kannst du ein Element daran andocken. Ja, wie sonst soll es gehen? Wenn du das Layout nicht weißt, kannst du es ja nicht andocken. Du musst ja wissen, wo ist die linke Kante, damit du dich ja dran flanschen kannst.
Genau. Und da gibt es eben so verschiedenste Konstellationen, die er in seinem Blogpost auflistet, die eben dazu führen, dass das Eltern-Element eben in dem Moment, wo du das Anchoring, oder wo das Kind-Element, das geänkert werden soll, gerendert wird, wo das Eltern-Element eben einfach noch nicht fertig gelayoutet ist und man sich dann eben wundert, warum das mit dem Anchoring nicht funktioniert. Zum Beispiel, dass im HTML das Eltern-Element nach dem Kind-Element kommt.
Ja. Schlecht. Oder das Kind-Element ist im Eltern-Element und es hat keinen, es ist nicht aus dem Fluss genommen. Irgendwie solche Dinge. Ja. Ja, ja, stimmt. Temani-Affif, so heißt er. Ah ja. Genau, der ist sowieso super, also wenn man sich für so CSS-Sachen interessiert, dann ist der Temani einfach mega gut. Genau, ich suche das Blogpost mal schnell raus. Ja, auch wenn man irgendwie die komplizierten Sachen gar nicht lesen kann oder möchte, weil Zeit kein CSS-Freak oder sowas.
Aber das sind immer sehr schöne Demos, die er auch zusammen bastelt. Kann man mal folgen. Genau. Und was auch cool ist, ist ein Talk von Ramus van Damme, von Google, den er bei der, wir haben das ja ein bisschen beworben, diese State of the Browser-Konferenz. Die war am 28. Februar und da war ich natürlich remote zugeschaltet, weil voll gute Konferenz. Und der hat einen Vortrag eben nur über Anchor Positioning gemacht und der war auch super. Also ich würde empfehlen, also der ist leider noch nicht released, wir verlinken aber die London Web Standards, also den YouTube-Kanal.
Das erste Video von der Konferenz ist schon online, aber eben nicht das von Pramus und da kann man da mal ein Auge draufhalten. Und wenn ich es mitbekomme, dass es released ist, dann werde ich es vielleicht auch einfach dann nochmal nachträglich in die Shownotes einpflegen. Genau. Okay, also Anchor Positioning definitiv für alle, die sonst zu viel CSS schon können und sagen, ich muss noch ein bisschen mehr lernen. Da kann man sich reinfressen. Ja, wobei es gibt halt eben, ich finde halt cool diese Aufteilung in quasi.
Wie soll man sagen, so ein Out-of-the-Box-Mode, der schon cool ist und dann eben diesen Expert-Mode, in dem man sich dann sozusagen freiwillig begeben kann, wenn einem das nicht reicht. Und ich glaube, der Grund, das Anchor Positioning, also daran wird ja schon ganz lange rumgebaut, aber die Tatsache, dass du beide Wege hast, die verdanken wir, glaube ich, dem Apple-Team. Die haben das irgendwann mal eingebracht. Das hat dann auch dazu geführt, dass das eben einfach alles deutlich länger gebraucht hat, aber dafür ist es halt auch jetzt richtig geil und richtig rund.
Ich glaube, es gibt noch hier und da ein paar Browser-Bugs bei so Edge-Cases, weil das ist, glaube ich, auch einfach für die Browser-Ersteller nicht so ganz so einfach als Layout-System zu implementieren. So ein bisschen wie bei diesem Has, dass man da ja auch immer irgendwelche Fixes sieht in den Release-Notes. Sowas wie, wenn irgendwelche Element-States in dem Has benutzt werden. Sowas wie Video Doppelpunkt Playing. Das gibt's ja jetzt. Das gibt's ja.
Und das Has dann das noch nicht berücksichtigt hat und dann irgendwer gesagt hat, so, ja, ich wollte erst damit benutzen, ging nicht und dann nachher, Kacke, haben wir vergessen, müssen wir ja auch noch implementieren. Ja. Ja, es ist halt schwierig. Es hat CSS mittlerweile so eine große Oberfläche und so viele Sachen, die beachtet werden müssen. Ja, und die Browser generell sind ja einfach Höllenmaschinen. Ja, aber ich meine, zumindest kannst du ja sagen, irgendwann ist ja so eine Programmiersprache wie ECMAScript so in ihren Basics so weit, dass du damit alles machen kannst, was du machen willst.
Und in CSS kann dir ja im Prinzip für jeder neue UI-Trend, der um die Ecke kommt, kannst du ja einen Taste dafür machen. Alle benutzen den. Also sollten wir es einfach machen, das zu tun. Also brauchen wir dafür ein Feature. Ich warte ja noch auf den Liquid Glass Filter. Das wäre jetzt ein Beispiel, das man bringen könnte. Also die Idee für so einen optischen Effekt ist nicht absurd. Ich bin sicher, man kann das auch so implementieren, dass es nicht aussieht wie Kacke, so wie Apple das da gemacht hat.
Und ich möchte noch mal kurz noch hier attestieren, dass es nun, also ich brauche es nicht wirklich. Also ich möchte es nicht unbedingt haben. Es ist nur so viel Minukarte 1 dazu. Ja, aber du kannst ja auch über zum Beispiel sowas wie Border-Image-Share nehmen. Wann hast du zuletzt Border-Image benutzt? Ist lange her, aber ich glaube, wenn benutze ich Border-Image eher, um irgendwelche anderen dreckigen Sachen zu machen. Das war so klar. Warum frage ich das überhaupt? Das war so klar.
Wann hast du Border-Image zuletzt bestimmungsgemäß genutzt, ist die Frage. Weiß ich nicht. Ich glaube gar nicht. Für halt so Raster-Grafik-Sprites um eine Box drum herum. Arrangieren. Das war mal ein UI-Pattern. Das hast du halt jetzt nicht mehr so viel. So wegen Gründen auch immer. Aber es war halt eben mal prävalent und deswegen macht es Sinn, das in ein CSS-Feature zu gießen. Und im Fall von Border-Image ist es ja zumindest mal so, dass das noch nicht irgendwelche Wechselwirkungen mit was anderem haben wird, wahrscheinlich.
Aber bei sowas wie halt eben, es ist sticky oder nicht, das ist halt schon eine fundamentale Änderung, was dann halt eben Folgen hat. Und trotzdem kommen die CSS-Features mehr und mehr. Genau, wobei ich sagen würde, also da ist auch so ein bisschen mehr Ruhe eingekehrt. Also ich dachte mir jetzt ja so eine Phase, das war ja so ein bisschen wie in der Phase davor mit JavaScript, wo halt ständig neue Sprachfeatures kamen und neue Frameworks. Also ich weiß nicht, wenn ich hier durch unsere Liste durchgucke, sind da schon so einige CSS-Features drin. Und wir haben sehr viele einfach nur zur Kenntnis genommen bei unserem Durchgehen.
Also das ist schon... Genau, aber ich sage trotzdem, also ich finde, also trotzdem, ich habe ja auch dieses On- oder mit dem Nils zusammen mache ich ja dieses Online-Meetup-CSS-Café, also da haben wir gemacht. Und das haben wir 2020 gestartet, genau während der Pandemie. Und da haben wir jetzt seit bestimmt einem Jahr kein Ding mehr gemacht. Also zum einen haben wir alle viel zu tun und schaffen es nicht. Zum anderen ist es aber auch so, dass es mir ein bisschen schwer fällt, so neue Themen zu finden, die wir nicht alle schon beackert haben.
Also bei CSS brauchen die Dinge auch manchmal lange. Also dann hast du halt über View Transitions schon vor drei Jahren gesprochen und die sind, die haben sich ein bisschen weiterentwickelt, aber es gibt nichts grundlegend Neues zu erzählen in dem Bereich. Und ich finde, so ist es bei CSS. Das ist immer noch viel, aber das Tempo ist so ein bisschen runtergegangen. Okay. Quasi eine CSS-Fatig. Ja, also deckt sich nicht mit meinem Bild, muss ich tatsächlich sagen.
Aber das liegt wahrscheinlich auch daran, dass ich so viel mit JavaScript rumhänge, für die halt CSS-Features von vor drei Jahren neu sind. Also auf der Konferenz, wo ich Anfang der Woche war und weswegen ich mich so anhöre, wie ich mich anhöre, da gab es halt so eine Night-Session, wo jemand eine Stunde lang was über View-Transitions erzählt hat. Und diejenigen, die dann tatsächlich die Night-Session nicht wahrgenommen haben und sich schon früh an den Bierzapfern begeben haben. Das waren halt nicht viele.
Das heißt, da herrscht also durchaus Bedarf. Und generell... Ich nehme das schon, ohne Frage. Man unterschätzt ja immer dieses klassische Ding, ach, mein Vortrag hat doch jeder schon gesehen oder das kennt doch jeder. Und dann merkt man ja jedes Mal wieder, es ist halt nicht so. Genau, das und zum anderen ist es ja immer so, indem diese Technologie ja immer breiter gestreut wird, kannst du ja mit den einzelnen Versatzstücken viel mehr anstellen.
Du findest jetzt vielleicht nicht irgendwie den neuen Standard für das neue CSS-Café, aber da hinten läuft der oder die rum und die haben diese völlig absurde Konstruktion gebaut oder dieses abwegige Problem gelöst, indem sie halt zwei Dinge, die nicht zusammengehören, zusammengesetzt haben. Im Prinzip könnte das ja auch ein Thema sein für sowas wie das CSS-Café. Das haben wir aber auch schon, auch das hatten wir, also zum Beispiel hier der.
Roman Kumarow, der macht ja solche Sachen, der macht ja im Grunde, nutzt der bestehende CSS, also auch da Bleeding-Edge CSS, um den Beweis anzutreten, dass man auch ein neues CSS-Feature einbauen könnte, wo alle sagen, das ist so schwierig. Weil er sagt, ja, aber ihr müsst ja im Grunde nur diese Verfahren, die ihr schon da und dort drüben nutzt, müsst ihr nur kombinieren. Sowas wie ich glaube, was jetzt ja auch kommt, ist ja dieser sich selbst skalierende Text. Ja.
Und das hat er ja quasi über Scroll-Driven Animations dann gelöst, indem er eben eine Schrift hat in einer bestimmten Größe in einem Overflow-Container. Und wenn die zu groß ist, dann entsteht eben, dann hast du eine Scrollbar. Ja. Dadurch wird halt eine Animation, dann ist halt der quasi der Scroll-Progress nicht mehr 100 Prozent, sondern nur noch, keine Ahnung, 97, weil ein Teil halt irgendwie raushagt. Und in dieser Animation macht er die Schriftgröße kleiner. Ja.
Mit dem zunehmenden Scroll-Progress. Und dadurch wird dann wiederum im Umkehrschluss die Schrift wieder kleiner. Und so justiziert der Browser sozusagen in einer Loop die Schriftgröße so, dass der Text in diesen Container passt. Ja, und ich halte sowas halt eben für extrem wertvoll. Nicht nur, weil irgendwie musst du erst mal drauf kommen. Und diesen Kram, den er da schreibt, zu lesen, ist auch immer so ein bisschen, okay, mentalen Stahlhelm aufsetzen und jetzt mal konzentrieren und nicht irgendwie nebenher noch drei andere Sachen machen. Das stimmt, ja.
Aber ich meine, der Effekt, den du ja auch hast, wenn du jetzt irgendwie ein UI bauen willst, das irgendwie so ein bisschen Wow-Effekt hat. Will ja vielleicht gar keiner, kann man ja alles generieren lassen, bla, Keks. Aber wenn du wirklich den Wow-Effekt haben kannst, musst du ja tatsächlich etwas am Start haben, was die anderen halt eben nicht haben. Also Liquid Glass hat jetzt nicht gut funktioniert, aber der Effekt war halt eben, oh wow, wie haben die das gemacht, wie können wir das irgendwie nachbauen, bla, bla, bla.
Und du erinnerst dich da an Bet 2.0, als wir dann irgendwie nicht mehr irgendwelche seltsamen Alpha-Hacks machen mussten für runde Ecken, sondern als jeder runde Ecken machen konnte, war das ja instantan uninteressant. Ja, und nicht zu vergessen, Wet-Floor-Effekt, ne? Lauter so Sachen, ne? Und jetzt halt eben, jetzt ist der richtige Zeitpunkt, um halt diesen autoskalierenden Text zu haben, weil sobald das in der Spezifikation ist, interessiert das halt keinen mehr, weil das ja jeder wirklich Kreti, Pleti und Klot alle auch haben können. Mhm. Also.
Da geht was. Und gerade halt auch so dieses was kommt und wie kriegen wir es jetzt schon hin, das ist eine super Sache. Also ich will nur sagen, macht mehr vom CSS-Caffee. Das sagt sich so leicht, ich weiß. Ja, genau. Ich muss jetzt erstmal, wir haben ja unser lokales Meetup hier wieder gestartet, da muss ich auch mal wieder, also wenn du mal irgendwann Lust hast, in Düsseldorf vorbeizuschauen. Welches? Wir haben quasi zwei lokale Meetups fusioniert.
Das WebRocker NRW, was ich gemacht habe und das WebEngineering Düsseldorf, was der Andi gemacht hat. Und der Andi ist ja Teil des Engineering Kiosk Podcasts, wo wir beide auch schon zu Gast waren. Und der Wolfi, also der zweite da in dem Team, der macht schon lange so Meetups in Innsbruck. Unter dem Engineering-Kiosk, quasi unter der Flache. Franchise. Franchise, genau. Und der Andi hatte Bock, das auch in Düsseldorf zu machen. Und dann hat er mich gefragt und dachte ich, ja, warum nicht?
Mache ich mit? Genau, und letztes Mal, wir sind zu dritt und wir haben aber gesagt, wir machen eine Kadenz von alle zwei Monate, damit es uns nicht überfordert. Und jeder kümmert sich dann eben um ein Meetup, sozusagen als Programmveranstalter. Und dann habe ich quasi ein Meetup alle sechs Monate. in der Backe. Hm, verstehe. Ja gut, das ist wahrscheinlich zu managen. Genau, aber wo wir gerade über so Tricks reinsprechen, ich weiß nicht, ich habe ja mein jährliches Blogpost geschrieben, hast du das gesehen?
Oh, du musst öfter Sachen schreiben, dann besteht die Chance, dass ich das... Einmal im Jahr mache ich das ja nur. Ja. Ein CSS-Karussell? Ich habe gelesen, CSS-Karussell ist voll doof und riecht nach Lulu. Genau, wobei ich glaube, es ist ein bisschen besser geworden seitdem. Das ist jetzt auch schon mindestens ein Jahr her. Also ich meine, es war ja wirklich ein Griff ins Klo, nicht bis zum Schultergelenk, sondern bis in den Faulturm der Kläranlage, oder?
Es war doch ein Accessibility-Desaster. Genau, es war ja so ein Google-Io-Driven-Development, würde ich sagen. Und das Problem ist, dass Accessibility, also quasi die darunter, verbauten ARIA, Roles und Attribute und States einfach kacke waren, nicht adäquat für dieses Pattern. Und jemand, der eben auf assistive Technologien angewiesen ist. Einfach eine Scheißerfahrung hatte. Ich finde, das Pattern, wie es jetzt ist, ist okay, aber ich bin jetzt auch nicht der maximale Accessibility-Guru.
Genau, ich habe in den Blogpost auch geschrieben, das ist jetzt nichts, was man shippen sollte, aber da habe ich auch ein paar Bleeding-Edge-Sachen quasi zusammen kombiniert. Ja, ich sehe es gerade. Und die Idee vom Team-Switcher, also du bist ja ganz tief ins Geschichtsbuch gegangen und hast dann ja den CSS Zen-Garden quasi reaktiviert. Genau, aber das lag daran, also genau, Ursprung war eine Veranstaltung, die an zwei Tagen mit Abstand zwischen den Tagen einmal in, also in Amsterdam stattfindet, einmal im April und dann nochmal im Juni und genau, hier ist The Web We Want und da, genau, das ist dann so vielleicht so ein bisschen philosophisch, ein philosophisches Nachdenken, was wollen wir eigentlich für ein Web haben, also ist das Web, wie es heute ist, finden wir das noch gut oder fanden wir das, eigentlich nicht irgendwie witziger und netter vor 15 Jahren.
Und was müssen wir dafür tun? Und die haben... Was müssen wir dafür tun? Und nachdenken, statt einfach die ganzen Patterns zu reproduzieren, die die ganzen Vollhonks einfach machen. Man kann ja ganz einfach sagen, Halt's Maul, was du da laberst. Ich mach jetzt das, was funktioniert und nicht irgendwie Next.js installieren oder so ein Blödsinn. Merkt man, dass ich vor kurzem Next.js installiert habe? Ja, irgendwer meinte, du hättest wieder React-Probleme getweetet oder getweetet oder sowas. Irgendwas sowas war.
Ich habe nur irgendwie einen Artikel weiter verbreitet, der einfach nur sagte, React is insane und keiner redet drüber. Und dann... Hast du gesagt, stimmt. Ja, ich habe den einfach nur weiter verbreitet, wie das immer so mein Stil ist. Überschrift, Link mit Handzeige-Emoji davor. Aber sofort hatte ich die Menschenzeit voll mit so, Ja, der Typ hat ja gar keine Ahnung. Alles, was halt der Typ gemacht hat, ist halt Dinge zu sagen, die offensichtlich zutreffend sind und zu sagen, dass es beknackt.
Das Disagreement kommt halt eben daher, dass halt vieles im React-Kontext als normal wahrgenommen wird, was man auch als beknackt verstehen könnte, wenn man in einer anderen Welt wohnen würde. Ja, du meinst also sowas wie, wir finden es alle normal, mit irgendwie Erdöl zu fördern, durch Pipelines zu transportieren und so weiter und das in Autos zu kippen und alle anderen würden sagen, also sagen wir mal, ein Außerirdischer würde sagen, das ist aber komisch, was ihr macht. Na gut, das ist ein Außerirdischer.
Der zählt nicht, weil der ist nicht existent. Soweit wir das jetzt sagen können. Aber wir haben ja in unserer, bevor wir hier losgelegt haben und die Browserkisten sortiert haben, haben wir mal darüber geredet, wie das so ist. Straßen mit Autos vollparken versus schiebst in irgendwelche Tiefgaragen unter irgendwelchen Parks. Das ist ja wirklich was, wo man irgendwie sagen kann, es ist völlig normal, dass du deine Blechkiste einfach auf öffentlichen Raum stellst und dass du das halt eben mit der Blechkiste machst, aber mit deinem Kühlschrank nicht zum Beispiel.
Aber ich denke, ich kriegst ja auch direkt eine Strafe, Aber es ist unmittelbar vorstellbar, dass man einfach sagt, ja, es in Tiefgaragen stellt, platzt du doch lieber dahin. Und so ist es halt eben mit React, man lebt halt da in einem Universum, wo das halt irgendwie völlig normal ist, Use-Effekt für eine vernünftige API zu halten. Und wenn dann halt eben in der Dokumentation drinsteht, irgendwie ein Buch, langes Essay, wann und warum man das nicht verwenden sollte und nur für drei ausgesuchte Use-Cases ist das irgendwie akzeptabel.
Wenn man da halt in der Suppe drin schwimmt, denkt man sich, ja, läuft halt eben so. Genauso wie ich mir halt eben denke, ja, ich parke halt eben da drüben. Aber es ist halt eine andere Welt feststellbar. Und der Punkt, den man da eben machen muss, ist, man muss halt eben da mal gucken, ist diese andere Welt denn komplett aufwendbar? Solarpunk, wie in deinem Beispiel, oder tatsächlich irgendwie was, was unmittelbar implementierbar wäre, wo man sich unmittelbar reinversetzen kann.
Das ist der Punkt mit dem React gewesen. Ich habe nichts gemacht. Ich habe einmal Next.js für eine Demo installiert vor irgendwie drei Tagen und hatte kein Problem damit. Okay. Ja, sonst, wenn du den Artikel hast, könntest du den hier noch in die Links reinpacken. Da muss ich ja Social Media aufmachen und mir überall anhören, wie doof alles ist. Ja, musst aber auch nicht. Genau. Man findet es auf deinem Account. Wir nehmen auf am, warte, hier, was ist heute? 19. März. Das heißt irgendwie so kurz davor, ne?
Ja, ich poste im Moment so viel, ist schwierig. Ich tu das mal hier in die Links rein. Die Person hat auch ein Follow-up geschrieben, weil mir sagen sie alle, du hast keine Ahnung und diese Person hat keine Ahnung. Aber die Person hat es ja sogar hingekriegt, dass irgendwie so ein populärer Dev-YouTuber den Artikel im Prinzip gelesen hat und nach und nach immer mehr in einen Rant abgedriftet ist, von wegen, das stimmt ja alles nicht, das ist alles Blödsinn, blablabla. Leist der Theo? Ja.
Ich persönlich konsumiere den nicht, aber das ist tatsächlich... Ja, also ab und zu gucke ich mir den schon an. Aber das ist natürlich schon so ein Next.js, React und was dazu gehört, Fanboy. Ja, der Punkt ist halt nicht, dass das schlecht ist oder irgendwie, dass in dem Artikel Dinge drinstehen würden, die nicht zutreffend sind, sondern nur, man kann es halt eben so oder so bewerten. Das ist das Ding. So, wir haben es jetzt, wir haben wir zwei, Shep. Wir haben es geschafft, über React zu reden.
Ja, also wir machen jetzt auch so ein bisschen hier dem Kiki und Stefan Konkurrenz so ein bisschen. Ich versuche mit denen seit Monaten einen Termin auszumachen für eine neue Revision. Das wird niemals passieren. Es wird niemals eine neue TypeScript und React-Folge geben, einfach weil es völlig unmöglich ist, aus den beiden Personen irgendwie, also die zeitgleich, also du weißt doch, wie in Slack nach einer gewissen Zeit die Nachrichten gelöscht werden.
Ich kriege es halt nicht, eine Frequenz hinzukriegen, wo die sagen, dann könnte ich, dass das passiert, bevor die Nachricht weg ist, weißt du? Ja, irgendwie etabliert sich das gerade, dass wir dieses ARIA-Glücksrad machen. Zumindest so lange, wie wir noch neue ARIA-Sachen bekommen aus unserem Zufallsgenerator. Irgendwann hört das ja auch auf. Und da ist ja unser Trick, immer schon den nächsten Termin abzumachen am Ende der Aufnahme der Folge. Dann wird das auch was.
Weil wir sind zu fünft. Ja, aber ihr seid auch fünf Menschen, die mehr Kontrolle über ihren Terminkalender haben als wir drei. Also da wird nichts mehr, das kannst du vergessen, das kommt nicht mehr. Wir müssen jetzt also auch die React-Last schultern. Okay, aber wir sprachen ja gerade über CSS. Was wäre denn, wenn man CSS in React reinkriegen wollte? Wie würde man das tun? Netter Versuch, Herr Netzer, aber lassen Sie mal den Delling jetzt das mal richtig machen.
Was man in React ja auch immer gerne benutzt hat, ist CSS und JavaScript. Hä? Aha. Ja, so. Wir haben beide Delling-Gene in uns. Ein bisschen, ne? Wir sind halt auch alt genug für den Scheiß. Pass auf. CSS-Module-Scripts geht jetzt auch in Firefox. Kann man also aus seinem ECMAScript-Modul CSS importieren, Import, Styles CSS, Width, Type, CSS, kriegt ein CSS-Style-Sheet daraus, bam, bam, bam, fertig. Super Kiste für komponentenbasiertes Arbeiten.
Das war ja das Ding, wo Chrome früher Assert hatte, glaube ich. Und das dann quasi im Standard-Width wurde und Chrome beides unterstützt. Unterstützt T. Ich habe letztens getestet, sie haben das Azure tatsächlich aus Chrome rauskratzen können. Ja, super. Da wäre meine Frage nur gewesen, also bedeutet der Support von Chrome für diese Dinge, dass der automatisch alle, also mit allen Mime-Types, die man so üblicherweise kennt, auch umgehen kann?
Oder ist das wieder eine andere Geschichte? Nein, das ist alles Special Cased. Ja. Okay. Also just gerade läuft hier auf Mastodon eine Diskussion. Lea Veru so von wegen, das ist ja alles Blödsinn, das ist alles gespecial-cased würde, weil pass auf, das Ding heißt ja Import-Attribute, dass du sagst, Import hast du nicht gesehen, from so und so, with, type und dann irgendwas. Und diese Types sind keine Minetypes, sondern das sind so Kisten wie halt JSON und CSS.
Das sind so die, die aktuell supported sind. Also anstatt Text-slash-JSON oder Text- oder Application-slash-JSON und Text-slash-CSS. Naja, was ist ein Minetypes? Was ist ein Minetype? Das ist einfach eine Konvention, oder? Es ist im Prinzip ein Identifikator. Du kannst dieses Teil interpretieren als dieses oder jenes. Also JSON solltest du vielleicht parsen, CSS in CSS-Parser werfen und so weiter. Aber was du ja normalerweise als Entwickler, als Entwicklerin willst, ist, du importierst das Ding als CSS und erwartest dann eben auch, ein JavaScript-Objekt zu bekommen, das vielleicht kein String ist, sondern ein Style-Sheet.
Du willst es als JSON importieren, du willst es vielleicht dann nicht auch manuell durch JSON-Pars schieben, sondern es sollte schon geparsst sein. Ja. So. Allein schon aus Performance-Gründen, weil Module, also ECMAScript-Module werden ja vom Browser dedupliziert und gecached. Und was gecached wird, sind nicht die Bytes, die importiert worden, sondern tatsächlich die evaluierten Ergebnisse. Sprich, wenn du jetzt eine JSON-File an sieben Stellen importierst, wird die einmal runtergeladen, einmal gepasst, aber du kannst die an sieben Stellen verwenden.
Hm? Ja, und mit CSS genauso. Und das willst du ja eigentlich haben. Und sie argumentierte jetzt hier gerade auf Mastodon. Auch das werde ich wahrscheinlich hier in die Links schmeißen müssen. Ist ja ein bisschen Blödsinn, wenn man nicht zuerst die Low-Level-Varianten baut. Und die sind auch spezifiziert. Import with type text. Das heißt, du kriegst dann, wenn du das mit CSS zum Beispiel machen würdest, würdest du ein String CSS kriegen und nicht ein Style Sheet.
Machst du einen JSON, kriegst du einen String, blablabla. Und eben falsch spezifiziert ist Import as bytes. Dass du halt ein Byte Array kriegst. Je nachdem, was du vorhast, kann das auch sehr nützlich sein. So. und sagt halt eben, warum dieses ganze Special Cases und nicht einfach die basalen Dinger. Und man kann es ja selbst halt zu, keine Ahnung, CSS machen. Aber da ist halt eben dieses Deduplizieren ganz, ganz zentral. Weil stell dir halt wirklich vor, du hast irgendwie, keine Ahnung, du baust einen Frontend mit Web Components.
Und du machst halt eben dann deine Adopted Style Sheets und deinen Shadow Roots, da willst du über das CSS reinladen. Und eine häufige Frage, die mir gestellt wird, ist ja, ich habe einen so einen Style Sheet für meine ganze Webseite, ich nutze trotzdem Web-Components mit Shadow DOM, aber eigentlich will ich den styleisolierenden Aspekt von Shadow DOM gar nicht haben. Ich will die gleichen Klassen im Innenaufbau verwenden wie im Außenaufbau. Wie mache ich das?
Was du halt jetzt machen kannst, wenn du dieses CSS einfach so importieren kannst und die Kosten für das Importieren und das Parsen eines Style Sheets fallen exakt einmal an für deine ganze Applikation. Und weil die Adopted Style Sheets sich ja auch Instanzen von CSS-Stylesheet-Objekten teilen, fällt ja auch der Memory-Verbrauch nur einmal an, spricht eigentlich nichts dagegen, in jede winzige Furzkomponente und sei es halt wirklich nur ein Button, alle Styles reinzutun, weil es halt eben...
Es hat exakt null Grenzkosten, nachdem du zum ersten Mal diese Style-Sheets importierst. Genau, in deinem Beispiel hätte das dann der Browser quasi schon für die Rumpf-Seite getan und dann liegt das schon fertig da rum. Das ist jetzt die Frage, warum ich das auf die Agenda bringen wollte mit dir, Herrn Performance-Past. Ich würde ja normalerweise, wenn ich jetzt eine normale Webseite baue und ich würde halt so Islands of Reactivity machen, ich mache halt das meiste, was ich machen kann mit HTML, CSS und so ein bisschen jQuery-Style-JavaScript und die komplizierten Dinge packe ich in Web-Components mit komplexem Inneren erleben.
Dann will ich ja irgendwie 50% Verteilung haben zwischen meine Realität findet in klassischen Webseiten statt mit HTML und CSS. Und auf der anderen Seite habe ich halt eben meine Web-Components. Und das Problem ist, normalerweise würde ich ja annehmen, der Browser ist darauf optimiert, CSS zu laden, indem ich das per Link-Element in die Webseite einbaue, meinen Style-Sheet da reinwerfe. Aber das ist ja außerhalb von meiner JavaScript-Welt. Das lädt ja nicht wie ECMAScript-Module.
Die Ressourcen werden sich nicht in dem gleichen Sinne geteilt. Das heißt, was du jetzt gerade gesagt hast, würde tatsächlich nicht stattfinden. Ich hätte die Rumpfseite und ich hätte halt eben die JavaScript-Welt. Innerhalb der JavaScript-Welt werden sich die Ressourcen geteilt, aber die Rumpfseite existiert halt anders, solange ich die halt eben mit Link-Elementen befülle. Aber was wäre denn? Es gibt ja Link-REL-Prelod zum Beispiel und dann gibt es ja Link-REL-Module-Prelod in dem Fall. Ja.
Weißt du, ob man das vielleicht auch für andersartige Module als JavaScript-Module benutzen könnte? Dann müsste man wahrscheinlich auch also eigentlich theoretisch misst, bräuchte man dann ja auch so ein Width-Attribut im HTML oder sowas also so wie S bei dem klassischen Preload auch immer S, Style Sheet S, Font, das wäre vielleicht wäre dann so ein Ausweg daraus also aber jetzt nur so aus meiner. Ja, also ich kann jetzt erstmal so aus der MDN-Seite das nicht erkennen, wie das funktioniert und wie das interagiert mit den CSS-Module-Scripts oder halt eben auch, du kannst ja auch JSON importieren, hast du nicht gesehen.
Und der Spezifikationstext ist recht dicht, weil das ist jetzt so das Ding, auf dem ich halt so rumsitze. Wenn ich jetzt wirklich sage, ich baue eine normale Webseite, eine Link, Style Sheet, ganz normal, CSS-Pattern mit irgendwie BAM oder so, no-brainer, passt schon. Oder ich baue eine Single-Page-Application mit Web-Components, mache ich eben alles in JavaScript mit den CSS-Modules-Scripts, auch easy. Aber was ist, wenn ich halt eben diese Mischform hast? Was ich halt für das eigentlich Optimale halte, weil es gibt halt viel, was mega interaktiv ist und viel, was es halt nicht ist.
Genau, das ist ja dieses Interactive-Island-Konzept. Also das, was ich ja auch bevorzuge, dass du, das meiste kann im Grunde statisch sein, dann gibt es eben so Inseln in diesem statischen Content, die dynamisch sind. So sieht es aus. Und dafür fehlt mir halt jetzt noch die performance-technisch optimalste Lösung. Und deswegen bringe ich das mal so auf die Idee und dieses Model-Preload. Ich kann es mir nochmal angucken mit diesem Link-REL-Preload-Module.
Ob da was geplant ist dafür. Das wäre eigentlich die richtige Sache, wo das dann stattfinden müsste. Genau, also einerseits gucken, ob das funktioniert, ob ein Module-Preload mit einem Verweis auf eine CSS-Datei funktioniert in einem Browser, der halt diese CSS-Module-Scripts kann. Und wenn nicht, was es da sonst so an Mitigation-Strategien gibt, wie groß dann der Impact wäre. Also wie schlimm ist es denn jetzt wirklich, wenn ich hingehe und ich lade das Style Sheet für meine Webseite halt eben via JavaScript?
Ich meine, Document hat auch ein Adopted Style Sheets Array. Also du meinst, du würdest dann sagen, okay, wenn ich schon diese Interactive Islands habe, dann wähle ich direkt den Weg quasi nur über Module Imports, also auch auf meiner Rumpfseite. Und dann, genau, dann macht der Browser dieses Deduplizieren, genau, aber es könnte, aber, genau, also ich glaube, die Konsequenz ist tatsächlich, dass, ich glaube, dass das Style Sheet einfach dann später da ist auf deiner Home-Seite trotzdem. streamen.
Genau, es ist davon auszugehen, dass es später ist, aber wie viel später? Ja, ne? Weil du könntest ja theoretisch in den Head als allererstes direkt nach dem Car-Set oder was auch immer, kannst du ja einen Script-Tag machen, also ein synchroles Script-Tag, was ich ja vor kurzem erst gelernt habe. Man kann ja aus einem synchronen Script, was kein Modul ist, trotzdem das Import-Keyword in seiner Funktionssyntax nutzen. Das heißt, du könntest, bevor der HTML-Parser mit dem Head fertig ist, schon anfangen, dieses CSS-Modul zu laden.
Da kriegst du ein Promise raus, machst du Then, kriegst den Style Sheet, Document Adopted Style Sheets, Push und dann ist das da drin. Also du kannst aus einem Nicht-Modul kannst du Imports ausführen oder was? Genau, du würdest sozusagen den Prozess des CSS-Ladens starten, während der HTML-Parser noch damit beschäftigt ist, dein Dokument zu verarbeiten. Ja, man wusste nicht, dass das geht. Ich dachte, Imports kannst du aus Modulen heraus machen.
Das dachte ich auch, bis ich einfach mal so durch die HTML-Spezifikationen gescrollt habe, weil ich an der Aldi-Kasse stand und die Schlange war lang. Klar, was soll man da machen? Alle halten mich für irre, ich finde das super. Und dann finde ich halt ein Beispiel, wo die so was machen wie A-On-Click, also so ein Inline-Event-Händler-Gedings. Und dann steht da drin, Import hast du nicht gesehen, so ein Modul. Und ich so, wait, what? Und dachte erst, das ist irgendwie spezielles Handling irgendwie im On-Click-Händler, dass das irgendwie als Modul ausgeführt wird, wenn der Mond richtig steht.
Aber die Wahrheit ist, ich kann aus einem synchron blockierenden Browser-Script Module laden über diesen Umweg. Und, ja, okay. Ist das dann dieses, ist das im Grunde so ein Dynamic Import? Es ist der Dynamic Import, genau. Du kannst aus einem Nicht-Modul, da kannst du keinen statischen Modul-Import machen, aber einen dynamischen Modul-Import. Und ich dachte halt eben, damit kommst du ja, das Problem ist ja wirklich, wenn du mit JavaScript deine CSS lädst, reißt du dich halt in der Startaufstellung beim Formel-1-Rennen erstmal ganz hinten an.
Ja, genau. Das ist wie, wenn der Motor abgewürgt würde erstmal kurz. Du fängst einfach ganz hinten an. Also beim Start hast du erstmal verloren, weil Link-Element ist halt am schnellsten, der HTML-Parser checkt es sofort und du hast ja auch diese hier Prescanner und Gedönse, die machen ja im Prinzip ein Racklacks auf dein Dokument und sagen, das sieht aus wie ein Style-Sheet, ich fang schon mal an. Und darum geht es halt. Und da wäre vielleicht wirklich so ein Modul-Preload, genau das Ding, was man halt wirklich macht, um den Abstand, wie groß der auch immer ist, das müsste man halt mal quantifizieren, so weit zu reduzieren, dass man am Ende kein Problem mehr hat.
Der Code, den man schreibt, sieht dann halt eben komplett Banane aus, weil man halt irgendwie sagt, ich habe halt hier so ein Islands of Reactivity-Ding und meine Hälfte, die Hälfte von meinem Content ist statisch, aber jedes CSS kommt ausschließlich über JavaScript da rein. Aber man kann es sich ja auf die Weise dann begründen, weil ansonsten zahlt man halt eine CSS. dann quasi nach hinten raus, überholst du dir dann wieder die anderen sozusagen.
Genau, weil das Ding ist halt, diese beiden Style-Sheet-Welten sind halt komplett inkompatibel zueinander. Ein normaler Style-Sheet, der mit normalen Link-Elementen geladen wird, den kannst du nicht in den Top-Lit-Style-Sheets stecken. Ja. Weil das halt eben Old-School-CSS ist, da drin kannst du auch so in CSS-Add-Imports haben, die ja bei CSS-Modul-Script nicht erlaubt sind, weil die halt einfach fundamental anders funktionieren. Das heißt, das sind zwei Parallelwelten, so ähnlich wie hat Module und Scripts eigentlich sind.
Abzüglich halt eben dynamischer Import aus dem Script heraus. Und das wäre halt mal ganz spannend, weil das würde halt dazu führen, dass wir hier, möglicherweise mit unserem präferierten Ansatz, Hälfte startet, Hälfte nicht, dann am Ende nicht nur deshalb gewinnen, weil wir halt per Default schneller sind als die Sina-Page-Applications, die halt eben das Rad komplett neu erfinden müssen, aber möglicherweise können wir uns 50% des Rades neu erfinden, auch wenn irgendwie 10% der Kosten runterkochen.
Und dann sind wir so flott wie eine hypothetische JQuery-Spaghetti-Anwendung, die aus irgendwelchen magischen Gründen wartbar ist und alles toll macht, aber halt wirklich maximalen Geschwindigkeitsvorteil bietet. Und weißt du, warum das alles komplett für den Arsch ist, was wir jetzt gerade besprochen haben? Ich weiß es. Du weißt es, ne? Safari kann das nämlich nicht. Ja. Ah, es ist das Problem. Genau, also es ist jetzt neu in Firefox, kann das ja schon, haben wir eben darüber gesprochen, und Safari supportet das noch nicht.
Die sind ja immer sehr schweigsam, was ihre Pläne für die Zukunft angeht. Genau, ich will nur sagen, ich bereite mich mal trotzdem auf eine Zukunft vor, wo das geht. Das heißt, für meine Islands of Reactivity mache ich dann sowas wie, ich habe da Importstatements drin stehen, die laden meinen CSS und dann nutze ich halt irgendwelche Bundler-Features, damit das als String importiert wird. Ich wandle es manuell in den Style Sheet um, stecke ich in die ganzen Adopted Rules.
Dann zahle ich nicht extra mit Requests, sondern nur mein JavaScript wird halt größer, weil das CSS quasi in den Byte-Payloads zweimal drin steht. Was jetzt nicht toll ist, aber auch keine Katastrophe ist, wenn das CSS einigermaßen kompakt ist. Und wenn dann eines Tages Safari das kann, schmeiße ich halt den Bundler-Aspekt davon raus und bin dann schneller geworden, indem ich quasi nichts tue. Das ist so meine Vorbereitung auf die neue Welt. Das ist ein super Stichwort um eins.
Wir haben noch so ein paar Rapid-Fire-Themen ganz hinten. Also Safari unterstützt jetzt auch Z-Standard-Kompression und vielleicht kann der das ja dann in deinem Stream, du nutzt ja mindestens HTTP 2, vielleicht sogar 3 und vielleicht lässt sich da mit Z-Standard-Kompression sozusagen die Duplizierung vermindern. Ja, aber das Problem ist ja, Safari unterstützt Z-Standard. Was machen die anderen Browser? Also Chrome unterstützt das auf jeden Fall auch. Ah, okay.
Chrome kann ja auch noch, ich weiß nicht, bei den anderen Browsern weiß ich nicht genau, die können ja auch diese Dictionary-Kompression. Wo du quasi ein bestimmtes Dokument referenzieren kannst als Dictionary und dann quasi alles wegkomprimiert wird, was eh schon in Dictionary drinsteht. Genau, bei Firefox weiß ich nicht, wie das mit Z-Standard aussieht. Aber es war jetzt nur so eine Sidenote, also Safari 26.3, der jetzt im Februar released wurde, der hat auch diesen Z-Standard-Kompressionsalgorithmus in Meta erfunden hat.
Und der sehr, sehr, sehr, sehr schnell komprimiert und auch ziemlich effizient. Ja, ist erstaunlich, was man so kompressionstechnisch hinkriegt, wenn man mal die 80er hinter sich lässt. Haben wir ja auch gerade nicht in der Themenliste drin, aber hier so Compression-Streams. Firefox kann da jetzt Brotli drin. Kann sonst kein Browser, deswegen ist das von franklicher Nützlichkeit. Aber weißt du, was das halt eben auch echt bräuchte, diese API?
Die bräuchte halt eben auch Dictionaries. Ja, ach, den kommen bestimmt. Es ist gar nicht mal so einfach, das zu sagen, weil die API ist ja dergestalt, dass es mehr oder minder so funktioniert. Du sagst halt, ich hätte gerne Compression oder Decompression-Stream für Algorithmus identifiziert durch String. Und du würdest ja wahrscheinlich pro Algorithmus unterschiedliche Optionen mitgeben können, weil nicht notwendigerweise kann ja jeder Algorithmus Dictionaries.
Also einfach zu sagen, es existiert eine Option namens Dictionary, wird wohl nicht hinhauen, sondern du müsstest halt eben ein Back of Options pro Algorithmus definieren. Und das ist alles ziemlich knifflig, weil wird das alles unterstützt? In den Browsern ist das da immer so eingebaut, dass die wirklich alles unterstützen. Das ist alles sehr, sehr, äh, habe ich, äh. Aber was mit so einem Dictionary alles ging, meine Güte, ich komprimiere mit dem D-Zeug ständig JSON-Objekte.
Das heißt, von 90% aller Strings weiß ich, dass die da drin vorkommen im Payload. Dafür ein Dictionary anzugeben, wäre halt einfach mal der Hammer. Ja, aber das kannst du ja in deinem Webserver, du baust ja quasi, das Dictionary kannst du ja selber erzeugen. Du könntest ja ein JSON, quasi einen Muster-JSON haben, das du das Dictionary ablegst und dann kannst du es ja per zum Beispiel per HTTP-Header kannst du dann den kompatiblen Browser sagen, so hey, hier wäre ein Dictionary, wenn du möchtest.
Ja, ja, aber nicht in den Compression-Streams, weil die haben ja nichts mit HTTP-Headern zu tun. Ist ja bloß eine JavaScript-Adeale. Ja, nee, genau, da gibt es nicht. Und das ist halt das Ding. Ich will halt so gerne JSON-Objekt rein, gib mir Byte-Array, Base64-URL draus, in die URL reinschreiben, parzack, brauche ich kein Backend. Hast du instantan share-barer Links. Ja. Allein haben wir halt noch. Jetzt haben wir so viele tolle neue Sachen, aber es fehlt immer noch so viel.
Tja, ist ja immer so. Haben wir denn noch weitere tolle neue Sachen, Shep? Ja, haben wir. Oh, das ist super, Shep. Kannst du mir mehr davon erzählen? Hup, hup. Genau, wir sind da letztens schon mal drüber gestolpert, weil ich glaube, der Safari unterstützte das in einem Nightly-Bild oder sowas in der Art. Genau. Also alle Browsers unterstützen mittlerweile jetzt, und Firefox ist der letzte, der dazugekommen ist, die Navigation-API. Die im Grunde die History-API ablöst und die so Patterns ermöglicht, dass man eben auf ein Navigation-Event horcht und das Event dann abfangen und canceln kann, so ein bisschen wie das beim Service-Worker der Fall ist.
Also das ist im Prinzip eine primitive, die man nehmen kann, zusammen mit dem URL-Pattern-Matching, der URL-Pattern-Matching-API, um einen kleinen-zeitigen Router zu bauen, wie wir sie eben aus SPAs kennen. Ist im Prinzip das, was die History-API eigentlich hätte werden sollen. Ja. History API 2.0, da ist ja alles dran irgendwie so ein bisschen seltsam und passt nicht so richtig gut und will man ohne Abstraktionslayer nicht anfassen und im Prinzip sind das hier die Lessons learned in eine JavaScript API gegossen.
Ja, genau. Und ein Grund, warum das vielleicht jetzt in Firefox gelandet ist, könnte sein, dass es Teil der Interop 2026. Des Agreements zwischen den Browsern ist, dass das eben eine Technologie ist, die sie im Laufe dieses Jahres eben alle shippen möchten. Aber wahrscheinlich ist da schon Vorarbeit geleistet worden, weil das Jahr ist ja noch jung und das hätten die auch noch auf die längere Bank schieben können. Ja, ich meine, es sind ja noch nicht alle Features in allen Browsern drin.
Also ich meine, so grundsätzlich ist das meiste da drin, aber da hängen ja auch noch so Interaktionen mit View Transitions dran. Da hat jetzt nicht jeder Browser jeder API, aber zu 99 Prozent ist es drin. Also bei View Transitions kommt ja auch ständig immer noch was, also auch in Firefox hatten wir gesehen, aber das sind dann eben, das ist halt so Feintuning und ich glaube Multipage oder Cross-Document View Transitions, die fehlen noch in, also ich glaube, die kann der Chrome bisher nur, oder?
Ich meine, da auch letztens was gelesen zu haben, warte mal, hold my beer, scroll, scroll, scroll, im Firefox ist es nicht drin, aber da ist ein Sternchen, was sagt der Bug Report. Warte mal. Implement CSS View Transitions 2. Es ist noch open. Scroll, scroll. Okay, da tut sich nicht wirklich viel. Genau, ich glaube, das ist, lass mal schauen, also View Transitions. Wir sind auch in Interop 2026 drin. Ah ja. Genau, da sind auch die Cross-Document View Transitions mit, also Teil des Ganzen. Ja, dann wird es das gewesen sein, was ich gelesen habe.
Okay, aber dann kommt es ja zumindest noch dieses Jahr. Das heißt, wenn wir alle keinen Mist bauen, kriegen wir noch was davon mit. Genau. Das wäre auch dann zur Navigation API erstmal alles, oder? Ich denke. Das Problem ist halt, es ist dringend notwendig gewesen und jetzt, wo es da ist, denkt man sich halt eben, es ist wie eine neue U-Bahn-Linie. Mensch, warum gab es die nicht schon immer? Okay, ich fahre jetzt damit. Und schon ist es halt irgendwie normal und du guckst die ganze Zeit nur auf dein Telefon und so sollte es sein.
Das wird irgendwie in die Frameworks eingebaut werden. Keiner kriegt mit, dass es existiert und alles ist gut. Genau, und die Frameworks können sich in Zukunft vielleicht sparen, Link-Elemente für diese Dinge bereitzustellen. Da hängt mittlerweile ja dann immer an den Dingen so viel mehr noch dran. Ja, wahrscheinlich wird es die immer noch geben, aber nicht, weil sie noch notwendig sind, sondern einfach damit quasi man den alten Code weiter benutzen kann.
Man darf ja bei Frameworks nicht vergessen, dass es ja immer ein Zusammenkommen aus Code, den man benutzt und schreibt. Und Konventionen, so werden Sachen gemacht. Und nur weil jetzt halt der Code weniger Volumen hat, weniger nötig ist, ist trotzdem immer noch da die Konvention, die man sich dazu ausgedacht hat. Also werden die da weitestgehend von unbeeinflusst bleiben, ist meine Hypothese. Ja, genau. Aber zumindest von jetzt an fällt der Grund weg, warum es das gibt.
Ja, und wenn man halt so seltsame Gestalten sind wie wir zwei, die sich eh alles selber bauen, haben wir es leichter. History API ist echt der Endgegner. Das stimmt. So, dann haben wir Safari, aber eben Technology Preview, heißt aber, also es kommt bald, hat Customizable Select per Default aktiviert. Also es wird schon hinter Flag, aber bald kommt es dann auch tatsächlich aktiviert. Und genau, bisher wird das, glaube ich, nur in Chrome unterstützt, aber Apple ist da auch generell bei, also nicht nur bei customizable select, sondern die haben da auch die Führung, was diese Spezifikation angeht, die alle Formularelemente betrifft, übernommen und pushen da richtig hart und genau der erste Schritt sind eben dann die customizable selects.
Und folgen werden eben dann nach und nach alle anderen Input-Typen. Und genau, das Customizable Select kann man ja mit Appearance-Base-Select, da kann man dann sozusagen Opt-Innen rein tappen. Und das wird es wahrscheinlich dann für die verschiedenen Inputs in der Form dann geben, nach und nach, also, keine Ahnung, Base-Date-Picker oder Date-Time oder wie auch immer. Und Base, was gibt's noch, was irgendwie ätzend ist, Base Checkbox meinetwegen. Oh ja.
Genau, und dann das Ziel ist eben am Ende nur noch ein Appearance-Doppelpunkt Base, also quasi so ein Shorthand zu haben, der dann, egal welche Art Input-Elemente es ist. Alle auf dieses Base oder dieses andere Modell umstellt Und die Base-Appearance ist ja so, dass du quasi sowas wie so ein relativ funktionales und okay aussehendes, aber total neutrales Input-Element bekommst und du einfach sehr viel mehr Handles bekommst, wo du quasi mit deinem CSS dann reingreifen kannst und du hast halt einfach absolute Gestaltungsfreiheit. Ja.
Ich habe mich damit jetzt noch nicht im Detail befasst, aber vielleicht kannst du mir das sagen. Wie wirkt sich denn jetzt so ein Customized Select auf meinem Mobiltelefon aus? Da bin ich es jetzt ja gewohnt, ich drücke da rein und dann kriege ich halt so das Betriebssystem eingebaute Multi-Select-Ding vorgesetzt, das ich da habe. Was ja irgendwie Sinn macht, weil ich ja ganz andere Zeit-Constraints habe. Oder ein Date-Picker ist ja genau das Gleiche.
Also so ein Input-Type Date-Time auf meinem Mobile Firefox zum Beispiel ist ja tatsächlich nicht ein Wichert, sondern das ist ein zweistufiger Prozess, wo ich erst den Tag auswähle und hinterher eine Zeiteingabemaske bekomme. Wie malte man sich das denn aus? Und ich meine, ist jetzt ein unglücklicher Zeitpunkt der Aufnahme, weil der Herr Zuckerberg jetzt ja gerade das Metaverse in den Orkus gesteckt hat. Du meinst, wie das auf so einer Brille läuft?
Ja, das ist ja das Ding. Keiner hat ja hervorgesehen, dass das iPhone um die Ecke kommt und trotzdem war ein Formular mit dem iPhone ausfüllen kein Problem, weil die Webplattform halt so agnostisch war und so allgemein Input Requirements formuliert hat. Und die Spezifikationen sagen ja immer nur, ein Input-Type-Date ist ein Eingabefeld für Datums und Zeitangaben. Und jeder Browser kann dann zum Glück und oder leider hingehen und das Element so gestalten, wie das für richtig hält.
Genau. Ja, da ist alles für und wieder. Ich versuche es gerade. Ich glaube, dass du, naja, hier haben wir das. Ich glaube, dass das auch auf Mobilgeräten funktioniert. Was heißt funktioniert? Also auf Mobilgeräten bekommst du nicht, genau, ist auch so, bekommst du nicht mehr das Betriebssystem-Interface. Okay, sondern dann muss ich halt eben mit meinem winzigen Bildschirm-Supermarkt-Android-Telefon das ertragen, was Mr. Riesen-iPhone in seiner Web-Klitsche von Cloud Code sich hat zusammenfrickeln lassen.
Genau, aber der kann ja mit Anchor-Positioning auch viele Dinge machen. Das glaube ich erst dann, wenn ich sehe. Ja. Also ich glaube, du musst es so machen, weil wenn der CEO mit seinem iPhone sich die Seite anguckt, die du gebaut hast, und dann sieht das eben nicht so aus wie in den Figma-Entwürfen, dann findet der es halt kacke. Und das heißt, du fängst dann doch wieder an, dir ein komplett eigenes Select zu bauen, damit der Chef irgendwie glücklich ist.
Absolut. Darum musst du in dem Fall, weil du ja auch aktiv sozusagen da rein tappst, das ist ja dann so, hier be dragons, so ja, ich weiß Bescheid, danke, ich mach das, ich weiß, was ich tue. Ähm, Dann muss das eben dann auch auf Mobilgeräten funktionieren. Ja. Und wir sind ja auch, glaube ich, ganz gut im Saft, was so responsives Interface-Design angeht. Nach, keine Ahnung, responsive Web-Design war es 2009. Wir sind gut im Saft. Hast du mal auf deinem Mobiltelefon den Adblocker ausgemacht?
Ich habe ja Chrome, da darf ich ja gar nichts installieren, derartiges. Okay, geh mal auf irgendeine Nachrichten-Webseite. Nee, die finde ich alle schlimm, ist ja klar. Wir sind gut im Saft, hast du gerade gesagt, was im weitesten Sinne das Webdesign für Mobile angeht. Und ich mache irgendwie auf dem Kollegen hier random News-Webseite aus. Okay, Mobiler Firefox. Aber du hast vergessen, die News-Webseite ist ja nicht für dich gebaut. Ich weiß. Die News-Webseite wird für Werbung gebaut und du darfst dir die dann auch noch angucken.
Ah, genau. Ja, die Werbung, nicht die Seite. Ja, klar. Also wenn du hier wirklich irgendwie den Guardian oder so ein Gedöns aufmachst und du hast einen Adblocker aus, oben irgendwie, hier unterstützt uns, unten unterstützt uns und dann hast du den da. Die geht ja fast noch. Also gibt es da so deutsche Publikationen an der Fokus und NTV oder Automotorsport, Alter, Falter. Aber ich meine, okay, da sind halt dann die Autoplay-Videos dann. Ich meine, selbst bei denen, wo du was Besseres erwarten würdest, ist es so, du gehst auf die Seite und du siehst keinen Content von Autopop-Ups.
Das stimmt. Weil oben unterstützt uns unten irgendwie hier Cookies und Gedöns. Deswegen habe ich auch ein Abo für eine solche Publikation, die ich sehr gerne lese. Und dann habe ich auch das Pure-Abo, dann ist da wirklich nichts drin. Alles, was du sagst, ist korrekt und richtig und gut und schön. Nur die Aussage, wir sind mit unserem mobilen Webdesign gut im Saft, da gebe ich maximales Kontra. Also unsere Hörenden sind ja wohl super im Saft.
Wenn sie das denn dürfen. Aber möglicherweise arbeiten die auch in irgendeinem Kontext, wo halt von oben herabdiktiert wird. Wir brauchen diesen Cookie-Banner, wir brauchen diese Werbung, hast du nicht gesehen, Autoplay-Video ist voll super, mach das X kleiner, mach unser Logo größer, aber das X kleiner, lauter so Kisten. Ja, aber ich glaube, dann hilft das mit dem Select irgendwie auch nichts mehr. Ja, das ist sicher, aber ich meine, okay, klar, die Mülltonne brennt.
Aber muss man jetzt wirklich zusätzliches Material ins Feuer geben, ist die Frage. Oder kann man einfach sagen und so, okay, wärme ich mir halt die Hände. Feuersödern, meinst du? Das Feuersöder? Der will doch eher Atomkraft haben, oder? Ja, genau. Also okay. Ich wirf gern ein paar Brennstäbe rein. Ich wollte gerade sagen, mein Plutonium würde ich jetzt vielleicht auch nicht reinwerfen. Das macht es auch nicht besser. Halt auf eine andere Weise schlimmer. Ich glaube, die Metapher biegt sich ein bisschen. Wollen wir...
Genau, der nächste Punkt ist einer für dich, weil wir in der Vorbesprechung irgendwie, wir haben was gefunden, wo du gesagt hast, ja, ist okay, müssen wir aber nicht bringen und dann stellte sich heraus, dass ich hinsichtlich des Konstrukts der JavaScript-Iterators etwas unterbelichtet bin und deswegen nehmen wir diesen Blog jetzt hier rein und du erzählst uns mal was über Iterators. Also erstes bist du nicht unterbelichtet. Ja, hier und da halt schon ein bisschen. Nein, nein, nein, nein, nicht was JavaScript angeht, sondern über diesen ganzen Themenkomplex hat wirklich gar keiner irgendeine Ahnung davon und alle gucken mich halt eben an, wie ein Wal, der zum ersten Mal ein U-Boot zieht, wenn sie mich mit den Dingern rumschonkieren sehen.
Genau, also ich weiß, also Iterators, der Name sagt es, das ist halt so, worüber man drüber loopen kann. Äh, genau. Gibt's ja irgendwie, es gibt das Iterator-Protokoll, das weiß ich noch. Da gibt's ja bestimmte quasi, du kannst jedes Ding in Iterator umwandeln, das weiß ich, indem das bestimmte Properties hat, und irgendwelche Dinge zurückgibt, wenn es fertig ist und so. Genau, und ich hatte gedacht, dass du über jede Art Iterator mit forEach drüber gehen kannst. Hast du gesagt, das ist überhaupt nicht der Fall?
Genau, ich glaube, das ist es. Und Iterators, was gibt es für Iterators? Ich weiß es nicht. Okay, pass auf, fangen wir mal an. Also erstmal, das Ding, worum es hier geht, heißt Iterator Zip. Und wenn ich mal ein MDM zitieren darf, bla bla bla, ist eine statische Methode auf der Iterator, auf dem Iterator Objekt. Das aggregiert Elemente aus verschiedenen iterierbaren Objekten und so weiter. So, jetzt ist die Frage. Dieser Satz, der spricht davon, dass ein Iterator-Objekt zurückgegeben wird, das wird produziert, aus verschiedenen Iterable-Objekten.
Ja. Iterator versus Iterable. Was ist was? Ne, da fängt es schon an. Also, es ist ja ein Iterator einfach quasi ein quasi von dir erschaffenes Ding, das diese Interfaces eben bereitstellt, die ein Iterator haben muss, während die anderen, die Iterables, vielleicht Build-Ins sind im Browser, vielleicht sowas wie, keine Ahnung, ob das stimmt, aber Noteless und Arrays oder sowas, und die eben auch integriert haben das Iterator-Protokoll oder was soll man. Fast perfekt.
Also unter praktischen Gesichtspunkten ist es genau so. Aber ein Iterable ist ein Objekt, irgendeine Datenstruktur, was auch immer. Und das hat einen speziellen Magic Key, ein Symbol, namens Symbol.Iterator. Und wenn man das aufruft, dann bekommt man einen Iterator zurück. Ein Hitterable hat eine Methode, um Iterator zu produzieren. Die Idee dahinter ist, die Datenstruktur hat halt eben ein Standardprotokoll implementiert. Diese Datenstruktur enthält irgendwelche Werte und gibt halt ein Objekt zurück, das ein Standard-Interface implementiert.
Und das ist etwas, das dann zum Beispiel konsumiert werden kann von so Mechanismen wie eine For-Off-Schleife und Ähnlichem. Das ist so die Idee. Genau, aber wichtig ist, dass es eine For-Off-Schleife ist. For-in oder so, das ist wieder was anderes. Ja, genau. Eine For-Off-Schleife nimmt auch kein Iterator notwendigerweise, sondern ein Iterable. Also eine For-Off-Schleife erwartet, dass du ein Array reinschmeißt mit diesem Magic Key, wo dann was aufgerufen wird und auf dem Ding operiert es dann de facto.
Aber beides sind halt im Prinzip bloß Interfaces. Das heißt, wenn du richtig fancy sein willst, kannst du dir auch ein Objekt bauen, das ein Iterable-Iterator ist. Das heißt, es implementiert beide APIs gleichzeitig, hat also diese Funktionalität, um in eine Voraufschleife reingesteckt zu werden. Und wenn die Voraufschleife sagt, gib mir den Iterator, dann hat das Ding einfach die Implementierung return this, weil es halt eben das andere Interface auch implementiert.
Es ist also nicht so sehr, dass das eine Art Basistyp ist, irgendwie so ein gemeinsamer Vorfahre von allen Dingen, die irgendwie listenlike sind, sondern es ist wirklich einfach nur eine Funktionalität, die viele verschiedene Objekte implementiert haben können. Aber es fühlt sich so ein bisschen an, als würde es so zu einer Art Basistyp degenerieren. Ja, also eine Art Prototype. Genau, so fühlt es sich an, ist es streng genommen nicht. Aber das ist, was du hier rauskriegst. Und deswegen ist halt eben, warum erzähle ich das alles? Naja, Iterator Zip nimmt halt verschiedene Iterables.
Also Dinger, die du auch in Vor-Affschleife reinstecken könntest. Zum Beispiel Arrays, Strings, Maps, Sets, Dom, Lists. Dererlei. Ja, Strings kannst du einsetzen, weil er dann quasi Buchstabe für Buchstabe durch iteriert. Buchstaben gibt es nicht. Wir haben hier Unicode am Start. Oder Characters. Characters gibt es nicht. Wir haben hier Unicode am Start. Dann halt das. Entities? Ich weiß tatsächlich gar nicht, wie die Kategorie heißt, die du da rausbekommst.
Weil es sind ja nicht Grapheme. Also Grapheme ist ja, was du als Zeichen wahrnimmst. Wenn du zum Beispiel hingehst und du machst irgendwie ein Slack-Daumen-Hoch-Emoji mit Hautfarbe, sind das ja zwei Emoji aufeinander folgend, die zusammen gerendert werden von Betriebssystemen, die das können. So wie eine Ligatur im Grunde. Genau. Es ist keine Legatur, aber es funktioniert von der Idee her wie eine. Und das ist ja, was man als Graphencluster wahrnehmen würde.
Also das ist, was ein Graphencluster ist, was Max Mütze als Zeichen bezeichnen würde. Und das kriegst du tatsächlich von dem Iterationsmechanismus von Strings nicht, sondern der würde dir dieses spezifische Konstrukt zerteilen in Daumenhoch- und Hautfarbenmodifikator. Das heißt, für dieses eine Emoji würdest du zwei Dinge kriegen, was aber schon mal besser ist, als wenn es die Codepunkte geben würde, weil dann würdest du ja vier bekommen. Die Surrogate-Pair, die zwei Code-Punkte für Daumen hoch und die zwei Code-Punkte für den Hautfarben-Modifikator.
Ist alles schrecklich kompliziert. Strings sind ein schlechtes Beispiel. Sagen wir, du schmeißt da rein ein Array und eine Notelist zum Beispiel. Ja. So. Die beiden Dinger haben ja erstmal per se nicht viel gemeinsam, außer dass sie konzeptionell Listen sind. Mhm. Und dass sie halt eben diesen Iterationsmechanismus implementieren. Und was halt eben die iterator zip rausgibt, ist halt eben der aggregierte Inhalt der beiden Elemente mit einem Objekt, das ein Iterator implementiert.
Das heißt, das, was da rauskommt, kannst du noch nicht mal hernehmen und so unmittelbar in so eine V-Off-Schleife reinschmeißen, sondern du könntest halt eben diesen Iterator nehmen und sagen, okay, ich baue jetzt aus dir ein neues Array zum Beispiel. Okay, also würdest du dann Array from und die sind dann von diesem Iterator. Ja, genau. So im Prinzip würde man das machen. Um nochmal kurz auf diese SIP-Funktion zu kommen, die würde dann wahrscheinlich sowas machen wie 1. Array-Eintrag, 1.
Notlist-Eintrag, 2. Array-Eintrag, 2. Notlist-Eintrag, sowas? Scroll? Nein, das nicht. Das ist tatsächlich nur ein Aneinanderhängen, wenn ich das jetzt gerade richtig sehe. Genau. Und du würdest halt einen Iterator rausbekommen mit halt, der enthält dann die Arrays mit den Inhalten aus den Itterables, die da reinkommen. Also, du schmeißt also rein diese beiden Elemente und sie werden halt sozusagen dann in Reihe gesetzt mit Arrays drin und dann kannst du das Ding iterieren, in Array verwandeln, flatten, was auch immer. Das ist so das Ding.
Aber was halt eben dazu wichtig ist, dass du dich halt eben in diesem Spannungsfeld der verschiedenen Objekte mit diesen verschiedenen Interfaces da zurecht findest, weil du würdest vielleicht erwarten, so eine SIP-Operation, dass die auf dem Array existiert. Tut es aber nicht, weil dann würde es ja nur mit Arrays gehen und vielleicht willst du ja auch deine Sets oder deine Notelists oder was auch immer zippen wollen. Oder irgendwie auch deine komplett selbstgebackene Datenstruktur. Warum nicht auch die?
Und das Schöne mit Iterator-Zip ist halt eben, weil es auf diese Low-Level-Ebene geht, ist es halt kompatibel zu allem, was halt grob als listenartig verstanden werden kann, um den Preis, dass du halt eben, wenn du drei Arrays reinsteckst, du halt nicht ein Array rausbekommst, sondern diese etwas allgemeinere Konstruktion, weil man halt eben nicht davon ausgehen kann, dass alle drei Inputs Arrays sind. Ja, okay. Was würde man dann verlieren? .length, gibt es das dann noch auf dem Iterator?
Nee, ein Iterator kann ja lazy sein. Ah ja, okay. Ein Iterator ist ja nur ein Objekt mit einem Interface. Das wäre das so mit dem Ding, was man verlieren würde. Ja, klar. Also es ist halt kein Array mehr. Kein Map, kein Filter, kein was auch immer. Und die Problematik ist natürlich auch da drin, weil Iterables lazy sein können und Iteratoren auch lazy sein können. Ist ja nicht gesagt, dass die endlich sind. Es ist ja bloß Implementierung einer Programmierschnittstelle und du könntest ja theoretisch sagen, jedes Mal, wenn ich hier aufgerufen werde und den nächsten Wert produzieren soll, mache ich I++ und nicht mehr. Das geht ja auch.
Und deswegen kannst du auch nicht dort Entries machen wahrscheinlich und äh, könntest du schon. Dann würdest du halt eben bei Entries wieder einen Iterator rausbekommen, der ja seinerseits wieder lazy ist. Das ist das Ding. Ah ja, okay. Wenn du hingehst und du machst auf einem Array oder auf einer Map oder was auch immer Entries, kriegst du ja nicht ein Array raus. Du kriegst ja immer so ein Iterable raus. Ne, einen Iterator kriegst du da raus. Iterable, Iterator? Hab's grad nicht im Kopf.
Das fällt halt meistens nicht auf, weil du willst ja dann damit meistens irgendwas anstellen. Du machst dann halt irgendwie sowas vor Value in myMap.keys zum Beispiel, weil du über die Keys überlupen willst. Und weil du es halt direkt in diese Konstruktion reinsteckst, fällt dir gar nicht auf, dass durch diesen Schritt deine Map nicht in ein Array degeneriert, sondern in ein noch basaleres Objekt gleichsam. Ja, okay. Was alles total gut ist, weil es in 90% der Fälle halt eben überhaupt nicht auffällt, was da vor sich geht.
Aber in dem Fall halt eben schon, und es wohnt halt eben auf dieser Iterator-Klasse aus einem Grund und ist halt keine Array-Methode und deswegen gibt es halt auch kein ForEach da drauf, weil ForEach müsste eben auch implementiert werden auf dem Prototyp jedes Typs, der da involviert ist. Kannst halt nicht davon ausgehen. Ja, okay. Ja, das ist doch super. Habe ich verstanden. Genau, das haben wir also neu in Firefox iterator.zip und iterator.zip keyed als Methoden.
Ja, was war denn nochmal iterator.zip keyed? Den habe ich gar nicht in meinem, Gewächnis drin. Aber halt eben da ist er. Scroll, das spuckt er aus. Iterator-Objekt, Keys. Ah ja, gut. Wenn du über so objektartige Strukturen sippen willst. Du hast halt eben Objekte, wo du halt eben angibst. Warte mal, warte mal. Äh, doch, genau. Für gekiete Elemente ist das, wenn ich es jetzt nicht sehe. Ich meine, das spielt jetzt eh keine so große Rolle, weil außer Firefox kann es im Moment keiner. Man kann es natürlich polyfüllen.
Aber vielleicht kann man die Analogie sagen, das eine ist halt wie Set und das andere wie Map? Vielleicht? Ich will jetzt nichts Verkehrtes sagen. Ja, okay. Na gut, wir können das ja offen lassen. Also, wer da irgendwie interessiert dran ist, wir verlinken das auf jeden Fall. Ja, wir verlinken das und, äh, ich meine, meistens weiß man ja auf welcher Datenstruktur man arbeitet. Man ist selten in der Situation drin, dass man wirklich jetzt unbedingt ein Komposit herstellen muss aus einem Array in der Notelist und einem String.
Wie oft kommt das schon vor? Es sind halt so diese ganzen Iterator-Helpers, das sollte man vielleicht noch erwähnen, das ist ein ganzes Proposal, wo lauter so Hilfsfunktionen wie halt CONCAT und tatsächlich auch Map und Filter und Konsorten, für Iterators bereitgestellt werden. Das heißt, du hast dann kein ForEach auf allen Iteratoren aber zumindest so Sachen wie Mapfilter Reduce. Das Ding bei all diesen Kisten ist halt eben, die müssten notwendigerweise lazy sein, weil sie davon ausgehen müssen, dass ihre Inputs auch lazy sind.
Und das ist halt immer so ein bisschen so der Hirnriss. A, degenerieren halt eben deine Typen und du machst Mapfilter. Aber wenn du halt eben Mapfilter auf einem Array machst, kriegst du wieder ein Array raus. Wenn du sagst Array.Entries, Mapfilter, kriegst du halt was komplett anderes raus, was auch noch lazy ist. Also nicht nur ein anderes Interface implementiert, sondern auch ein ganz anderes Falten in den Tag legt. Aber eigentlich ganz schön, wenn das alles geht. Asychrone Iteratoren gibt es natürlich auch.
Die geben dir halt nicht den nächsten Wert, sondern einen Promise auf den nächsten Wert raus. Und auch die kriegen ihre Helpers, aber das ist ein separates Proposal, das braucht ein bisschen länger. Also for a weight of. Ja, wobei nicht vergessen, die Vorschleife will ja Iterable Objekte haben mit dem Magic Key, wo man den Asynchron-Iterator draufkriegt. Das ist also nochmal was subtil anderes. Aber das hängt halt zusammen. Es gibt halt in JavaScript immer die grüne und die blaue Variante. Die grüne Variante ist synchron.
Iterables, die Iteratoren ausspucken. Und dann gibt es noch asynchrone Iterables, die asynchrone Iteratoren ausspucken, die das gleiche sind wie die Synchronen, aber halt eben mit promise of the weight. Okay. Und wo wir gerade bei denen sind? Hier, Safari meldet in den Technology Previews, A, Streams, also Readable Streams, werden jetzt auch asynchron iterierbar, das heißt, die implementieren auch dieses Interface. Hat bisher immer gefehlt, musste man manuell dran patchen, also so Prototyp hacken.
Bisschen blöd, aber nicht schlimm, ist halt so ein zwölfzeiliger Polyfill gewesen. Und Safari Technology Preview vermeldet auch, dass man mit Readable Stream From aus einem Iterable oder Asynchron-Iterable sich dann komfortabel einen Readable Stream bauen kann. Auch so ein Ding hat bisher in Safari gefehlt. Auch wieder 10 Zeilen Polyfill, den man da drauf patchen musste. Kann man sich dann auch sparen, wenn das alles raus ist. Und die Readable Streams werden transferable, was natürlich auch eine feine Sache ist.
Das heißt, man kann die an Worker übermitteln, zum Beispiel? Jo, Chef. Ärgert dich das nicht manchmal, also ich meine, gerade du, so als Low-Level Web-Tech-Hacker mit deinen Islands of Reactivity. Wünschst du dir auch manchmal, es wäre einfacher, Dinge in einem Web-Worker zu haben, die irgendwie mit Dingen interagieren, die fundamental nicht im Web-Worker existieren können? Mhm. Stell dir einen Notation-Observer im Web-Worker vor. Das ist quasi die Krücke dafür, auf dem du das machst. Genau, genau.
Das Ding ist ja, also generell ist das Problem mit Web-Workern ja immer, du musst dann immer so Nachrichten da reinpassen. Ja. Und du bist dann quasi immer dazu gezwungen, auf Basis von PostMessage dein eigenes Datenprotokoll zu erfinden. Genau, und da kannst du quasi diesen readable Stream noch reinstecken und der... Huisa, huisa. Das ist ja auch gar kein Problem, es sei denn, du willst in deinen Worker verschiedene Nachrichtentypen reinschieben.
Hier für Task A, da für Task B, da für Task C. Da kann ich ja Broadcast Channel auch empfehlen für. Um Nachrichten in einen Worker reinzuschieben, Naja, du kannst ja einen Broadcast-Channel für jeden Typ Daten oder sowas aufmachen. Ja. Und die Worker können dann ja sich subscriben an die entsprechenden Broadcast-Channels, die sie interessieren. Das wird natürlich funktionieren. Dachte, dass du hättest jetzt irgendwie für drei verschiedene Typen, drei verschiedene Worker am Start.
Das wäre natürlich ein bisschen overkill. Manchmal auch. Manchmal auch. Na, pass auf. Es ist ja eigentlich so, ich meine, JavaScript ist ja am Ende des Tages, das will wieder die React-Fraktion nicht hören, aber es ist ja im Herzen objektorientiert, oder? Die Daten wohnen in Objekten, die haben Methoden und so weiter und so weiter. Das heißt, der klassische Abstraktionsmechanismus wäre ja der, du hast irgendwie eine Quelle von Daten, zum Beispiel Mutation Observer, und willst irgendwie das irgendwie sinnvoll kapseln.
Die Konstruktion von Mutation Observer an sich ist ja schon ein bisschen oll, so mit einer Callback-Funktion. Das wäre schon praktischer, wenn das irgendwie ein Event-Target wäre, was es nicht ist, oder irgendwie ein Readable-Stream wäre. Und was du halt eben jetzt machen kannst, was ich halt super finde, ist halt, du nimmst ein Konstrukt, das halt irgendwie so Callback-mäßig unterwegs ist und das du normalerweise wirklich naiv einfach in einen Worker reinpipen würdest.
Also, wenn Mutation of Server Callback feiert, machst du Post Message, aber dann wird es halt immer sehr kleinteilig, sehr Spaghetti-ig. Stattdessen nimmst du den Mutation of Server, packst du einen Stream drumherum und filterst die Daten raus, die dich interessieren und beamst dann den Stream als Transferable in den Worker. Das heißt, wenn dann eine Mutation im Main Thread passiert, kriegst du im Worker, nicht das Mutation Event, weil du natürlich so Sachen wie DOM-Referenzen vorher rausfiltern musst, die gehen da halt nicht rein.
Aber so Informationen wie das Ding mit der ID hast du sich nicht gesehen, hat jetzt drei Children statt vier, ist vielleicht genau die Information, die du brauchst, um irgendwelche Operationen zu triggern. Wobei ich gerade überlege, ob das für Mutation Observer gehen würde, weil du ja dann immer quasi, du hast ja immer dann Entry.Target, glaube ich. Und das ist ja ein Verweis auf das DOM-Element. Ja. Ob dafür ist ja noch das drin funktionieren? I don't know. Nee, das müsstest du halt rausfiltern.
Ja, okay. Diese Information kannst du halt nicht übertragen. Du kannst halt nicht dem Worker eine Referenz auf DOM-Objekte geben. Aber halt alles andere. Ja. Und wenn du halt irgendwie so Operationen hast, wie Träger-Rechnungsschritt, sobald das passiert ist, oder mach Request, wenn das Ding sichtbar geworden ist, so Späßchen, das geht halt eben ganz wunderbar. Und es ist halt so ein schöner No-Brainer, weil es halt ein Transfer ist, im Sinne von, du baust diesen Stream auf, nur um ihn in den Worker zu stecken, dann ist er auch tatsächlich transferred, im Sinne von, der existiert dann bei dir nicht mehr.
Das heißt, es ist sozusagen ein einmaliges Worker-Setup. Du machst den Worker auf, schiebst den Stream da rein mit dem Web-Server oder was auch immer da dran, attach das und dann ist halt eben fertig. Null manuelles Management mehr. Ja, sehr cool. Also wirklich so, der Worker operiert dann quasi autark und du musst nicht mehr Post-Message-Krempel dahin machen. Mhm. Sehr nice. Ja, ist super. Habe ich noch nie irgendwas benutzen sehen, aber es ist halt immer so ein Gehirnexplosionsding, wenn ich das zeige.
Ja, wahrscheinlich, wenn das einer benutzt, dann wahrscheinlich irgendwie hier Surma, wobei ich nicht weiß, ob der noch viel mit Web macht gerade oder ob der noch in Rust abgetaucht ist. Also der ist ja nicht mehr so richtig, taucht, ich sehe den nicht mehr, seit der bei hier Shopify arbeitet. Mhm. Ja, der ist ein bisschen untergegangen, das stimmt. Genau, wir haben noch zwei Sachen in der Liste. Machen wir eben schnell, komm. Genau, also Firefox hat jetzt, oder sagen wir mal, Firefox 149 Beta hat Popover-Hints, unterstützt die jetzt.
Das sind ja die Popovers, die nicht durch User-Interaktionen getriggert werden. Sondern wo man, also du machst halt Popover und dann gleich Hint. Und dann gibt es auf verschiedenen Devices unterschiedliche Heuristiken, zum Beispiel auf Desktop-Devices gucken die sich an, wo du mit deinem Pointer gerade rum, fuchtelst und dann geht ein Popover auf, je nachdem, wenn dein Pointer über einem, gepopoverten Element ist und auf Mobile funktioniert das so ein bisschen wie bei den Speculation Rules, dass die halt Heuristiken haben, wo die sagen, wenn du irgendwo hingeschreut bist und eine gewisse Zeit auf den Ausschnitt des Bildschirms guckst und da ist ein Popover des Typs Hint, drin verbaut, dann würde das dann irgendwann sagen, ah, ich glaube, die Userin, der User interessiert sich für mich, ich ploppe jetzt auf.
Das ist das eine. Kann der Safari noch nicht. Genau, ich weiß auch nicht, ob das Interop ist oder nicht. Ich glaube ja. Genau, und das andere ist, dass der Firefox das Close-Watcher-Interface implementiert. Das hat der Chrome schon bestimmt seit zwei Jahren oder so und dieses Interface hat den Zweck, also, es gibt ja bestimmte Interaktionspatterns auf Geräten, jetzt nicht unbedingt auf Desktop-Devices, aber auf Mobile-Devices, mit denen du Fenster schließt.
Also auf Desktop kennt man das natürlich, also da erwarten wir eigentlich immer, wenn wir Escape drücken, dass ihr ein Fenster schließt, das Gefühl ist. Das wäre vielleicht auf Desktop das Pattern. Auf Mobile ist es eine Swipe-Geste, die in nativen Apps auf einer gewissen Plattform dann Dinge, Fenster schließen. Das können die Browser nicht. Da ist ja so ein Swipe-Geste bislang eigentlich immer so ein History-Back oder irgendwie sowas. Und du kannst eben mit diesem Close-Watcher sagen, ich will jetzt solche Gesten, ich möchte darüber Bescheid bekommen und dann kann ich damit auch zum Beispiel Dialoge schließen.
Ja, also im Prinzip die device-spezifische und mir nicht notwendigerweise bekannte Nutzerinteraktion für mach das weg, wird ausgelöst, da kann ich einen Callback draufsetzen und dann darauf reagieren, damit dann mein Dialog, meine Sidebar, was auch immer, verschwindet. Genau. Alternative wäre halt eben zu recherchieren, was gibt es an Browsern und Devices und was haben die da so an Mechanismen, um das zu auszudrücken. Genau, aber das skaliert natürlich auch nicht. Also dann hast du vielleicht irgendwie Samsung Internet, der macht irgendwie was anderes als Chrome und das, also. Ja, der PlayStation-Browser ist irgendwie ganz seltsam. Oder so, genau.
Und dann verändern sich die Browser auch. Also deswegen ist natürlich so ein generisches, so mir egal, wie die Geste ist, aber sag einfach Bescheid, wenn die kommt. Wenn dieses Intent des Users kommt, dann ist das natürlich cool. Und ergänzend dazu vielleicht die Tatsache, dass du in den Dialog-Elementen mittlerweile ein Close-By-Attribut verbauen kannst. Und wenn du das auf All setzt, dann hast du dann Light Dismiss. Den gibt es schon bei Popover.
Und der Light Dismiss, der integriert all diese Dinge schon. Also du im Grunde, wenn du System in Browsers, der Close-By auf Dialog unterstützt, dann brauchst du es dafür schon mal nicht. Dann machst du einfach Close-By gleich All und dann schließt sich das bei Drücken von Escape. Dann schließt sich das bei Klick außerhalb des Dialogs und dann schließt sich es auf mobilen Geräten, wenn man die entsprechende Swipe-Geste macht. Und wenn du das richtige mobile Gerät hast.
Ja, dann? Dann funktioniert das. Wenn du das falsche hast, das mit dem Absell drauf. Ach so, der unterstützt das noch nicht. Dieses Close-By-Attribut meinst du? Natürlich nicht. Gehen wir denn da sonst hin? Ja, gut. Okay, aber warte mal, hier Interop, da ist das auch drin. Also Ende des Jahres ist das dann auch in Safarien. Okay, also müssen wir weiterhin alles tun, um nicht von einem Zug überfahren zu werden, auf das wir in den Genuss dieses Features auch auf dem EIOS.
Genau, sobald wir das haben, können wir uns vom Zug überfahren lassen. Dann ist es ja alles egal. Genau. Hey, wir müssen einfach gucken, ob wir Ende des Jahres noch Züge fahren, so mit Energie und Gedöns ist ja nun alles nicht sicher. Elektrozüge? Genau. Ja, aber dann wird ja, wenn wir nicht mal Auto fahren können, der ganze Strom für die Flugtaxis gebraucht. Dann kannst du dir ja den ICE auch in den Hut stecken. Okay, ja, das hatte ich natürlich jetzt übersehen. Tja.
Vielleicht noch sieben letzte Stichworte. Firefox kann, unterstützt jetzt auch die Length-Units CH, EX, IC und CAP in der Route-Variante, also Route-Schriftgröße, so wie wir das von REM kennen oder REM, gibt es eben RCAP, RCH, REX und RIC. RCAP, ja. Da müsste man nur einen Buchstaben austauschen, damit das kontrovers wird. RCAP, RCAP. Okay, man müsste zwei Buchstaben rausnehmen. Ich weiß jetzt wieder, ja. Es endet auf einem P. Und du sprichst in Initialien unserer ehemaligen Außenministerin.
Werft den Purchen zu Boden, weißt du doch, man kann das so oder so aussprechen. Außerdem finde ich es gut, wenn ich meine Schriftgröße jetzt als Rex angeben kann. Das entspricht zu meinem Selbstbild. Das ist top. Genau. Oder Rick and Rex. Das klingt wie ein Snack. Genau, dann hat Firefox 148 so einen Quirk behoben, den die halt hatten, weil Browser sich da früher irgendwie, weil es da keine Standards für gab, nämlich, wenn du einen iframe hattest und oder ein frame, also iframe und du setzt das, die Source auf about blank, dann hast du zwei Load-Events im Firefox gehabt, nämlich einmal.
Bei dem leeren Screen vor about blank und dann nachdem about blank geladen war, in Anführungszeichen, was im Grunde ja auch quasi nichts ist, aber Firefox hat dann quasi doppelt gefeuert, das ist jetzt weg. Das hatten die auch gebissen, gerade erst vor vielleicht so drei Wochen, vier Wochen. Ich wollte es gerade sagen, das ist ja nicht einfach nur so die Updaten about Blank, sondern das ist ja tatsächlich ein Problem gewesen. Genau, weil ich da was reingeladen habe und eigentlich davon ausgegangen bin, dass wenn ich das Load-Event bekomme, dass das dann geladen ist, dass das dann passiert ist und das war eben nicht der Fall und das lag daran.
Genau, dann ist die Sanitizer-API natürlich jetzt auch in Firefox, da verweisen wir auf die Folge mit dem Frederic Braun, die wir nicht allzu lange Zeit aufgenommen haben, wo wir da sehr ausschweifend drüber gesprochen haben. Sehr coole API. Genau, dann hat Safari begonnen den Doppelpunkt-Heading, die Pseudoklasse Doppelpunkt-Heading zu supporten, nicht hinter einem Fleck, in Firefox gibt es das auch hinter einem Fleck und damit kann man alle. Headings, Heading-Tags gleichzeitig ansprechen. Ja, und auch nur die, also deine Web-Component, die auch eine Heading sein möchte, ist außen vor.
Könnte man mal eine Ergänzung anfordern in Element & Tunnels. Genau, das haben wir uns in der Vorgeschreibung gefragt, ob wenn man Roll-Heading da drauf legt, ob das dann irgendwie da auch reinfällt. Nee, pass auf, das ist ja nochmal was anderes. Also die Dinger, die jetzt angesprochen werden, sind ja intrinsische Headings. Ich will Web-Components haben, die sagen können, ich bin auch eine Heading. Und du willst das über ein ARIA-Attribut regeln, was ja dann jedes dahergelaufen ist.
Also deine Web-Component extents dann dieses Heading-Element sozusagen. Nee, nee, es gibt ja Element-Internals, womit du quasi Features aus internen Algorithmen, aus den Standards auf deine Elemente anwenden kannst. Damit kannst du ja zum Beispiel deiner Web-Component eine Default-Role geben für ARIA zum Beispiel. Und das geht zum Beispiel, wobei ich letztens gelernt habe, eine Frage, die mich auf Mastodon erreicht hat, von, heißt er nicht auch Peter?
Ein Peter auf Masse, dann fragt er mich jedenfalls danach. Gibt es eigentlich eine Möglichkeit, dieses interne gesetzte ARIA-Value zu exposen nach außen? Weil, stellt sich raus, dass Accessibility-Test-Tools das nicht können. Die wissen halt, ein Main-Element hat eine Role-Main und die wissen halt eben, sie müssen sich HTML-Attribute namens Role angucken, um anzuschauen, ob dann irgendwie das Diff eine spezielle Role hat. Aber wenn ich einfach so, keine Ahnung, My Heading gebaut habe, haben die keine Möglichkeit. Weder das eine noch das andere zu. Richtig, genau.
Das hat nichts Intrinsisches an sich, sondern ist halt dieser dritte Weg da. Und das können die halt nicht feststellen. Ich weiß nicht, warum ich das jetzt erzähle. Was ist dann, wenn man irgendwie dort, also wenn man das quasi programmatisch abfragen würde, würde das gehen? Was programmatisch abfragen würde? Also wenn ich jetzt zum Beispiel Custom Element selektieren würde und dann .roll mir ausgeben lassen würde? Nee, das ist ja der zweite Fall.
Der zweite Fall ist ja, wenn das Roll-Attribut gesetzt ist. Aber das ist ja der Fall, du hast einfach nur den HTML-Tag. Du hast nur das Main. Dann hat das ja was Intrinsisches. Und wenn du dann Roll abfragst, steht da ja auch nichts drin. Genau, wenn ich das auf dem H1 mache, würde ich da auch nichts bekommen wahrscheinlich. So sieht's aus. Ja, ja, ja. So, jedenfalls, dieser Heading Pseudoselektor selektiert nur H1, 2, 3, 4, 5, 6. Dinge mit einem Rollheading oder Dinge, die qua Web Component ein Heading sein wollen, sind damit nicht miterfasst.
Ja, genau. Für die einen kann das ja richtig so sein, für die anderen ist es vielleicht so, dass man denkt so, ja, weiß nicht. Wir brauchen einfach nur nutzerdefinierte Pseudoklassen. Dass ich mir einfach selber in CSS sagen kann, ich meine, ich kann if machen, ich kann Funktionen machen, ich kann allen möglichen Blödsinn machen, warum kann ich mir nicht auch meine eigenen Pseudoklassen machen, mit Koks und sonstigen Ergänzungen? Keine Ahnung, weil Houdini das dafür gedacht war, irgendwie im Sandeverlauf ist. Wir müssen echt nochmal da wegholen und wieder zu Google schicken. Ja, genau.
Wir haben aber noch eine Pseudoklasse, die wir benutzen können in allen Browsern außer dem Safari, glaube ich. Das ist die Open-Pseudo-Klasse. Also alles, was irgendwie openbar ist, sei es ein Dialog, vielleicht ein Popover, aber auch Inputs, die irgendwelche Picker haben, die geöffnet werden können. All das würde dann erfasst werden von dieser Open-Pseudo-Klasse. Ja, hoffentlich auch die Custom-Selects, sonst wird es interessant. Ja, gute Frage. Ich gehe mal davon aus, die Welt ist kompliziert. Nicht wahr?
Das finale Ding, wo ich, irgendwie war das so, ich hatte Release Notes gesehen oder einen Post von der Jen Simmons zu einer Safari-Version und da waren viele Sachen drin und das war das, was mich am meisten gefreut hat, nämlich das Safari, Score Anchoring jetzt unterstützt, was die anderen Browser seit Trilliarden Jahren schon können. Und das ist halt quasi, dass dein Viewport an der Stelle stehen bleibt, wo er quasi runtergescrollt gerade ist, auch wenn vielleicht oben drüber größere oder kleinere Elemente eingefügt werden und sich sozusagen das Dokument verkürzt oder verlängert.
Um Gottes Willen, das können die anderen Browser ja wirklich seit der Kreidezeit. Ja, eben. Genau, und Safari war halt der einzige Firefox 66, Chrome 56. Genau. Und man konnte das im Safari eben nur fixen, also zumindest wenn man jetzt selber, wenn man Einfluss drauf hatte, konntest du dann eben einfach die Scrollpositionen weg sichern, das dann quasi einbauen und die dann quasi adjustiert wieder anwenden. Das war ein bisschen doof. Und das kann Safari jetzt oder kann das jetzt irgendeine Technology Preview?
Ich glaube, ja, das ist jetzt hier in meinen Notizen verloren gegangen, aber egal. Also bald kann der Safari das. Ich sag mal, der kann das. Ich glaube, er kann das. Genau. Und ansonsten haben wir ja auch in der V-Sprechung darüber gesprochen. Safari ist ja mittlerweile mit den Death Rail Leuten relativ gut dabei. Das heißt, da gibt es dann ja Menschen, denen man sagen kann, falls da nur eine Technology Preview drin ist, dass sie vielleicht mal im Rahmen ihrer Möglichkeiten einen saftigen Tritt in den Hintern vom Dev-Team vielleicht gezielt platzieren können in Richtung von Scroll-Anchoring. Weil das ist wirklich ein bisschen...
Schwach, dass das nicht geht. Na, ich weiß nicht, das ist irgendwie einfach unter den Tisch gefallen. Aber tatsächlich, also die Fragen auch aktiv nach Wünschen. Das ist halt meistens so, wie wenn man selber gefragt wird, was willst du zum Geburtstag, dann weiß man irgendwie gar nichts. Das heißt also, wenn euch solche Dinge auffallen, der Jack Archibald von Firefox oder das Firefox Dev, der Dev-Account, was aber er ist aktuell, fragt das auch ab und zu.
Also wenn ihr irgendwelche solche Sachen habt, dann schreibt die am besten irgendwann irgendwo auf, damit wenn dann diese Frage kommt, ihr auch sozusagen direkt was dazu schreiben könnt. Ja, oder ich würde die auch einfach anschreiben. Die haben doch bestimmt die Technologie der Notiz schon für sich erfunden und können das dann in den großen Eimer mit Wünschen reinfüllen. Ja, genau. Ja, und dann wären wir jetzt durch mit den Spannungsneuerungen der letzten 20 Wochen.
Ein paar mehr gab es, viele Bugfixes und so, aber so die anderen Sachen, die waren so ein bisschen so, also WebGPU wird jetzt auch unterstützt auf Safari, auch cool, aber sehr special interest. Ja. Ich meine, das sind die Dinge, zu denen wir was sagen konnten und Perspektiven beitragen konnten. Richtig, genau. Also WebGPU könnte ich auch noch was zu sagen, aber benutze ich einfach nicht. Also liegt davon daran, dass ich ja aus dem 3D-Bereich komme und da immer so mein Herz da immer noch so ein bisschen dranhängt und ich das dann immer spannend finde.
Aber brauchen tue ich es halt einfach genau gar nicht. Also okay, was macht es denn? Also mache ich damit wirklich GPU-Sachen oder mache ich damit irgendwie generelle Berechnungen, KI-Blödsinn? Was kann ich damit machen? Also du kannst damit generelle KI-Brechnungen machen auf der GPU. Der Vorgänger von WebGPU ist ja WebGL, das war ja QL-Standard. Es gab auch mal so WebCL, das war ja mal, aber ich glaube, das hat es irgendwie nie dann über die Zählinie geschafft. Das war ja Web Compute Language oder Compute Library, während WebGL Web Graphics Library ist.
Und das ist wiederum basiert auf OpenGL ES 2.0, das ein Subset von OpenGL ist. Und OpenGL ist halt von Silicon Graphics erfunden worden und 30 Jahre alt. Genau, das ist ja so der kleinste gemeinsame Nenner gewesen. Genau, und wie es halt so bei kleinsten gemeinsamen Nennern ist, also alle Devices können das, es läuft, aber es ist einfach ultraantik. Und bestimmte Dinge kannst du halt nicht machen. Also es hat Nachteile. Es ist Single-Threaded. Du kannst also, und das haben wir, das ist auch bei so grafischen Stellen wie DirectX und Metal und Vulkan.
Vulkan ist ja der Nachfolger von OpenGL. die sind entwickelt worden unter anderem weil OpenGL nur Single-Threaded arbeitet, wir Multicore-CPUs haben und die GPUs einfach nicht schnell genug von diesem einen CPU-Kern, den OpenGL ja nur unterstützt und WebGL auch gefüttert wurde und genau das geht jetzt halt Multithreaded, das heißt also unsere ganzen 8 bis 16 Cores können die GPU zuwerfen mit Kram und die eidelt halt nicht rum. Das andere ist, dass du, also so Sachen wie Partikelsimulationen oder irgendwelche solche Berechnungen, Physikberechnungen oder so, die konntest du auch mit OpenGL und WebGL nicht in der GPU fahren, sondern musstest die auf der CPU machen, auf dem Mainstrad, der eh schon beschäftigt war, die GPU zu jonglieren.
Und ich sehe gerade jetzt, das hat ja hier ganz einfach in der API so ein Compute-Pipeline-Konzept, dass man dann sagen kann, explizit eine Schnittstelle für nicht Grafikkram. Genau, und jetzt kannst du das alles quasi auf die Grafikkarte schieben. Die Grafikkarte berichtet dann die Grafik oder die Triangles und das Shading und so weiter. Und eben Physik und vielleicht Partikel. Und die CPU muss halt den Kram gar nicht mehr machen. Und kann eben multithreaded die Grafikkarte unter Dampf setzen.
Ey, und die Shader-Language sieht ja auch nicht aus, als wäre sie aus den 80ern. Ah ja, genau. Und die Shader-Language ist eben auch eine neue und die ist jetzt auch eben debuggable. Ich wollte es gerade, das sieht halt wirklich aus wie irgendwas, wo ja, okay, das ist zuwutbar und das ist nicht irgendwie so, okay, ich muss jetzt irgendwie mir den Bärenpelz anziehen, um da ins richtige Mindset zu kommen. Sehr schön. Ja, und ich glaube, dass das halt, ich sag mal, unsere Bewegungspunkte ist wahrscheinlich als Nutzer, also ich weiß nicht, wie oft du irgendwelche, AAA-Title im Browser spielst oder irgendwie tolle 3D-Spiele, wahrscheinlich eher selten, aber wir würden wahrscheinlich Nutznießer werden der Tatsache, dass du eben natürlich auch KI-Berechnungen über Web-GPU auf der GPU laufen lassen kannst.
So, wenn du irgendwelche KI-Frameworks benutzt oder auch, ja, gab's ja auch schon so Frameworks für irgendwie so Gesichtserkennung und solche Dinge, das kannst du dann auch. Vor allen Dingen gibt's dafür ja in den Browsern ja auch tatsächlich extra APIs, aber wenn du wirklich dein unabhängiges, eigenes Ding bauen willst, ist das sicherlich eine Idee zu. Naja, und ich meine, wie gesagt, der ganze Unterbau ist auf jedem Device vorhanden. Und wenn das Web da jetzt keine Schnittstelle für hätte, wäre halt einfach schwach. Ja, genau.
Und der finale Vorteil von WebGPU gegenüber WebGL ist eben, dass es für Erweiterbarkeit entwickelt wurde. Das heißt, du kannst, also Grafikkarten können ja neue Sachen, die können dann irgendwie, keine Ahnung, auf einmal können die Raytracen oder die haben bestimmte Texturarten, die die dann auf einmal verstehen und das kannst du dann, also WebGPU ist so gestaltet, dass das Feature-Set eben nicht das ist, was jetzt bekannt ist, sondern du kannst es quasi nach und nach, kannst du zulernen sozusagen.
Ja, ich meine, der wird sicherlich auch da irgendwann mal eine Version 3.0 geben müssen. Aber weißt du, was wir in dieser Sendung gesehen haben, sind so dann jetzt mit WebGPU auch zwei Instanzen von etwas, was ja heutzutage eher selten ist. Nämlich, da kommt eine Version 2.0 von was raus und man stellt fest, ah, okay, das ist tatsächlich besser. Ja. Also hier die Navigation API, nie wieder History API anfassen, super. So, und selbst beim Durchscrollen durch die WebGPU API und meinem sehr, sehr marginalen Verständnis von WebGL vorher, erkenne ich halt sofort, dass das einfach einen ganz anderen Geist atmet. Ja.
Genau. Einfach auch so absolut. Ich meine, ich mache damit nichts, aber wenn ich es jetzt wollte, würde ich wahrscheinlich hier viel schneller einen Einstieg reinfinden, als in dieses, wirklich, wie du ja schon so sagtest, antike Zeug von damals. Ja, genau. Und du hast ja auch teilweise, musst du ja bei WebGL Fremdkörper mit Fremdkörpern hantieren, die eigentlich überhaupt gar nicht zu Hause sind im Web. Also die ganz merkwürdig sind. Ja, okay. So native Syntax für jetzt die Shader-Language sehe ich jetzt hier drin auch nicht so richtig.
Das ist immer noch ein String, den ich da irgendwie reinstecken muss, aber auch das ist... Besser. Kann ich auch als Text importieren mit einem Modulescript. Import Type Text. Kein Problem. Ja. Ist so. Vielleicht auch bald als Shader Language. Ja, warum nicht? Warum soll das nicht direkt verarbeitet werden können? Auf geht's. Okay, so. Nachdem wir es jetzt geschafft haben, noch ein bisschen länger zu quatschen, weil ich doch gesagt habe, komm, Shep, erzähl mir was über Grafikkarten. Ja.
Genau, also wenn ihr uns genau, ihr könnt uns supporten bei Patreon, aber ihr könnt uns auch GeForce RTX 5090 schicken, das ist auch okay? Oder das Geld da reinstecken und uns schicken? Gib mir SSDs. Oder SSDs oder RAM-Riegel. RAM-Riegel habe ich genug. Das Wir brauchen das Working Draft Rechenzentrum. Wir müssen auch eins bauen jetzt. Einfach so. Ich würde es nicht Rechenzentrum sagen, sonst sind wir wenn es losgeht, auch bei denen, die angezündet werden. Wir haben kein Rechenzentrum. Okay.
Wir sind immer noch hier individuelle Untergrund-Podcaster. Wir haben von Anfang an die Wahrheit berichtet. So. Und wir sind definitiv kein Rechenzentrum. Bitte zündet die anderen an, nicht uns. Ja, okay. Dann machen wir das so. Aber schickt mir gerne SSD, wenn ihr eine übrig habt. Genau, schickt den Peter SSDs und schickt uns auf einem unserer Kanäle, die ihr alle auf der Webseite findet, gerne Feedback, wenn ihr Feedback habt, wenn ihr Fragen habt, und schickt auch gerne generell Fragen.
Das haben wir jetzt mal gemacht, also vor dem ein, zwei, drei Folgen. Genau. Das könnten wir auch mal wieder machen. Genau. Schreibt sie uns irgendwo hin. Kommt in den Community-Slack. Schaut uns auf Social Media an. Genau. Und geht zu Bion Tellerrand. Ich habe immer noch keine Anfrage für jemanden, der zu Bion Tellerrand kommt, den ich durch Düsseldorf führen kann. Das heißt, ich sitze einfach nur auf meinem Hintern oder was. Ja, und das ist ja nicht gut. Shad macht gute Führungen durch Düsseldorf.
Genau. Kann ich aus Erfahrung bestätigen. Alles klar. Dann danke fürs Zuhören. Danke, Peter. Hat Spaß gemacht. Ich habe neun Millionen Sachen gelernt. Ich wollte es gerade sagen. Ja, sehr gut. Gut, dass wir das hier machen. Und dann geht es nächste Woche weiter und da wird es gehen um VZERO von Vercel, mit einem der Menschen dahinter. Also man kann viel über diesen Podcast sagen, aber nicht, dass wir eintönig werden, dass die Themen ausverlangen geht. Ja, das stimmt.
Also, Dann bis nächste Woche. Bis dahin. Tschüssi. Tschüss.
Transcript supplied by the publisher with the episode.
Podcast
Working Draft
Vanessa Otto, Peter Kröner et al. · Tech & Science · German
Deutschsprachiger Podcast über Webentwicklung — HTML, CSS, JavaScript, Browser-APIs und alles rund ums moderne Web.
More from Working Draft All episodes →
-
E710 · 28 Apr 2026 · 1 hr 21 min
Revision 710: React- & TypeScript-Glücksrad, mit Hans-Christian Otto
Wir spielen wieder Glücksrad und lassen uns durch eine bunte Mischung aus React- und TypeScript-Themen treiben. Mit dabei sind diesmal Stefan, Peter und Hans-Christian Otto und wie schon beim letzten Mal zeigt sich schnell: Ein einzelnes Thema reicht locker für eine halbe Stunde Diskussion. Wir hangeln uns vom React-Compiler über TypeScript Assertion Signatures bis hin zu useState und verlieren uns dabei genüsslich in Details, Meinungen und Abschweifungen zu Compilern, CDNs und Programmierparadigmen. SHOWNOTES [00:02:13] REACT COMPILER Der React Compiler wird als neue Möglichkeit diskutiert,…
-
E709 · 21 Apr 2026 · 1 hr 40 min
Revision 709: HTTP/3 und WebTransport, mit Max Inden
Diese Woche ist Max Inden (Mastodon) von Mozilla zu Gast. Mit ihm sprechen wir über den Networking-Stack von Firefox und arbeiten uns dabei von HTTP/1 über HTTP/2 bis zu HTTP/3 und QUIC vor. Ausgangspunkt ist die Frage, warum es nach den Versprechen von HTTP/2 überhaupt noch eine weitere HTTP-Version brauchte und welche praktischen Probleme im echten Netz dabei eine Rolle spielen. UNSER SPONSOR Im Webcafé, dem Podcast zu Webentwicklung, Webdesign und Unternehmenskultur, nehmen euch Felix und Kay mit auf eine spannende Reise durch die Welt moderner Softwareentwicklung. Gerade ihre…
-
E708 · 14 Apr 2026 · 56 min
Revision 708: Temporal, mit Philipp Dunkel
Diese Woche haben wir Philipp Dunkel (Bluesky) zu Gast und sprechen mit ihm über Temporal, also die neue JavaScript-API für Datum, Uhrzeit, Zeitspannen und Zeitzonen. Aufhänger ist ein Vortrag von Jason Williams auf der State of the Browser, von dem aus wir in die Geschichte, die Designprinzipien und die praktische Modellierung von Zeit in JavaScript einsteigen. UNSER SPONSOR Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige…
-
E707 · 7 Apr 2026 · 1 hr 39 min
Revision 707: ARIA-Glücksrad, die Dritte
Wir spielen mal wieder ARIA-Glücksrad und haben uns dafür mit Paweł Masarczyk (Mastodon), Peter Krautzberger (LinkedIn / Mastodon) und Marco Bretschneider (Mastodon) in bekannter Runde zusammengefunden. Daniela Kubesch musste diesmal krankheitsbedingt leider aussetzen 😥. Wir bedienen erneut unseren Zufallsgenerator, das „Glücksrad“, welches uns verschiedene ARIA-Properties ausspuckt, über die wir aus Sicht von Spezifikation, Implementierung und praktischer Nutzung mit assistiven Technologien sprechen. EVENT-TIPP Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei…
-
E706 · 31 Mar 2026 · 1 hr 4 min
Revision 706: v0 und Vercel, mit Leo Reuter
In dieser Revision sprechen wir mit Leo Reuter von Vercel (LinkedIn / E-Mail) über den Wandel von Deployment- und Hosting-Plattformen hin zu AI-gestützten Entwicklungswerkzeugen. UNSER SPONSOR Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints. Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉…
-
E704 · 17 Mar 2026 · 57 min
Revision 704: Der Tech-Stack des NABU, mit Eleonora Heiden und Christoph Wolff
Wir sprechen in dieser Folge mit Eleonora und Christoph (Mastodon) vom NABU darüber, wie digitale Infrastruktur in einer großen, föderal organisierten NGO funktioniert. Ausgangspunkt ist das NABU-Netz: ein Intranet mit zentralem Login, das Mitglieder und vor allem Ehrenamtliche mit Werkzeugen für Kommunikation, Weiterbildung, Zusammenarbeit und Webarbeit versorgt. EVENT-TIPP Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com…
-
E703 · 11 Mar 2026 · 1 hr 32 min
Revision 703: Hörenden-Fragen – Progressive Enhancement, Bildformate und JavaScript Disposables
In dieser Revision beantworten wir Fragen aus der Hörerschaft. Wir, Peter und Schepp, haben uns einige Themen aus einer längeren Liste herausgepickt und diskutieren darüber, warum bestimmte Web-Techniken sich in der Praxis manchmal schwerer durchsetzen als man erwarten würde. EVENT-TIPP Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue…
-
E702 · 3 Mar 2026 · 1 hr 24 min
Revision 702: Das <geolocation>-Element, mit Thomas Steiner
In dieser Revision sprechen wir mit Thomas Steiner von Google über einen lange offenen Schmerzpunkt im Web: Permission-Dialoge. Ausgangspunkt ist das neue -Element, das Chrome eingeführt hat und das Permissions kontextueller, deklarativer und weniger fehleranfällig machen soll. EVENT-TIPP Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue…
-
E701 · 24 Feb 2026 · 50 min
Revision 701: Der Government Site Builder (GSB) – mit Daniel Fau
In dieser Folge sprechen wir mit Daniel Fau (CEO der TYPO3 GmbH) über den aktuellen Stand des Government Site Builder (GSB). EVENT-TIPP Noch nichts vor am 28. Februar? 👀 Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨ 👉 https://2026.stateofthebrowser.com Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers Nachdem wir zuletzt vor allem über…
-
E700 · 17 Feb 2026 · 1 hr 41 min
Revision 700: 2016 vs. 2026 – Was ist aus unseren Prognosen geworden?
Zum Jubiläum werfen wir einen Blick zurück – ziemlich genau zehn Jahre. Inspiriert von einem Vorschlag aus unserem Community-Slack hören wir noch einmal in unsere Prognosen-Folge von Ende 2015 hinein und prüfen: Was ist aus unseren damaligen Thesen zu HTTP/2, Flexbox, Angular 2, React, Web Components und WebAssembly geworden? EVENT-TIPP Noch nichts vor am 28. Februar? 👀 Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem…
