Transcript
[0:00] Bei Dialog war ja noch kritisch anzumerken, dass der Modalmodus, ja deklarativ, gar nicht aktiviert werden kann.
Es gibt ja diese Popover-API, jetzt auch relativ frisch.
Da kannst du quasi sagen, eben wenn ich hier klicke, dann bitte mach dieses Popover auf.
Und das kannst du nur mit HTML und Beziehungen zueinander ausdrücken.
Je mehr ich drüber nachdenke, umso weniger gefällt mir das. Und deswegen denke ich, Leute, nehmt's JavaScript, nehmt's HTML, nehmt's CSS, dafür ist es da.
Wenn ihr was Spezielles haben wollt, dann macht das.
Wenn ihr was weniger Spezielles haben wollt, nehmt dann eine Library.
Und ansonsten braucht ihr vielleicht auch einfach gar keine Tabs, sondern einfach nur eine Liste von Zeug.
[0:44] Diese Revision von Working Draft wird euch präsentiert von Midwild.
Next-Level-Hosting für deine Projekte.
Ihr fragt euch jetzt bestimmt, wie kann sowas Langweiliges wie Hosting Next-Level sein?
Ganz einfach. Midwalds hochperformantes Cloud-Hosting ist perfekt abgestimmt auf die Anforderungen von Freelancern und Agenturen.
Es gibt z.B. ein smartes Rollensystem für die Zusammenarbeit mit euren Projektpartnern.
Und Midwald hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal unter uns Nerds. Sachen anklicken in einem User-Interface? Muss das sein?
Nein, muss es nicht. Denn bei Midwald gibt's die M-Studio CLI.
Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch Automatisieren.
Von Nerds für Nerds bringt euch Midwald die optimale Developer Experience, wenn's ums Hosting geht.
Und deshalb jetzt auf zu midwald.de slash workingdraft. Egal, ob mit Curl oder mit so nem grafischen Browser, es schreibt sich auf jeden Fall mittwald.de slash workingdraft.
Und alle Infos zu Midwald findet ihr natürlich auch noch mal in den Shownotes zu dieser Revision.
Wir danken Midwald für die Unterstützung von dieser Revision von Working Draft. Revision 585.
[1:58] Music.
Revision 585: Neues in HTML und Co, Teil 1 von 3
[2:23] Heute sind wir nur zu zweit. Der hat mir zum einen den Peter.
Moin, moin. Und ich bin der Shep.
Und ja, es ergibt sich, dass es dieses Jahr nicht nur ein State-of-JS und State-of-CSS Survey geben wird, sondern auch ein ganz neu, ein State-of-HTML Survey, mit dessen Erstellung die Lea Verou beauftragt wurde.
Und das finden wir zum einen ziemlich cool, also ich zumindest, dass HTML auch eine entsprechende Survey mal bekommt, denn die dient ja nicht nur unserem Entertainment und einer, weiß ich nicht, nicht weiter genutzten Datenerhebung, sondern die Browserhersteller benutzen diese State-of-Surveys ja mittlerweile als Grundlage, um eben zu entscheiden, was für Features pushen wir und was für Features wandern in diese Interop-Bemühungen, wo eben alle Browser-Hersteller versuchen, bestimmte Features auf dem gleichen Stand zu bringen in ihren Browsern. Und das war halt bei HTML bisher nicht.
[3:42] Nee, aber wenn man sich da mal in diese GitHub-Diskussion einklingt, die jetzt hier die Quelle für unsere Revision ist, Dann laufen da tatsächlich auch so einige Leute aus den Browserherstellern rum und sagen so diese jene Frage ist für uns besonders interessant.
Also das ist definitiv relevant, dass dahinterher nicht nur die Working-Draft-Revision zuzuhören, sondern auf jeden Fall da auch abzustimmen und mitzuteilen, was einen interessiert und was man schon verwendet und was nicht.
[4:07] Ja, ich weiß nicht wann die geplant ist, wann die fertig sein soll.
Genau, aber ich denke mal, wer uns auf den verschiedenen sozialen Medien, wie auch immer sie heißen, folgt, wird es vielleicht dann auch mitbekommen.
Weil wir das bestimmt auch entweder über unseren Account, also Podcast-Account oder persönlich retweeten oder reposten oder retooten werden.
Reaxen sagt man, glaube ich, jetzt.
Oder reaxen.
Genau, und wir haben hier in diesem GitHub-Repo einfach gesagt, wir gucken da jetzt mal rein und sortieren nach Upvotes, also die verschiedenen Vorschläge, was da so abgefragt werden soll in diesem Survey. Und da sind ein paar Sachen dabei, wo wir auch gesagt haben, okay, die haben jetzt keinen Neuigkeitswert, oder da haben wir schon drüber gesprochen, die würden wir jetzt einfach überspringen, aber es sind halt eben auch einige Dinge dabei, die relativ neu sind oder wo wir noch nicht viel drüber gesprochen haben oder die wir vielleicht auch noch nicht mal kannten.
[5:08] Und genau, würde ich sagen, können wir direkt mal das erste uns schnappen und das wäre das Dialog-Element.
Jawohl, ein aufklappbares, nee, nicht aufklappbares Widget, aber tatsächlich so, dass der typische Dialog, den man sonst per Window Alert macht, mit, ja, eben als HTML-Element, man kann Formulare reinbasteln, man kann beliebigen Content reinbasteln und.
[5:34] Kümmert sich dann halt um so Krempel wie, dass es einen Hintergrund gibt, dass da der Z-Index ordentlich gemanagt wird.
Und dass halt eben auch so Sachen wie Fokusmanagement und so zumindest innerhalb eines Browsers da einigermaßen gleich funktionieren, dass es da von Nutzerseite her auch weniger Überraschungen gibt.
Genau, also es sind ja viele Sachen, die da sozusagen drin gekapselt sind.
Ich glaube, du kannst das, dieses Dialog-Element wahlweise als Modal oder eben auch nicht als Modal öffnen.
Da ist ja der Unterschied sozusagen, dass wenn du ein Modal hast oder Modal, dass dann dein Fokus in diesem Element gecaptured wird und du nicht mehr quasi rauskommst, wenn du es nicht schließt.
Und in der anderen Variante, der Non-Modal-Version, ist das eben nicht so.
Und das hat natürlich zur Auswirkung darauf, wie das so allgemein funktioniert, ob es jetzt wirklich über allem drüber liegt und halt tatsächlich auch mit seinem Background so ist, oder ob das einfach ein HTML-Element ist, das da irgendwo im Flow drin ist.
[6:35] Ich glaube, das liegt schon immer über allem drüber, soweit ich weiß.
Es ist nur quasi, ob das so ein Fokus-Trapping macht oder eben nicht.
Also, das ist, glaub ich, der Unterschied.
Und was ja da auch neu eingeführt wurde, was also in der Browser-Plattform ...
Ich glaube, es gibt noch irgendein anderes Element, das es auch nutzt, das mir grade nicht einfällt.
Aber es gibt jetzt ja so was wie so eine Top-Layer.
Und die kann man sich so ein bisschen vorstellen wie das, in Frameworks wie React, früher unter dem Namen Portal, lief.
Also dass du quasi so eine Stelle im DOM hast, die garantiert immer über allem anderen liegt.
Genau, also weil das Problem ist, also es ist ja ein Trugschluss zu glauben, dass man mit hohen Z-Indexen sich immer quasi über alles andere drüberlegen kann.
Ja.
Weil die ja sozusagen immer wieder ...
[7:29] Weil die Z-Indexe im Prinzip ja immer eingesperrt werden durch Stacking-Kontexts.
Und von denen haben wir halt allerlei auf der Seite. Und da, also man gerät schnell in einen Stacking-Kontext hinein.
Und dann kann man auch mit Z-Index eine Milliarde eben auch nicht mehr aus diesem Stacking-Kontext herauskommen.
Und wenn der eben nicht zufälligerweise auf der obersten Schicht liegt, dann liegt eben auch ein Element darin nicht auf der obersten Ebene.
Und genau, da gibt es eben diese, ich glaube, die heißt auch Toplayer.
Und darin öffnet sich eben dieses Dialog-Element.
Und das hat wiederum dann, glaube ich, den Nebeneffekt, dass wenn du Custom-Properties auf dein Root-Element definierst, sie da nicht hinein vererbt werden.
Zumindest nicht in den Backdrop, der dann hinter dem Model da liegt.
Der ist tatsächlich nicht, äh, ja, custom, äh, property-style, Property-Style war, das stimmt.
[8:31] Ja, ansonsten, tja, also aus, ich denk mal so aus Accessibility-Gesichtspunkten ist es ein super Feature, weil bisher so ein Dialog-Element irgendwie vernünftig zu bauen, war schon ziemlich schwierig.
[8:48] Auch eben dieses Focus-Trapping, dass man eben per Tab oder so nur innerhalb des, sich des Dialog-Elements bewegen kann, aber nicht rauskommt.
[9:00] Das war schon nicht so ganz einfach.
Ich würde das anders charakterisieren. Ich würde sagen, das ist auf jeden Fall sehr einfach, das zu bauen, aber sehr anspruchsvoll, das richtig zu bauen.
Aber je nachdem, was dein Use Case ist, merkst du möglicherweise nicht, wenn du es nicht richtig gebaut hast.
Und dann hast du halt so eine halbgare Lösung da, die zwar irgendwie im aktuellen Beispiel ganz oben liegt und wo das mit dem Fokus auch kein Problem ist und wo du dann denkst, wunderbar, ich brauche mir keine Dependency irgendwie installieren mit dem Ding in fertig aus implementiert.
Selber hinbekommen und dann bist du in deiner eigenen Implementierung irgendwann gefangen, bevor du merkst, dass du da eine ganze Menge Dinge berücksichtigen musst, an die du zuerst nicht gedacht hast, weil sie halt eben nicht offensichtliche Sachen sind, wie das Fokus Management, die Accessibility und so weiter. Ja, wobei ich finde, also ich persönlich finde, wenn man das so bauen wollte, also ich meine, worauf du Bezug nimmst, ist sozusagen, also dass es augenscheinlich einfach ist, so was zu bauen.
Scheinbar.
Ja, okay. Genau. Weil das kommt ja auch später vor, aber vielleicht ist das ein guter Moment, auch das inert-Attribut zu erwähnen. Das ist ja auch relativ neu.
Ich glaube, die kamen so im Gleichschritt, die zwei Features in die Browser.
Wenn du das inert-Attribut auf irgendwas setzt, dann schaltest du quasi jegliche Interaktivität, mit diesen also mit dem Element und seinen ganzen Kind Elementen aus.
[10:26] Das heißt also kannst du nicht mehr rein tabben und nicht mehr nix mehr fokussieren und so, auch mit der Maus nicht.
Aber was ich halt bei dem Inert-Attribut doof finde, weil man könnte ja sagen, ah, cool, ich könnte mir so was ähnliches wie einen Dialog auch mit dem Inert-Attribut bauen, indem ich einfach zum Beispiel auf den Body einen Inert setze und auf dieses Element, was dann eben Fokus trappen soll, da mache ich dann Inert wieder False, sodass das eben alles, was da drin ist, durchaus fokussierbar ist.
So ein bisschen wie bei der CSS-Visibility, da kannst du ja quasi auch auch hidden setzen und darin irgendein Element wieder auf visible und das funktioniert.
Aber leider ist inert nicht so konzipiert. Also es ist kein, du kannst es nicht auf irgendwie false setzen, um dann innerhalb einer inert area das wieder aufzuheben.
Und das finde ich schon ein bisschen schwierig. Also du kannst, du musst quasi dann dein nicht inertes overlay parallel zu, vielleicht einem E-Nerden Rapper um deinen restlichen Content packen.
Sonst klappt das einfach nicht. Hm. Ja, also wenn man sich jetzt wirklich anschaut, wie das inert-Attribut spezifiziert ist, da steht ja buchstäblich drin, wenn inert, dann ignoriert der Browser das betroffene Element.
[11:52] Also wenn das sozusagen wirklich die, ja, die Konzeption ist, dann ist es halt relativ schwierig zu sagen, schwierig zu sagen, du ignorierst dieses Element, um halt eben dann Kind Elemente daraus wieder rauszunehmen, muss man es ja nicht ignorieren.
Ja, aber bei Visibility funktioniert das ja auch und rein vom Bauen her, finde ich, würde sich das eben anbieten, wenn es nicht so wäre, weil wir einfach eine Baumstruktur haben und in der Regel ist ja dann bei solchen Overlays immer der Wunsch, hey, alles andere soll nicht nicht mehr interagierbar sein, außer das, was im Overlay drin ist.
Und das kannst du eben mit dem Inert-Attribut ...
Dann nicht ausdrücken. Mhm. Das ist halt irgendwie ein bisschen ungünstig und schade.
Hätte man vernünftiger konzipieren können.
[12:42] Ja. Aber hey, noch mal ganz kurz, der schwenkt zurück zum Dialog-Element.
Wo du grad schon bei der Kritik an HTML-Elementen und Attributen bist, bei Dialog wär ja noch kritisch anzumerken, dass der Modalmodus ja deklarativ gar nicht aktiviert werden kann.
Also da kann man eine Methode drauf aufrufen, entweder Show für Zeig an oder Show Modal für Zeig halt eben in dem vorhin besprochenen Modalmodus an.
Aber da gibt es kein Attribut für.
Kannst du denn Dialog überhaupt öffnen ohne JavaScript? Es hat ein Open Attribut.
Das kannst du einfach per HTML setzen.
[13:17] Ach so, okay. Ja, okay. Ja, klar. Das ist hier quasi unser nächster Punkt.
Es gibt ja diese Popover-API, jetzt auch relativ frisch.
Bei der haben sie es noch besser gelöst, weil da kannst du quasi sogar sagen, eben wenn ich hier klicke, dann bitte mach dieses Popover auf.
Und das kannst du nur mit HTML und Beziehungen zueinander ausdrücken.
Also dann eben ähnlich wie, wie du eine Beziehung zwischen Label und Input ausdrücken kannst.
Genau, das fände ich halt richtig cool, weil das Open Attribut musst du ja dann auch von Anfang an setzen.
Dann ist halt dieses Dialog-Element offen.
Aber so einen Weg, das quasi per Knopfdruck dann öffnen zu lassen, nur deklarativ per HTML, das geht ja auch nicht.
[14:12] Nö, man kann beides haben. Also ich meine, es ist ja okay, wenn du irgendwie, also schau dir ja irgendwie die Classlist an.
Also hast du ein Attribut, kannst du es damit setzen oder du kannst es halt eben auch über die Classlist JavaScript API toggle.
Und bei so Sachen, wo es letztlich einfach ein Zustands-Switch ist zwischen ist jetzt da oder ist nicht da oder ist jetzt in diesem Modus oder in jenem Modus, wenn du mich fragst, die all diese Varianten geben, weil es halt eben all diese Use Cases gibt von halt irgendwie, Ich mach das mit so einem jQuery-artigen Ansatz auf, oder ich mach halt irgendwie React, da ist alles deklarativ, oder ich render das vom Server schon so raus, oder, oder.
Naja, das stimmt, aber du kannst halt nicht ... Also, wenn du jetzt sagst, ich möchte nur deklarativ irgendwie ausdrücken, dass, wenn man auf diesen Knopf drückt, dass dann ein Dialog aufgeht.
Ja. Also, wenn du das ... Das kannst du ja nicht. Also, entweder er muss von Anfang an per Open Attribut eben offen sein, Und wenn er das nicht ist?
Dann kannst du ihn auch nicht nur mit Dingen, die du ins HTML schreibst, öffnen lassen.
Nee, da brauchen wir das HTML-X für.
[15:20] Genau, und das geht halt mit der Popover, oder mit dem Popover-API heißt es.
Aber letztlich sind das HTML-Attribute neue.
Ja.
Und das finde ich eigentlich ganz gut. Ja, es ist, also ich meine, es sind die HTML-Attribute, Und es ist halt tatsächlich auch eine Extension, was so die JavaScript-Sachen angeht. Also, das ist im Prinzip, wie ich das Dialog-Element ganz gern hätte.
Also, man kann sagen, Hide-Popover, Show-Popover, Toggle-Popover und so weiter.
Und halt eben, dass man das Target setzt, ist halt eben per Attribut, das macht ja auch irgendwie Sinn.
Ist ja irgendwie ein Key gleich irgendein Value.
Und da ist ja Attribut auf dem Element tatsächlich ja das einigermaßen idiomatische Mittel, um sowas auszudrücken.
Also, ich finde, das passt schon. Das ist halt ein bisschen besser und vollständiger von der API her als das Dialog-Element.
Ja, genau, find ich auch. Aber das kann man ja noch nachrüsten.
Was ist der Unterschied zwischen Dialog und Popover?
Also, in beiden Fällen wird ein ...
[16:21] Ja, im Prinzip ein Overlay geöffnet. Ich glaub, das Popover-Overlay-Dingsbums ist auch in dieser Toplayer.
Ich weiß nicht, ob ich an das eben gedacht habe. Genau, aber das Dialog-Element ist tatsächlich eher so, sagen wir mal, ohne Bezug zu einem spezifischen Element.
Und bei dem Popover, das verankert sich ja ...
An einem anderen Element. Genau, Popover würde ich beschreiben als ein etwas von den Funktionalitäten her eingeschränkteres Dialog mit einem bestimmten Target-Element, auf dem das drauf ist.
[17:03] Also du hast jetzt, glaube ich, ein Popover, der Popover kann jetzt nicht dein Form-Target sein, wie das ja beim Dialog-Element der Fall ist. Ja.
Genau, und das Popover, die Popover-API bringt im Schlepptau auch mit dieses Anchored-Positioning in CSS, dass man eben auch ohne Popover nutzen kann, um, also ähnlich wie man bei Position Absolut Dinge positionieren kann, oder Position Fix kann man eben auch hier Anchored Positioning verwenden, um ein Element am anderen zu verankern.
Also ich meine, das geht mit Position Absolut ja im Grunde auch einigermaßen. Der Unterschied ist aber, dass bei diesem Anchored Positioning der Browser auch schaut, wo ist denn gerade mein Viewport zu Ende?
Und wenn das eben rausragen würde, dann würde er es eben auf die andere Seite packen, wo es nicht rausragt. Genau.
[18:04] Was man sich halt sonst echt mühsam, mühsam erarbeiten müsste.
Also, geht halt schon mit Absolute Positioning, aber halt mit erheblichem Mehraufwand, über die absolute Positionierung hinaus.
Genau, und so der Klassiker ist ja eigentlich hier Popper.js.
Das benutzt man für so was.
Und das ist auch so ...
Ich bin ja ein großer Fan von Hand-Rolled-Sachen, aber so das ist einfach ...
So nervig und eklig. Das macht, da nehme ich dann auch Popper.js dafür.
Naja, und warum würdest du es nicht machen? Weil ich meine, der Use Case ist so klar abgegrenzt.
Wenn jetzt irgendwie Popper.js irgendwie vor die Hunde geht, auf welche Weise auch immer, da findest du entweder sofort einen guten Ersatz oder einen sehr guten Ersatz wird sich relativ bald ergeben.
Das ist ja auch nicht deine ganze Applikation da drin irgendwie eingebaut, wie irgendwie, wenn du jetzt eine Angular App schreibst und Angular geht vor die Hunde, dann hast du ein ernsthaftes Problem, das so ohne weiteres nicht reparabel ist, aber da tauschst du halt die Libraries aus und verbringst irgendwie drei Zeilen Code, damit das irgendwie noch anzupassen und zu justieren, dann läuft die Kiste, würde ich auch sagen.
Das ist ein völlig okayer Use Case.
[19:11] Genau, oder eben in Zukunft, wenn denn die ganzen Browser sich einigen, die Popover-API, zu implementieren, oder zumindest das Anchored Positioning, dann, naja, die Popover-API wäre schon schöner in ihrer Gesamtheit.
Dann bräuchte man eben Popper.js nicht Und, ähm, genau, das wär jetzt zum Beispiel ein schöner Outcome des State-of-HTML, wenn das jetzt da drin landet und die Leute sagen, ich hab da total Bock drauf auf die Popover-API, dann würden vielleicht die Browsersteller sagen, okay, dann lass uns das in unsere Interop 2024 oder so mit reinnehmen und dann ist es nächstes Jahr hoffentlich in allen Browsern.
Das sieht ja schon mal so schlecht gar nicht aus. Also, die Chrome-Crew hat das schon.
Bei Firefox ist es drin, aber hinter einem Flag und bei Safari ist es in Pre-Releases schon drin.
Also, ich will jetzt nicht sagen, dass man nicht dafür stimmen sollte beim Survey, aber es wird wahrscheinlich auch so relativ bald weit verbreitet sein.
[20:18] Ja, genau. Und die Popover-API, die kommt aus einer recht interessanten Community.
Es gibt ja diese Open UI Community Group, die sich hingesetzt hat und gesagt hat, Was sind denn eigentlich die immer wiederkehrenden, aber harten Herausforderungen beim Gestalten von UI?
Der Klassiker ist, ich möchte einen Select stylen.
Aber das sind eben noch ein paar andere Dinge. Und Popovers bauen ist eins davon.
Und ich glaube, auch im Verlauf dieser Aufnahme werden wir immer wieder auf Dinge kommen, die eben aus dieser Open-UI-Gruppe gekommen ist.
Ja, wollen wir da mal zu dem Select-Problem kommen mit dem Select, ehemals Select-Menü, jetzt Select-List?
Also, genau, Select-Menü ist, glaube ich, gerade vorgestern oder vorgestern wurde das irgendwie per Beschluss auf Select-List geändert.
Ich weiß, ich hab's nur mitbekommen, ich weiß nicht, warum das so ist.
Weil mit Menü einfach noch was anderes gemeint ist.
Es gab ja, glaub ich, auch dieses, äh, gab's nicht auch mal Menü?
Ähm ... Als Element, aber nur in Firefox unterstützt oder so.
Irgendwie so was Obskures gab's da mal, ja.
[21:44] Genau. Ja, ich glaub, Select Menü oder Select List, da sind die meisten wahrscheinlich schon drüber gestolpert, ist letztlich eine neue Konzeption von Dropdowns, die eben zum Ziel haben, dass sie gestaltbar sind, aber dass man eben auch so Dinge bauen kann, wie vielleicht searchable Selects und also so die ganzen Use Cases abbilden kann, für die man bisher irgendwelche Libraries benutzt hat.
Also eine, die mir einfällt, die man früher viel benutzt hat, ist Select 2, die noch jQuery gestützt war.
Also du kannst im Prinzip auch dann in dieses Dropdown kannst du beliebiges HTML stecken, ob das immer Sinn macht, ob man es tun sollte, ist die Frage, aber es geht und es wird eben auch darauf geachtet, dass Accessibility Dinge weiterhin funktionieren und eben in dieses Teil eingebacken sind.
Ja, eine richtige Spezifikation dafür sehe ich jetzt noch nicht.
[22:52] Also dieses, was wir da von OpenUI jetzt haben, ist ja wirklich mehr so eine Art High-Level-Explainer.
Das taugt, glaube ich, hinterher wirklich sehr gut für Copy-Paste nach MDN.
Mit so Beispielen und Zeug. Aber ich bin da ja mal wirklich sehr gespannt, wie das am Ende tatsächlich hinhaut, weil das ist, glaube ich, schon eine relativ extrem knifflige Angelegenheit, das zu machen.
Weil du hast halt so Sachen wie interaktive Elemente in interaktiven Elementen drin.
Also dein Select, was searchable ist, oder dein Dropdown-Item, wo dann halt irgendwie noch Unterseitelemente anzuklicken sind.
Das ist ja inherent schon mal ziemlich hakelig, das muss irgendwie gestaltbar sein, aber da sollen die Leute sich auch nicht irgendwie in Schwierigkeiten bauen können.
Und das Problem ist halt eben, das hatten wir mal vor ewig langen Zeiten bei so Diskussionen über sortierbare Tabellen, glaube ich, wo ich halt so ein bisschen skeptisch bin, ob das so wirklich ohne weiteres möglich sein wird, eine Lösung zu finden in HTML, die tatsächlich alle Use Cases von allen Nutzern von HTML irgendwie abdeckt, oder wirklich so diese 80%-Schwelle, die vielleicht so ein Dialog oder so ein Popover erreicht, da wirklich abdeckt.
[24:01] Und ich bin mir nicht sicher, ob man das wirklich so gut hinkriegt, dass man das am Ende im Standard hat, und 80% von allen nutzen das, versus wir haben irgendwie so eine Katastrophe wie irgendwie ein Input-Type Date, was irgendwie ja auf dem Papier sehr gut aussieht, aber in der Realität halt so viele Spezialitäten und Sonderanpassungen jeweils immer braucht, dass es vielleicht besser gewesen wäre, das einfach sein zu lassen und zu sagen, das ist out of scope, nehmt halt weiter eure Diffs, das geht ja bisher auch.
Naja, vielleicht muss man die Frage stellen ...
[24:32] Also, vielleicht muss man weniger die Frage stellen, ob das, was man damit baut, dann ...
Perfekt ist. Sondern einfach nur, ist es ...
Es ist ein fortschritt gegenüber dem wie es halt heutzutage oft gelöst wird und da glaube ich dass es schon der fall ist.
Moment, würde ich nicht sagen, dass das stimmt, weil nur Fortschritt reicht nicht, weil du wirst es ja nie wieder los.
[25:00] Also, das muss halt tatsächlich, wenn du jetzt ein neues Element einführst, ja schon irgendwie sitzen, weil sonst, wie gesagt, Input-Type Date.
Mhm. Also, wo halt eben irgendwie alle, die sozusagen das Versprechen von diesem Widget brauchen könnten, alle, die sozusagen die eigentliche Zielgruppe sind, dann doch so spezielle Anforderungen haben, dass sie sagen, da kriegen wir eh nicht so hin, wie wir es haben wollen, dazu ist die ganze API zu eingeschränkt, weil halt eben so Dinge wie halt irgendwie das Management von verschachtelten interaktiven Elementen und so weiter, der Gestalt halt dann einschränkend ist, um sozusagen den generellen Case irgendwie abzudecken, dass um unseren speziellen Case umzusetzen, wir eh wieder bei den Diffs oder bei irgendwie Select-To und ähnlichen Dingen landen.
Also du meinst, dass es dann nicht so gut ist und dass die Leute es dann auch nicht verwenden?
[25:48] Schwierig, ne? Ich würde halt wirklich sagen, Datepicker klingt jetzt für mich einfacher umzusetzen, als jetzt dieses Select-List-Element mit seinen ganzen Komplikationen.
Und da hat es schon nicht geklappt. Und ich glaube, bei HTML tendiere ich echt so ein bisschen so zum Minimalisten, weil das ist halt wirklich so der Layer, an dem kommt halt wirklich keiner vorbei.
Egal, wie viel React man baut, am Ende ist es HTML. Da kommt man nicht dran vorbei, und das muss halt wirklich irgendwie, wenn man da was einbaut und man es nicht wieder loswerden kann, der Gestalt sein, dass es wirklich unmittelbar nützlich ist.
Und das kann ja gerne irgendwelche Trade-offs haben und Nachteile.
Inert-Attribut ist irgendwie jetzt nicht für jeden Use-Case das Richtige, aber ich glaube, so alles in allem ist es schon auf eine Art und Weise so nützlich, dass viele das verwenden werden.
Und bei Selectlist, wie gesagt, sehe ich halt so ein bisschen das Problem einer überschaubaren Zielgruppe mit sehr speziellen Anfertigungen, die vielleicht dann doch eher besser damit bedient sind, die Dinge von Hand nachzubauen oder irgendeine Library zu verwenden.
Nicht für jeden Use Case muss es ein HTML Element geben, würde ich damit sagen.
[26:49] Ja, nee, also, würd's auch nicht geben. Ich glaub, damals hattest du ja auch als Beispiel, ähm, glaub ich, Tabs und ...
Tabs waren ganz genau, darüber haben wir geredet. Genau, und da ging's aber ja auch vor allem darum, wie ...
Also, dass, wenn's solche Elemente gibt, müssen auch so ...
Also, müssen auch Smartphones eine Idee haben, wie sie so was abbilden können.
Und vielleicht ist das bei den Tabs ... Smartphones, alle Geräte, die jemals kommen werden.
Ja, genau. Aber Smartphones sind ja schon so ein erster konkreter Fall, wo man kennt das ja, wenn man so Tab-Container baut.
Und wie funktioniert das denn da, wenn irgendwie die Tabs mehr sind als Platz ist? Bricht das dann um?
Oder stellt ein Smartphone das vielleicht irgendwie direkt anders dar?
So ähnlich wie native Selects ja dann auch irgendwie anders funktionieren? Genau.
[27:46] Naja, und vor allen Dingen, du hast halt letztlich so unterschiedliche Dinge, die dich in dieses Problem reinführen können. Also, du hast auf dem Smartphone in der Horizontalen zu wenig Platz, was machst du? Naja, das dürfte halt darauf ankommen, auch wodurch der wenige Platz zustande kommt. Also hast du jetzt viele Tabs oder hast du zwei Tabs, in denen extrem viel drinsteht?
Weißt du, dass es irgendwie höchstens drei Tabs werden können aufgrund deines Use Cases oder musst du damit rechnen, dass es 300 werden? Daran entscheidet sich halt eben, ob du dann umbrichst oder die Dinge auf so ein Icon minimierst, wie bei einem angepinnten Tab im Browser, wo du auch du daraus dann irgendwelche um 90 Grad gedrehten Tabs machst, die du an die linke Seite klatscht oder oder oder.
Und das können alles je nach Use Case vernünftige Lösungen sein, aber weil das alles vernünftige Lösungen sein können, müsste ja ein theoretisches HTML-Element, das das alles berücksichtigen muss, das alles implementieren.
Und dann fängt's halt, glaube ich, an, richtig hakelig zu werden.
Weil du hast ja letztlich auch irgendwelche Schriften, die du von links nach rechts, von rechts nach links oder von oben nach unten liest.
Und wie machst du das dann mit den Tabs? dann musst du halt so ähnlich wie bei Flexbox und Grid-Layout eine eigene Sprache entwickeln für da läuft's lang, da läuft's lang.
Ich meine, du könntest die natürlich auch adaptieren, aber dann musst du irgendwie HTML und CSS im Gleichschritt da entwickeln lassen.
Und je mehr ich drüber nachdenke, umso weniger gefällt mir das.
Und deswegen denke ich, Leute, nehmt's JavaScript, nehmt's HTML, nehmt's CSS, dafür ist es da.
Wenn ihr was Spezielles haben wollt, dann macht das.
Wenn ihr was weniger Spezielles haben wollt, nehmt dann eine Library.
Und ansonsten braucht ihr vielleicht auch einfach gar keine Tabs, sondern einfach nur eine Liste von Zeug.
[29:11] Ja, da sagst du wahres. Wenn wir jetzt eh schon in dieser Open-UI-Gruppe sind, dann lass uns doch noch schnell Breadcrumb erwähnen.
Oh ja! Ganz wichtig.
Genau, das kommt auch von denen. Ich glaube, da der Antrieb ist, dass sie das auf den Tisch gebracht haben, ist letztlich eigentlich nur, dass die, wenn man die per Hand zusammenbaut, die Leute das nicht korrekt auszeichnen.
Mit entsprechenden Accessibility-Attributen, also mit keinem angemessenen Role, keinem Area-Current draufsetzen auf das aktuell aktive Element.
Ich glaube, dass das wahrscheinlich daherrührt, oder? Und dass man das einfach kapselt in einem Red-Crump-Element.
Nee, also, ja, das mag die Intention sein, Aber warum nehmen die Leute nicht das nav-Element?
[30:11] Also, das ist ja das, was im Grunde dann hier im Vorschlag, glaub ich, unten drunter schlummert.
Weiß ich nicht. Also, ich nehm das nav-Element und setz dann noch ein ARIA-Label drauf. Ja.
Bei dem, ähm, aktuellen Element, da nehm ich dann in der Regel, verlink ich das nicht mehr in der Breadcrumb, sondern setzt eben nur ein aria-current-page drauf.
Genau. Und damit machst du ja sozusagen wirklich alles, was für eine vernünftige Breadcrumb-Navigation getan werden muss.
[30:46] Möglicherweise ist die sogar einigermaßen benutzbar, wenn das ARIA-Current da nicht drauf ist, weil es ist halt die Breadcrumb-Navigation, das ist ja ein Pattern, das erkennt man dann ja wieder, und weiß das zu benutzen.
Deswegen scheint mir das mehr so eine Art zu sein, die Leute benutzen das Nuff-Element nicht, also geben wir ihnen das Nuff-Element mit einem anderen Namen und hoffen, dass es diesmal funktioniert.
Irgendwo hat auch der Einstein mal was über Wahnsinn gesagt, oder?
Wenn man immer wieder das Gleiche probiert Ist das vielleicht nicht so clever?
Vielleicht, ja. Also, ich zweifle da echt hart dran. Vor allen Dingen, Breadcrumb-Navigation ist ja auch so ein arg spezifisches Navigationspattern, das ja auch nur in einer Welt der breiten Bildschirme Sinn ergibt, und wo ich halt immer sofort an Web 2.0-Farbverläufe denke.
Ich hab so ein Ding schon länger nicht mehr benutzt.
Das scheint mir also wirklich so eine Art Media-Type-TV zu sein.
Was echt ... Ja, wie meinst du, das ist der Grund, warum die eingebaut werden, zumindest aus meiner Erfahrung, dass Zeo das gerne hätte.
Aha. Ähm, genau. Also, das war bisher eigentlich immer der Grund, warum ich Breadcrumbs eingebaut habe.
[31:58] Ich find halt, bei irgendwie komplizierten, tief verschachtelten Sachen ist das ja zur Navigation sicherlich auch nicht schlecht.
Du liest irgendwie so die ECMA-Skript-Spezifikationen und du hast dann diesen Table of Contents an der Seite weil das Label of Contents halt dann 70 Unterpunkte hat, ist das nicht unbedingt zur Orientierung hilfreich, weil du halt irgendwie beim genug Scrollen nur 10 Punkte nach oben, 10 Punkte nach unten siehst.
Aber wenn du jetzt irgendwie sowas hättest wie, ich bin hier, Unterkapitel hier, Unterkapitel da, Unterkapitel dort, das würde ja auch außerhalb von SEO noch Sinn machen.
Das gebe ich ja. Aber das sind halt super spezielle Use Cases, die lassen sich halt mit Bordmitteln auch super umsetzen.
Und SEO ist ja auch so eine schöne Sache. Es herrscht nicht Konsens darüber, dass diese ganze Submaschinen-Geschichte eh für den Arsch ist alles demnächst von von AI erledigt wird, dann muss man da ja auch eh nichts für optimieren.
[32:45] Vielleicht genau aber noch noch herrscht dieser konsens nicht und ich meine das auch nur ich meine das tatsächlich nur halbtrollig also es reicht ja schon seo will das heißt ja im prinzip irgendwer der was zu sagen hat will das. Im wesentlichen.
Joa, vielleicht, ja. Und das ist ja auch tatsächlich keine Naturkonstante.
Dass es irgendjemanden gibt, der was zu sagen hat, der genau das will.
Also, das in ein HTML-Element zu gießen, halte ich halt wirklich für ziemlich knifflig.
Nimmst NUV-Element, packt noch ein ARIA-Current drauf, so wie der Chef das gesagt hat, und dann ist super.
Gegen das Ding würde ich tatsächlich aktiv gegenvotieren, weil das sorgt halt nur für Verwirrung.
Diese ganze Diskussion. Ja, was zählt denn als Navigation? Ja, guck in die Spezifikationen, Major Blocks of Navigation. Ist das jetzt noch eine Breadcrumb-Navigation oder ist es eine andere?
Weil ich benutze halt irgendwie nicht da so diese Feilchenstruktur, da man liest es halt in die in die andere Richtung, bla Keks, das macht es ja alles wirklich nicht besser.
Ja. Ich bin spartvoll.
Ich tendiere übrigens dazu, in Navs gar keine Listen mehr einzubauen.
[33:56] Ich mach das, wenn ich so ein strukturierendes Element noch brauche. Also halt ...
Kannst halt links reinpacken und irgendwie mit Grid und Flexbox kannst du die ja bequem stylen.
Okay, wenn du quasi so einen Steigbügel brauchst, so eine Rollbarleiter für deinen Anfasser, für deinen CSS, dann entscheidest du dich für eine Liste und ansonsten nicht.
Genau, weil sonst müsste ich ja ein DIV nehmen. Und dann ist da halt schon irgendwie ein bisschen nicer, auch so unter dem Szenario, irgendwie CSS ist kaputt oder sowas alles, ne?
Ja. Aber brauchst du halt heutzutage nicht mehr, weil schön ist neues CSS.
Mhm. Ja.
[34:32] So, dann könnten wir jetzt, wenn du magst, mal kurz auf Lazy Loading zu sprechen kommen. Sehr gerne.
Das ist ja an sich auch nichts Neues mehr.
Also, äh, man kann per Loading gleich Lazy auf Bildern und iFrames und sonst aber nix, ähm, sagen, dass etwas eben erst geladen werden soll, wenn es nah genug am Viewport dran ist.
Mhm. Ähm, ist ganz cool.
Hab ich immer mal wieder Probleme mit iOS übrigens tatsächlich, dass der abschmiert.
Er stürzt ab. Er stürzt einfach ab. Das ist ja bei iOS so, wenn die einen Fehler haben, dann stürzen die einfach hart ab.
Sodass ich im aktuellen Projekt tatsächlich immer noch alles in No-Scripts kapsle und dann per Intersection Observer die Bilder dann aus dem No-Script herausziehe, wenn sie nah genug dran sind.
Also nur wegen iOS.
[35:35] Genau, aber vielleicht ist es auch, das ist halt so eine E-Commerce-Seite, ganz viel Bilder auf so einer Übersichtsseite zu sehen sind.
Und vielleicht ist es dann auch erst ab einer gewissen Menge Bilder, dass iOS dann abkackt.
[35:49] Okay, das ist eine Erklärung, aber keine Entschuldigung, weil du solltest einem Webbrowser Webseiten vorsetzen sollen und dann soll der das irgendwie verarbeiten, wenn er die Bilder nicht anzeigen kann.
Dann zeigt er die Bilder nicht an, aber abstürzen ist ziemlich inakzeptabel.
[36:02] Ja, also es liegt definitiv daran, weil wenn man es eben wegnimmt, stürzt er nicht ab.
Und es gibt ja auch diese Log-Files, die er noch irgendwie schreibt, diese Debug-Logs, die man sich rausholen kann. Und da sieht man dann auch, dass er eben mit dem Laden von Bildern beschäftigt war.
Genau, aber ...
Das ist jetzt sozusagen als kleine Anekdote am Rand. Was jetzt neu hinzukommt, wo ich Lazy Loading sozusagen nur als Aufhänger sehe, ist, ähm, äh, beim...
Du kannst ja, bei den responsiven Bildern kannst du ja mit Source-Set und Sizes arbeiten, ne? Das ist sozusagen der...
Beim Picture-Element. Nee, beim Image-Element kannst du das ja auch.
Du brauchst dafür kein Picture-Element.
Das ist sozusagen der einfachste Ansatz. Und Picture bräuchtest du dann erst, wenn du jetzt zusätzlich noch verschiedene Dateiformate bereitstellen willst.
Dann geht das nicht ohne. Und da habe ich übrigens gerade erst letztens gelernt, dass Microsofts Edge immer noch kein AWIF kann. Obwohl der Chrome das seit Version 85 schon unterstützt.
Und der Edge ja auf Chromium aufbaut.
Aber anscheinend hat das irgendwie was mit Patent-Trollen zu tun, dass wir es immer noch nicht aktiviert haben.
[37:24] Okay, möchte ich jetzt gerne mal den Patent-Troll kennenlernen, vor dem Microsoft Angst hat, aber Google nicht. Das hört sich nach einer sehr starken Spezialisierung an.
[37:35] Ja, ja, keine Ahnung. Also das ist, gelesen habe ich das bei Alex Russell.
Der hat das eben irgendwann mal als Grund genannt.
Genannt. Also hätte ich auch nicht gedacht, muss man wissen. Jedenfalls bei dem Sizes-Attribut ist es ja so, da gibst du in so einer Art Media-Query-versehenen Schreibweise ja an, an, wie groß wird ein Bild dargestellt im Fenster.
[38:12] Und dann kann der Browser darauf basierend sich angucken, ah, okay, hier ist mein Source-Set-Datei-Strauß.
Und wenn das irgendwie 30 Prozent der Viewport-Breite sind, und ich bin auf dem mobilen Gerät, dann brauche ich jetzt mal ein Bild, das ungefähr 100 Pixel Breite hat.
Und was daran halt doof ist, ist, dass wenn du so eine zentrale Image-Komponente hast, die du immer wieder überall einsetzt, dann musst du auf einmal die im HTML konfigurieren mit Layout-Informationen.
Dafür ist ja eigentlich CSS da und im Zweifelsfall ist das vielleicht auch gar nicht so einfach für jemanden, der so eine Komponente einbindet, das schon irgendwie zu wissen.
Das heißt, es geht eigentlich immer nur im Gleichschritt mit dem CSS, was du dazu schreibst.
[39:06] Und da gibt's jetzt den Vorschlag, zumindest bei lazy-loadenden Bildern ein Sizes gleich Auto möglich zu machen, weil lazy-loading ja auch darauf fußt, dass erst das CSS ausgewertet wird.
Weil erst dann weiß ja der Browser, wo ein Bild im Layout ist und ob das eben nah am Viewport ist oder nicht.
Und wenn er bei dem Lazy Loading sowieso auf das CSS wartet, also was auch wirklich so ist, dann kann er ja auch aus dem CSS heraus ablesen, wie breit das Bild ist. Und dann muss das die Person, die eben das HTML zusammenschraubt, nicht schon vorab definieren.
Und ich denke, das ist auf jeden Fall eine sinnvolle Sache. Und genau, nur bei den eben nicht-lazy ladenden Bildern, was jetzt im Prinzip die wären, die unmittelbar zu Beginn im Viewport sind, da müsste man dann eben weiterhin dieses Sizes-Attribut korrekt setzen.
[40:16] Und vielleicht noch so ein Nebenaspekt des Ganzen ist, wenn ihr all eure Bilder lazy ladet, Und dann schaltet ihr damit eurem Largest Contentful Paint, weil eben der Browser das wichtige erste Bild eben nicht rendern kann, bis er denn nicht das CSS auch tatsächlich ausgewertet hat.
Du guckst so nachdenklich?
Ja, ich bin noch am überlegen. Das heißt, wenn ich jetzt sozusagen das Loading gleich lazy gesetzt habe und das Ding ist beim ersten laden der Seite direkt im Viewport, dann passiert was nochmal?
[41:01] Dann weiß der Browser das ja erst, wenn das CSS ausgewertet ist und das Layout berechnet ist.
Ja, und dann kann der, äh, der Ressourcenscanner aka Pre-Parser, der schon vorab durch das Dokument geht und versucht, eben alle Bilder und Skripte und Style-Sheets, ähm, schon mal in die Queue zu werfen, der würde das dann eben einfach noch nicht laden.
Das heißt, du verlierst Zeit, und zwar so viel Zeit, wie zwischen Pre-Parser geht über die Seite, CSS-Dateien wurden alle geladen und wurden auch ausgewertet.
[41:50] Okay, gut. Verstanden. Dann ergibt das jetzt Sinn. Das musste das nur kurz noch enttütteln, weil ganz so trivial ist es ja nicht.
Nee. Also ich denke auch, dass dieses Auto kommen wird.
Es macht ja total Sinn, beziehungsweise das Verhalten, das nicht sozusagen der jetzige Normalfall ist, ist ja schon ein bisschen schwach.
Ja. Ja, wo dieses Sizes-Attribut auch ein bisschen querschießt, ist, wenn du anfängst, mit Container-Queries zu arbeiten.
Ja. Da würde so ein Sizes-gleich-auto auch helfen. Bei Container-Queries, du kannst ja ein Sizes-Attribut sozusagen nicht ausdrücken in Container Currys und da bin ich mal gespannt, ob da noch Lösungen kommen und wenn ja, welche.
[42:47] Ja, es ist ein bisschen unglücklich, dass diese Syntax, sowohl Sourcet als auch Scythe, so eine Ad-Hoc-DSL ist für halt den spezifischen Use Case dieser spezifischen Attribute auf diesem Element. Das ist schon ein bisschen unglücklich, weil das halt die Interaktion mit den ganzen anderen Sachen, die da so sind und kommen, verkompliziert. Gerade so Sizes ist ja wirklich, sieht ja aus wie Media Query, ist es ja also quasi auch so ein bisschen vielleicht, aber schon so ein bisschen ein bisschen falscher freundgefahr.
[43:19] Tja. Hätt's mal alles Jason machen müssen, das hätt's geholfen.
[43:26] Ja. Jason hätte geholfen.
Aber dann hätten wir die Leute, die dauernd rumpöbeln von wegen, da müssen aber Kommentare drin erlaubt sein, auch in den Diskussionen um HTML, wär vielleicht auch nicht gut.
Ich guck grad durch die Liste durch, was wir uns als Nächstes schnappen.
Hier sind Sachen drin wie InlineSVG, die find ich jetzt nicht so ...
Oder ist ja nicht so spannend, Picture-Element. Weiß ich nicht, ob man da jetzt irgendwie noch drüber reden muss.
Ich hätte so zwei Sachen, da hätte ich tatsächlich im Sinne der Survey tatsächlich so die Fragen an dich, was mich interessieren würde. Du als so praktischer Mann aus dem Schützengraben.
Wie sieht denn so deine Benutzung vom Template-Element aus? Eigentlich eher mau.
Ich meine, gerade benutze ich das für irgendwas? Nö, ich glaube nicht.
Okay. Finde ich nämlich interessant. Ich benutze das nämlich auch für nix.
Weil es scheint mir halt von der Konzeption her außerordentlich seltsam, ein Template zu definieren in HTML.
Und vermutlich, um Templating durchzuführen, brauche ich ja wahrscheinlich JavaScript, also eine andere, ganz andere Sprache. Und das dann irgendwie cross-referenzieren, sozusagen per GetElementById und Consorten, ist ja schon mühsam.
Wahrscheinlich wäre es einfacher, sich dann, keine Ahnung, mit einem entsprechenden Tag-Template-Literal da was ins JavaScript direkt reinzubauen oder JSX zu verwenden oder, oder, oder.
[44:54] Das ist nämlich halt eben auch mein Eindruck, dass das relativ.
[44:58] Sagen wir mal, overstated ist, was das so zu leisten vermag.
Und deswegen bei vielen außerhalb jetzt da, wo das irgendwie in so ein Framework-Kompilierprozess eingebaut ist, irgendwie nicht so richtig viel Verwendung findet, ist so mein Eindruck.
Plus, es fehlt ja das Wichtigste an so einer Templating-Sprache, nämlich irgendwie die Möglichkeit, das Zeug rein zu interpolieren.
[45:18] Ja, da hatte ja Apple irgendwann mal einen Vorschlag gemacht vor Ewigkeiten.
Das hatten wir dann auch mal hier bei uns erwähnt.
Ich weiß noch nicht mehr genau, wie das hieß.
Ja, aber da müsste es eigentlich vorangehen an der Stelle.
Oder jemand müsste halt hingehen und müsste sagen, wir bauen so eine Art ab dafür.
Es gibt ja genug Templatesprachen da draußen, die irgendwie in der Lage sind, da Mustache, JS und ähnliches irgendwie in so Content reinzufriemeln.
Das passiert halt nun meistens entweder serverseitig oder irgendwie auf String-Ebene.
Aber allein schon so einen Adapter zu haben, dass man irgendwie sagen kann, das Ding verwendet als Input-String tatsächlich irgendwie ein Template-Element.
[45:58] Und holt sich dann davon irgendwie das innerHTML oder was auch immer und macht dann seinen ganzen Substitutionskram darauf.
Das würde ja, glaube ich, schon was helfen. Das würde ja zumindest mal dieses, ich will irgendwie standardkonform sein, irgendwie zu haben.
Man kann ja auch das Template-Element als so eine Art einfach nur String-Wrapper verwenden.
Also man muss ja nicht wirklich ein Template-Element als HTML in seinen Content reinschreiben, man könnte ja wirklich irgendwie sagen, ich bin eine Funktion, ich mache dieses Templating-Interpolationsgebimsel und als Input verwende ich ein Template-Element, und kann es das ja auch mit Document-Create-Element oder so erzeugen.
Ja. Aber da fehlt es halt wirklich, die Nützlichkeitshürde wird nicht genommen, dass diese entsprechenden Libraries nachziehen würden, um das zu machen. Und bei der Apple-Geschichte bin ich jetzt auch so in meinem aktuellen HTML-Minimalismus-Trip so ein bisschen auf der Frage, okay, kriegt man das wirklich hin, die Templatesprache da zu definieren, die in HTML dann drin ist und die dann auch den Test der Zeit besteht. Und wenn ich mir so angucke, wie viele Templatesprachen es da draußen gibt, bin ich da eher ein bisschen skeptisch, dass so der nächste Schuss dann definitiv ein Erfolg wird.
[47:06] Ja, wahrscheinlich nicht, aber es steht halt Web Components auch einfach im Weg, dass das nicht geht. Tut's das?
Naja, ich würde schon sagen. Also, wäre doch schön, wenn die Plattformen da was anbieten würde und man nicht LIT oder was weiß ich was benutzen müsste.
Ja, naja, wie gesagt, das stößt halt auch wieder an meinen, kriegt man das dann wirklich korrekt, so also richtig hin, gibt es da die One-Size-Fits-80-Prozent-Lösung? Da habe ich halt so ein bisschen, ist halt schwierig, weil das, weil da wird halt echt so ein großes Rad gedreht und da muss halt wirklich, muss man halt irgendwie auch wirklich sagen, dem Scope-Creep halt auch zu widerstehen Und zu sagen, so brauchst du jetzt nicht Selection und Article vielleicht.
Hätte auch eins gereicht, weil wir kennen doch unsere Nerds, die werden entweder das gar nicht wissen, oder sie werden es falsch verwenden, oder wenn sie, sagen wir mal so, die Geistesgegenwart haben, es richtig zu verwenden, werden sie elendige Diskussionen darüber auslösen, wann man jetzt was verwenden sollte.
Also entweder, wenn es klar ist und einen einigermaßen verdaubaren Scope hat, eine html element ja und ansonsten das template halt so ein bisschen so ein rohrkrepierer mein Einer meiner meine andruck.
[48:34] Da hast du recht und einen weiteren Survey Eintrag wollte ich auch noch mal hier vor die Nase werfen. Wie gesagt, du jetzt hier als mein Kontakt in die Realität. Das jetzt unser Service Eintrag Custom, Elements. Da wird ja nachher sicherlich wie bei State of JS sowas drin sein, wie irgendwie verwende ich ständig verwende ich manchmal habe ich noch nie von gehört.
[48:55] Wie ist es bei dir? Nee, also benutze ich auch tatsächlich nicht das Das Einzige, das ich jetzt letztens mal verbaut habe, ist das Google Chromecast Launcher Element.
Wo im Prinzip die Library in Form eines Elements daherkommt.
Ja, also du lädst deren Framework Und dann baust du eben an die Stelle, wo du eben diesen Cast-Knopf haben möchtest, dann baust du eben das, ich glaube, das heißt Google-Cast-Launcher-Element ein.
Und dann kannst du damit Videos an einen Chromecast schicken oder Audio.
Okay, und früher wäre das ein Diff mit einer ID gewesen?
Früher wäre das ein Diff mit einer ID gewesen, genau. Es wäre dann semantisch ähnlich schön, wie das jetzt das Ding ist, weil es ist ein Knopf, aber hat keinen Roll-Button und es ist auch nicht tastaturfokussierbar.
Das hat Google leider alles vergessen.
[50:11] Und das muss man dann selber noch nachrüsten. Okay. Okay, gut, aber das ist ja sozusagen ein Fail auf der Ebene der Implementierung und nicht so sehr, also, ein Failing von Custom Elements an sich.
[50:30] Joa, wahrscheinlich. Aber was würdest du denn vermuten, was der Grund ist, warum du noch nicht die Dinger verwendest?
Weil ich habe letztens Diskussionen gesehen, irgendwie so, da kam ein Artikel, machte die Runde von wegen, ja, irgendwie, so und so viel Prozent der Webseiten benutzen Custom Elements.
Ja, ich habe so ein Ding noch nie benutzt, bla Keks, und dann hat man sich darüber gezankt.
Wie ist es bei dir? Warum nicht? Genau, ich benutze es deswegen nicht, weil ich dieses Konzept von meiner ganzen Seite ist eben so lange tot, bis ein Riesenhaufen JavaScript das alles initialisiert, finde ich halt irgendwie doof.
Davon bin ich kein Anhänger. Ich möchte gerne im Prinzip so viel wie möglich Fertiges ausliefern über das HTML.
HTML. Und ähm.
[51:19] Das ist eigentlich der Grund. Ich könnte jetzt meine ganzen Komponenten, ich baue ja auch Komponenten, also vermutlich könnte ich die auch alle anstatt eben den Klassennamen so zu namespacen für das Projekt und dann den Komponentennamen dann folgend lassen, könnte ich das Ganze auch in Web Components oder in Custom Elements ausdrücken.
Genau, ich könnte natürlich auch, man muss ja auch das, was da drin ist, nicht unbedingt aus HTML rauslassen, also das würde ja auch gehen.
Aber ja, ich hätte halt Events wie vielleicht irgendwie sowas wie onMounted und onUnmounted und sowas, das regle ich aber im Grunde alles über Also ich nutze schon Teile der Web-Components-Dinge, aber eben weiß nicht, warum ich das jetzt quasi machen sollte.
Also ich denke, das hat ja, wenn du das jetzt so beschreibst, es soll ja möglichst ohne großartige JavaScript-Initialisierung, die nicht strikt nötig ist, daherkommen, hat ja wahrscheinlich auch dann was mit der Art von Projekt zu tun, der du arbeitest, weil du ja von einer Welt ausgehst, in der überhaupt jetzt so ein Server, der fertiges Markup ausliefert, eine nennenswerte Rolle spielt.
[52:43] Genau. Also, ich glaube, ich würde... Wahrscheinlich würde ich Web Components benutzen in einem Kontext, wo ich eine Komponentenbibliothek bauen müsste, die von relativ vielen Konsumenten genutzt wird.
Also verschiedenen, da würde ich glaube ich, also da würde ich dann den Weg einschlagen oder zumindest den erforschen, vielleicht ist es ja auch trotz alledem dann nicht der richtige Weg, das weiß man nicht.
Aber wenn ich eben eine Komponentenbibliothek habe, die möglichst wiederverwendbar sein soll, dann finde ich eben diese Ansätze, hey, dann schreibe ich eben ein HTML und CSS und JavaScript dafür und dann muss jedes Mal irgendwer hingehen und das portieren, nach React, nach Angular, nach was weiß ich was, oder vielleicht auch serverseitig in eine serverseitige Sprache.
Das finde ich dann irgendwie nicht so attraktiv.
Bedenke, was du dafür tun müsstest. Stell dir vor, du würdest tatsächlich das Selectlist-Element jetzt als UI-Komponente, die man sich dann npm install add-shap-selectlist installieren könnte.
Stell dir vor, du wolltest das bauen.
Du müsstest ja auf diesem Ding, und wir reden jetzt ja von einem Element, ja im Prinzip eine komplette Formularelement-API nachbauen.
[54:08] Du kannst ja nicht einfach eine API exposen, du müsstest sie ja nachbauen.
Du musst da mit den Internals hingehen, deinen internen State managen.
Vom Fokus-Management reden wir noch nicht mal, das kriegt man, glaube ich, noch am ehesten hin, aber du musst halt die komplette API exposen von einem Select- oder einem Select-ähnlichem Objekt und das dann da irgendwie durchleiten.
Das ist immer so bei Komponenten-Library, wo ich mir so denke, ja, okay, wenn du die mit React baust, dann funktioniert die nur in React, aber dafür bist du halt auch in endlicher Zeit fertig.
[54:37] Ja, also das wäre halt so ein Fall, wo ich jetzt nicht ausschließen möchte, ausschließen möchte, dass ich dann irgendwie sage, so nee, dafür nicht.
Oder vielleicht wäre die Lösung in dem Fall dann, dass die Inputs nicht einzeln wären, sondern ich ein Custom-Formular-Gerät hätte, dass ich dann konfiguriere, dass es unter anderem so einen stylbaren Select hat oder sowas.
Also was bei mir nämlich letztens mal so aufgefallen ist, was den Web-Components wirklich fehlt und was für viele Use-Cases echt nützlich wäre, ist nämlich was, also beim Select-List-Element könnte ich es halt noch irgendwie so nachvollziehen, dass man sich die Aufgabe macht, weil dann kriegt man wirklich ein neues nützliches Widget hin und das leistet dann etwas, was vorher nicht ging und das funktioniert überall und das ist irgendwie ziemlich gut, aber viele Komponenten in echten Projekten sind ja auch so Dinge wie, ich brauche ein Select und das ist irgendwie ein bisschen vorkonfiguriert, da gibt es halt nur die drei Options drin und das hat immer diese CSS-Klasse, damit diejenigen, die es nachher irgendwo rein droppen, nicht eben den Inhalt managen müssen und die Klasse managen müssen und sowas alles. Und das ist so ein Use Case, den können die Web Components gar nicht.
[55:46] Ja. Weil die Möglichkeit, der einzige Weg, internes DOM auszudrücken, ist Shadow DOM.
Das ist per Definition isoliert.
Und es gibt halt nicht ein Feature, für das ich jetzt votieren würde, dass man irgendwie eine Art Membranmechanismus braucht, um zu sagen, dieses Custom-Element-Ding da expost die API von diesem Ding im Shadow DOM.
Mhm. Dass gewisse Sachen wie Attive Endless-Nodes vielleicht einfach durchgetunnelt werden.
Und mit offenem Shadow DOM, es gibt ja Close und Open, wäre das eine Möglichkeit, auch wenn man dann vielleicht den Schutz vor Style-Leaking verliert?
Nee, der Schutz vor Style-Leaking ist dann ja gegeben. Open heißt ja bloß, dass auf dem Element die Property Shadow-Root von außen accessible ist.
[56:33] Ah, okay. Das würde halt eben nicht helfen, weil dann könnte zwar jemand von außen im Prinzip durch die Shadow-Root-Elementgrenze durchgreifen und sagen, im Shadow-Root mache ich einen Query-Selector auf das Select-Element und hänge da ein Event-Listener drauf.
Aber dann muss ja sozusagen die Benutzerseite, die diesen Schritt macht, aware sein, dass das Ding Shadow-DOM als Implementierungsdetail hat.
Und das wollen wir ja nicht. Wir wollen ja sagen, hey, verwende hier Project-Select.
Das hat alles vorkonfiguriert, du musst darüber nicht nachdenken, das ist ein Select-Element.
Aber es kann keins sein.
Und wenn es keins ist und man es aussehen lassen möchte, wie eins, gibt's dafür keinen Mechanismus, keine Membran oder sowas?
Ja, ich glaube, Formularelemente sind ja ein großes Dauerthema, so was mit Webcomponents echt schwierig ist und generell auch so Beziehungen ausdrücken, wie zum Beispiel Label to Input oder gibt ja auch andere Dinge, die man sozusagen per Beziehung ausdrücken kann.
Und wenn eben diese Beziehung über die Grenzen gehen müsste, über die Custom-Element-Grenze, dann klappt das ja schon wieder nicht mehr.
Ach doch, schon.
Kannst auch in die Klasse einen Static-Block reinbauen.
Dann kannst du da ja sozusagen anders initialisieren, der Klasse irgendwelche Nebenwirkungen hängen.
[57:59] Also, du willst irgendwie jetzt die Kommunikation haben zwischen einem Label und irgendwie einem Ding mit einer ID, also so per Vorattribut oder sowas. Genau. Da kannst du ja theoretisch einfach so im Prinzip eine JavaScript-Umgehungsstraße aufmachen.
Also, die Klasse wird initialisiert entweder von dem Target oder von dem, das das anzielt.
Und das macht dann einfach so einen JavaScript-Nebenstraße auf, in dem das halt irgendwie einen globalen Event-Bus initialisiert.
Und dann pingpongen die darüber ihre Kommunikation und keiner kriegt das mit.
Genau, aber so aus Accessibility-Gründen, also das würde das ja nicht lösen, oder?
Das kannst du doch mit irgendwelchen Internals, wo du Area-Fork konfigurierst, möglicherweise hinkriegen.
Mh.
[58:43] Du könntest ein ARIA-Label dann draufsetzen, das den gleichen Inhalt trägt wie eben das, was das Label, das eben außerhalb liegt, selber auch hat.
Genau. Dein Custom-For-Attribut ist sozusagen eine Fassade für einerseits die ARIA-Mechanik, die unten drunter liegt, und deine JavaScript-Umgehungsstraße, um die tatsächliche Interaktion mit dem Fokussieren und Gedöns möglich zu machen, andererseits.
Da geht halt eben schon alles nicht trivial.
Nee.
Deswegen also wahrscheinlich, also mein Weg wäre wahrscheinlich einfach nur ein Custom-Form-Element zu haben und das eben zu konfigurieren mit den Inputs, die es haben soll, sodass das alles dann zusammen in dem einen Ding lebt.
Okay, das heißt so, dass der Baustein, mit dem dann deine Mitarbeiter arbeiten, ist nicht das Select-Element, also irgendwie, das ist ja meistens, kommt das ja in Form von so einer Row da, dass man irgendwie sagen kann, es gibt ein Label, dann diesen Input-Typ, und das packe ich in so ein Ding rein, dann wird es formatiert und alles ist gut.
Sondern dein Abstraktionslevel wäre das Formelement?
[59:50] Wahrscheinlich. Oh, ein Hot Take. Bin ich aber mal gespannt, ob da nicht dann irgendwie so die Vielzahl der Änderungen am Formular dann...
Ja, also, aber vielleicht, also ich meine...
Ich glaube, unter unseren Hörerinnen und Hörern sind bestimmt einige, die...
Die mit Web Components arbeiten oder gearbeitet haben oder sich die Zähne ausgebissen haben oder Lösungen für diese Dinge gefunden haben, erzählt uns doch mal, wie ihr das in der Praxis dann macht.
Oder ob Web Components für euch eigentlich auch eher ähm, ja, nix sind.
Spannender fände ich, was fehlt.
Oder was wollt ihr erwarten und woran scheitert ihr? Weil das sind ja genau die Dinge, die in dem Survey da am Ende rauskommen sollten.
Das und das und das fehlt, weil...
[1:00:41] Man ist halt immer Kind seiner Zeit, Kind von dem Gedankengebäude, in dem man da unterwegs ist, und unter der Prämisse wurden auch Web Components entwickelt, dass man so Sachen wie Style Scoping überhaupt haben will.
Das ist ja sowieso auch schon mal eine Annahme, wo ich jetzt irgendwie sagen möchte, ist das so?
Weil ich meine, irgendwie muss man ja auch das CSS in seine Komponente dann reinkriegen.
Und vielleicht will man ja irgendwie so gewisse Basics, die jetzt über Dinge, die mit CSS-Variablen konfigurierbar sind, hinausgehen, irgendwo einheitlich haben.
Da Link-Tags reinbauen, die hast du alle reinrümpeln, aber dann ist ja mein Shadow DOM total aufgeblasen.
Weiß Gott, was das für die Performance macht. Keine Ahnung, Shape, das musst du mir sagen.
Oder man baut sich halt irgendwie ein Build-Tool, dass dann halt das CSS da einfach reininlined, was sehr, sehr bequem ist, aber garantiert auch nicht gut ist, weil dann ist ja jede Komponente ausgestattet mit irgendwie einem erheblichen Batzen CSS.
Kann man das irgendwie filtern? Ja, okay, ist aufwendig.
Also mich interessiert mehr so, wo scheitert es überall noch und wie kriegt man das irgendwie hin?
Und diese Membran-Idee, die ich da jetzt gerade vorhin ausgebreitet habe, ist nur die jüngste, auf die ich gekommen bin, was man da eigentlich haben müsste, um halt einfach so dieses, diese Leichtigkeit von, ich baue mal eben eine React-Komponente raus, worüber man ja da gar nicht nachdenkt, weil es halt so einfach ist, weil es nur ein Vorkonfigurieren von HTML ist.
Das muss man ja auch irgendwie mit irgendwas abbilden. Und mit einer Klasse, wo ich irgendwie 1000 Properties definieren muss, macht man das definitiv nicht.
[1:02:05] Ja, das, da gebe ich dir recht. Und wenn wir jetzt nicht mal ein Select-Element, wir zwei hier, Shep und ich, hinkriegen in der Kürze der Zeit, dann würde ich halt auch an so Sachen wie so Select-List ein großes Fragezeichen hängen, an das Tab-Interface ein großes Fragezeichen hängen, weil das alles so irre kompliziert ist, dann auch noch so hinzukriegen, dass es wirklich für alle nützlich ist.
Ich kriege ja nicht mal ein Select-Element hin, das für mich nützlich ist per Web-Component.
Ja, wir gucken mal, wie sich das weiterentwickelt. Ich weiß gar nicht, das Select-Menü, Select-List, haben wir da gesagt, es ist nur, du hast gesagt, Chrome wäre das nur, oder? Richtig?
Ich hatte, glaube ich, bei MDN gesehen, dass das in Chrome ist.
Moment, Select-List. Ja, ich finde, das ist ja immer so ein Indikator, wie kompliziert Dinge sind.
Also du hast ja gesagt, die Popover API, die gäbe es ja auch in Safari, im Technology Preview und in Firefox hinter Flags, das ist ja dann so ein bisschen so ein Indikator dafür, dass es keine großen Probleme irgendwie konzeptioneller Natur gibt.
[1:03:18] Ja, einerseits das, andererseits kann ich mir einfach vorstellen, dass hier gerade bei Popover, wo du ja auch gesagt hast, da gibt es ja die sozusagen CSS-Features, die das Backend darstellen, die gibt es ja konzeptionell auch schon, dass sozusagen das Umwandeln des Ganzen in ein HTML-User-Interface jetzt nicht so der große Sprung ist.
Dass man irgendwie sagt, ja, okay, wir machen hier irgendwie Constraints drauf und mit dem CSS-Mechanismus, den wir schon ausspezifiziert haben, wo wir schon über die ganzen Interaktionen und Probleme und Stacking-Kontexte und so weiter nachgedacht haben, Das nehmen wir einfach und adaptieren das und bauen dann ein bisschen HTML-UI drumherum.
Das ist, glaube ich, eine andere Geschichte, als zu sagen, wir definieren jetzt das Select-Element neu und zwar so, dass es für alle funktioniert.
Das halte ich für die wesentlich größere Geschichte und ich suche jetzt ja noch irgendwie, weil ich meine, wenn Sie das bei Chrome implementieren, haben Sie ja normalerweise auch irgendwen, der das in so eine Art Spezifikationstext gießt.
Aber den finde ich hier gerade nirgendwo.
[1:04:21] Äh, customizable Select Element, Blau Keks, ja, ich finde halt das Spezifikationsdokument nicht.
Weil? Irgendwie so der Explainer da von Open UI, der liest sich gut.
Das ist ein super MDN-Artikel.
Wie funktioniert das wirklich? Ja, was kann ich da an interaktiven Elemente in diese interaktiven Elemente reinbauen, damit es schwierig wird? Kann ich in das Kann ich in das Option-Äquivalent da einen Link reinbauen?
Kann ich in das Option-Element da ein Formular-Äquivalent reinbauen?
Und was machst du, wenn ich Select-Lists in Select-Lists habe?
[1:04:51] Das hätte ich halt gerne mal irgendwo ausspezifiziert, bevor ich da jetzt irgendwie sage, das ist irgendwie easy.
Spontan hört sich das für mich sehr, sehr kompliziert an.
Also angeblich ist es ja ein Editor's Draft zumindest. Puh.
Aber wie das jetzt, wo der sein soll, wo der sein soll, oder ob das wirklich nur dieser Explainer ist.
Äh, genau, auf GitHub haben sie was.
Damm-di-damm.
[1:05:25] Naja. Nicht, dass das so wichtig ... Naja, find ich schon, weil im Moment find ich halt bloß so Dinge so, das wollen wir erreichen. Ja, super.
Aber ich würde auch gern zum Mars fliegen.
Wie machen wir das jetzt konkret?
Und solange ich da nicht irgendwie die Spezifikation oder die Rakete sehe, bin ich da erst mal so im Zweiflercamp.
Ja, zu Recht. Hast du denn hier auf der ersten Seite noch was, was dir ins Auge sticht?
Hier, ich seh noch Input und dann die Showpicker-Methode drauf.
Hab ich noch nie verwendet.
Macht Sinn, ist wahrscheinlich auch sinnvoll, wenn man eben einen Input customizet und vielleicht irgendwie den eigentlichen Button, der ein Color Picker oder so öffnet, versteckt, um ihn dann eben alternativ öffnen zu können, sowas oder Datepicker.
Ja, solche Geschichten habe ich jetzt auch noch nicht verwendet. Was haben wir da?
Cutting-Edge-Chip, but not in all browsers. Also gibt es auch noch nicht überall. Anscheinend.
[1:06:31] Genau, dann gibt es hier noch das Portal-Element. Das gibt es ja auch schon relativ lange.
Seit 2020 oder so.
Ich glaube, das wurde mal schnell zusammengetackert für irgendein Google I.O. oder so was.
Und man was zu erzählen hat.
Manchmal merkt man das ja, dass die ganz schnell noch Dinge erfinden, um die dann so ein bisschen so ein Show-off machen zu können.
Ich glaub, Portal war auch so was. Ich würd vor allen Dingen noch mal, Chef, du hast ja gerade gesagt, das gibt's schon sehr lange.
Noch mal mit dir jetzt den ganz großen philosophischen Wurf wagen.
Das Konzept oder die Idee.
Aha, was wir unter Existenz verstehen. Also, weil das ist wieder so ein, man müsste mal zu Mars fliegen.
[1:07:15] Okay, wie machen wir das? Habt ihr eine Rakete, einen Getreibstoff, irgendwas?
Ach, habt ihr nicht. Okay, schwierig.
Genau, ein Portal ist ja eigentlich so vielleicht so der ...
Das, was man damals versucht hat, was aber auch heutzutage die View-Transition-API übernimmt.
Das heißt, man kann in einem Iframe die nächste Seite laden.
Oder in einem Portal in dem Fall. Das ist im Prinzip wie ein Iframe.
Dann kann man dieses Portal sozusagen zur Hauptseite promoten.
Genau.
Und das kann man eben animieren. Die View-Transitions, da den überwiegenden Teil von ganz gut abfrühstücken.
Genau, aber ich glaube, damit dürfte das Thema auch durch sein mit den Portals.
Ja, ich hoffe, weil das hört sich auch alles sehr nach einer Aufgabe an, die in CSS oder JavaScript oder irgendwas anderem als HTML EML echt besser aufgehoben ist, als...
[1:08:14] HTML, weil das ist ja nicht irgendwie Markup, also bin jetzt ja nicht wirklich der Purist, der da noch von ernsthaft von Dokumenten und Zeug spricht, aber trotzdem.
Das ist ja schon arg interaktionsrelated.
Ja, das bringt mich aber auf ein anderes Attribut, das hier irgendwo auch vorkommt.
Wahrscheinlich nicht so hoch gewotet und zwar das Render Attribut, dass man auf, ich glaube, theoretisch auf beliebige Elemente setzen kann Und, ähm, genau, der Ursprung dieses Attributs kommt von den View-Transitions.
Und, äh, genau, also, man kann das dann auf Blocking setzen.
[1:08:55] Das heißt also, dass der Browser eben erst anfängt zu rendern, wenn er dieses Element geladen hat.
Das könnte also vielleicht ein Bild sein oder irgendwas anderes.
Oder, ja, bei Skripten ist es ja, wenn die nicht async oder deferred sind, sind die ja auch Render-Blocking.
Wobei es könnte ein Skript sein, das weiter unten ist, oder es könnte ein Skript sein, das man trotzdem asynchron oder deferred laden möchte, das aber Blocking sein soll, weil nämlich, also wichtig ist das für die View-Transitions, dass eben die Dinge da sind, zwischen denen dann auch gemorpht werden soll später.
Und das kann man eben sicherstellen, zum Beispiel bei einem Bild, man da sagt, äh, Render Blocking, und dann würde eine View Transition auch erst, äh, anfangen zu transitionieren, wenn eben diese ganzen Render Blocking markierten Sachen dann auch da sind. Mh.
[1:09:59] Also eigentlich eher was, was man nicht haben möchte, und vielleicht so einer der großen Nachteile von View Transitions, obwohl die an sich ja schon ziemlich cool sind, aber das wäre dann wiederum was, wo das so ein bisschen, gegen die Natur von Rendering läuft.
Ja, beziehungsweise, das ist ja, was du gerade ja erklärt hast, ist ja mehr oder minder einfach nur ein standardisierter Workaround eigentlich.
Mhm.
[1:10:37] Genau. Ansonsten, View Transitions, hast du mit denen schon rumhantiert bestimmt, oder?
Habe ich tatsächlich noch nicht ernsthaft mit rumhantiert, weil das in zu wenig, das bisher zu wenig Verbreitung hatte, um bisher von mir in meine Pipeline von forsche und setze das um in irgendwas produktmäßiges, das ist da noch nicht reingefallen, aber das steht tatsächlich für die nächsten zwei Monate auf meinem Zettel, dass ich mir die mal genauer anschaue.
Ja, da bin ich mal gespannt, was du zu denen sagst. Also an sich sind die ja cool und man kann ja auch so Sachen damit machen, die bisher traditionell immer schwierig zu machen waren. Du kannst ja theoretisch auch eine View-Transition innerhalb der Seite selbst durchführen.
Also du musst dafür ja nicht eine neue Seite laden, und man kann damit auch sowas machen, wie ich mach den ersten Snapshot der Seite, wenn die Liste zehn Elemente hat, und jemand drückt auf den Löschen-Knopf von einem dieser Elemente.
[1:11:38] Und dann, wenn im Anschluss wird das Element eben gelöscht, und dann aktiviert sich die Transition, und dann hast du eben das, also, dann rutscht die Liste eben weich zusammen, und das Element wird nicht einfach so quasi weggenommen, und sofort ist die Liste eben kürzer.
So, das sieht ja immer ein bisschen doof aus.
Das könnte dann weich eben zusammenfahren.
Ja, und könnte halt diverse, sonst relativ aufwendige JavaScript-CSS-Transformations-Fummeleien, die man da anstelle dessen macht, ersetzen.
Ja, oder auch so, wenn du vielleicht Suchergebnisse in Kachelform hast, und jemand ändert die Order, wonach das sortiert werden soll, dann könntest du quasi auch mit einer View-Transition dafür sorgen, eben die ganzen Kacheln dann weich an ihre neue Position fliegen.
So Sachen sind halt auch möglich. Genau, der Browser weiß halt, es wird eine View-Transition und muss nicht irgendwie aus meinem Konvolut aus CSS und JavaScript erraten, welchen Optimierungspfad er jetzt beschreiten soll, sondern er weiß, was kommt.
[1:12:47] Ja. Und der, die einst, aber der Use-Case, der mich die hat wieder abschalten lassen, ist eigentlich, also in dem aktuellen Projekt, Zum einen führt das tatsächlich schon zu so leichten Verzögerungen in der Interaktion, weil dieses Screenshot-Machen dann doch ein bisschen Zeitaufwendig ist.
Und das andere ist, dass es dann ein bisschen haarig wird, wenn du verschiedene Elemente hast, die vielleicht gleichzeitig sich ändern und die gleichzeitig weiche Animationen gebrauchen könnten, könnten, aber die nicht miteinander abgestimmt sind. Und du quasi nebeneinander zwei View-Transitions startest, die aber immer global für das ganze Dokument nur funktionieren. Also du kannst quasi quasi nicht sagen, die View-Transition...
[1:13:43] Soll oder das morphing soll sich quasi beschränken auf dieses quadrat in dem meine diese eine komponente a ist und dann könnte die komponente b ein ebensolches, morphing für ihr ihren quadranten starten sondern das geht halt immer nur für die gesamte seite, und da ist halt dann blöd in der regel ist ja immer eine die die irgendwie zuerst triggert und die nächste die dann triggert bringt halt alles irgendwie durcheinander.
Und das hab ich halt hier so öfters mal, vor allem, wenn du eben wirklich so komponentenbasiert arbeitest und kein zentrales Orchestrierungstool hast.
Mhm. Und selbst dann funktioniert's halt nicht, weil du könntest ja auch so was machen wie, hey, ich debounce das und warte ab, ob noch irgendwelche Kommandos von irgendeiner anderen Stelle kommen, und erst dann start ich die View Transition.
Ja, oder ich mach irgendwie drei Klicks und es laufen drei Requests los, wiederkommen und dann soll das drei Transitions geben?
[1:14:41] Genau. Aber das funktioniert halt nicht. Weil selbst wenn du das debounced, dann kannst du die ersten zwei Requests zusammenfassen, aber du weißt nicht, dass dann ja noch ein dritter kommt, der aber zu langsam war, um quasi noch eben in diesem Debounce-Zeitraum, den du dir ausgewählt hast, rechtzeitig zu kommen.
Und dann macht der das halt alles kaputt.
[1:15:05] Mhm. Ja.
Gut, ähm, ich überleg jetzt grad, also wie gesagt, ich hab das jetzt selber noch nicht angefasst.
Und tatsächlich war mein mentales Modell noch gar nicht bei dem angekommen, was du jetzt gesagt hast mit diesen ganzen Einzelkomponenten, dass man das machen könnte schon.
In meinem Gehirn war View Transition bisher tatsächlich primär Transition von View as in, ich hab hier eine Multi-Page-Applikation, und klicke jetzt auf den nächsten Link.
Ich glaube, da ist das immer noch am besten aufgehoben. Und das mache ich eben nicht.
Und diese Multi-Page-Application-Transitions gibt es ja noch nicht, die kommen ja noch.
Das heißt, da kann ich sie nicht nutzen in meinen Multi-Page-Projekten.
Aber ich fand es eigentlich schon cool, auch irgendwie nur innerhalb der Seite für interaktive Elemente.
Und da funktioniert es eigentlich gut, eben bis zu dem Moment, wo mehrere gleichzeitig vor sich hin arbeiten, dann fällt das Kartenhaus in sich zusammen und dann müsste man die in iFrames irgendwie sperren oder was weiß ich was machen.
Ja.
Siehst du denn grundsätzlich eine Möglichkeit, die API so weiterzuentwickeln, dass das irgendwann mal diesen Use-Case vernünftig abdeckt?
[1:16:20] Weil, wie gesagt, ich hab damit jetzt noch nicht viel gearbeitet, aber für mich klingt das jetzt mehr so nach, das ist aber ein ziemlich fundamentales Problem.
Mhm.
Also, vermag ich nichts zu beantworten. Also, irgendwie gefühlt, denke ich, könnte das schon gehen.
Aber wahrscheinlich, also so, wie ich diese Entdeckung ja auch erst gemacht habe, nachdem ich die View-Transitions eingebaut habe, wird man dann wahrscheinlich wieder auf neue Probleme stoßen.
Denke ich. So wie das halt häufig so ist. Joa. Joa, wird sich zeigen, wird sich zeigen.
Aber das heißt...
[1:17:00] Mhm, okay. Ja, nee. Gibt Sinn. Ich werd das ausprobieren müssen und damit mal spielen müssen.
Mittlerweile ist es ja weit genug in der Realität angekommen, dass man zumindest sagen kann, das geht erst mal nicht weg und bleibt da und, ähm, ja, wird sich zeigen.
Immer noch nicht in Firefox, auch noch nicht ansatzweise, mh.
Ja, ach, das machen die Leute von Igalia dann irgendwann. Äh, meinst du?
Die kommen doch immer an und implementieren Dinge in, äh, in Engines, wo das Personal einfach nicht mehr die Kapazität hat.
[1:17:35] Was die implementieren sollten, wäre irgendwie so ein Cool im Mozilla-Hauptquartier. Mhm.
Dass man da mal die ganzen Hosts rausschmeißt und da irgendwie Leute installiert, die einen vernünftigen Browser bauen.
Ach, ist ja nix.
Doch, super. Also, ich bin ja seitdem Chrome da seinen letzten DRM-Trip gestartet hat, hab ich gesagt, so fick die Scheiße.
Ich bin auf Mobile-E mit dem Firefox unterwegs Desktop etabliert und das geht voll gut, da sind echt so, also das Beste, was ich sagen kann, ist mir fällt ja halt nicht auf.
Also ich habe meinen Browser gewechselt und ich merke es halt nicht, wenn ich nicht gerade Zencaster aufmache.
Und ein paar Sachen wie so deren Multiline, JavaScript, Playground da drin in der Konsole, finde ich besser als das, was Chrome da hat.
Das ist total super, ist irre schnell, alle Extensions da, Blau Keks und immer mehr.
[1:18:21] Äh, ich weiß gar nicht, was ich sagen wollte. Du findest den gut.
Ich find den gut, der fällt mir nicht negativ auf.
Äh, und auch positiv jetzt nicht groß. Aber mein Desktop-Browser ist ja eh eine relativ unkomplizierte Sache.
Ich hab drei Extensions, und das war's.
Auf Mobile fällt er mir positiv auf. Aber trotzdem ist das ja so, dass immer, wenn man irgendwie da von Mozilla irgendwelche ...
Die machen halt regelmäßig ihre Stunts.
Und auch zum Beispiel Sachen wie dieses AI-Ding da in MDN, wo ich so denke ...
Nee, ich hab, also jetzt wo du's sagst, erinnere ich mich, dass da irgendwas war, aber ich hab das nicht verfolgt.
Ich hab keine Ahnung, was die da machen.
Ja, also man kann ja so was bauen, testweise.
Und man kann das ja irgendwie mal so sagen, hier, hast du versucht, ne?
Ist ja auch ein Beta-Batch dran, so schön Web 2.0 ist ja völlig gut.
Aber wir wissen ja, wie im Moment der Technik mit den Dingern ist.
Du musst nicht viel Arbeit da reinstecken, um die dazu zu bringen, dass sie Käse erzählen.
Und was machen die da? den du was fragen kannst, oder wie?
Ja, genau, synthetisches Stackoverflow ist das Gleichsam.
[1:19:21] Ah ja. Da fragst du halt den, und dann sagt er dir irgendwie so, ja, du kannst mit dem Intersection Observer natürlich die Notelist um drei Elemente kürzen, so geht's.
Mhm. Okay. Was halt so ein ganz klassischer Move ist, wo halt die richtige Antwort wäre, die Frage ist falsch, aber das ist halt nicht das, was die AI der Technik heutzutage beantworten kann.
Ist ja okay, muss man ja ausprobieren, um festzustellen, dass es nicht funktioniert.
Aber wenn dann halt wirklich Leute bei GitHub, kannst du ja bei MDN machen, sagen, hier, Bug Report, ich hab diese Frage gestellt, da kam Blödsinn raus, hallo, hier, mach mal was.
Und dann die, sagen wir mal, ähm, Pro-Fraktion von diesem Feature, dass da sozusagen ...
Dass da erhebliche Ressourcen reinverschwenden, um zu rechtfertigen, dass es ja zwingend nötig ist, dass da KI in MDN mit eingebaut wird.
Mhm.
[1:20:13] Wo ich irgendwie so sagen würde, Leadership bei einer Firma, die ja schon so einen technischen Anstrich hat und wo so Produkte wie Webbrowser, oder von mir aus auch sowas wie Pocket und Konsorten ja schon irgendwie echt so Nerd-Unternehmungen sind, die sollten doch in der Lage zu erkennen, dass so ein Experiment da nicht hinhaut und dann auch relativ schnell den Stecker ziehen, aber der ist immer noch da.
Ja, wobei ich glaube, ist MDN denn überhaupt noch Mutze da? Oder ist das nicht eher jetzt so ein von allen betriebenes Dings mittlerweile?
Habt ihr mir dann alle MDN-Mitarbeiter bis auf einen ...
Ja, gekündigt bei Mozilla und dann ... Warte mal, dann ist ja vielleicht das das, worüber ich mich aufregen sollte.
Ja, dann solltest du dich darüber aufregen.
Ja, ja, nee, das war schon schade.
Redirekten wir das dann. Ja, ist nicht schade, ist halt irgendwie so ...
Ich meine, okay, ich hab ja den Browser nicht ohne Grund gewechselt, weil immerhin wollen sie mir jetzt hier mit Mozilla-Stand jetzt nicht irgendwie DRM für Webseiten reinwirken.
Trotzdem ist laut Mission Statement Mozilla schon an einen höheren Standard zu binden, als jetzt eine ganz normale Firma, wie Microsoft, wie Google.
Da darf man mehr erwarten. Und wenn dann zwar objektiv mehr geliefert wird, als von der Konkurrenz, aber die an ihrem eigenen Anspruch scheitern, dann müssen wir trotzdem auf den Deckel kriegen.
Zu Recht. Deswegen benutze ich den Browser und schimpfe, aber ich meine es gut.
Ja.
[1:21:37] Ja, dann. Wir haben jetzt schon über eine Stunde aufgenommen. und du hast Termine.
Die Frage an dich wäre, hast du Lust, noch mal ein Part 2 zu machen, wo wir uns noch die verbleibenden Sachen angucken?
Weil wir sind jetzt ...
Also, so ein paar seh ich noch, die ganz nett wären. Mhm.
Also, nicht im Sinne von ... hier, wie du immer nett definierst, sondern ...
Besprechenswert. Genau. Nee, das machen wir auf jeden Fall. Wir machen auf jeden Fall einen Teil zwei, weil ich hab hier schon mal sehr viel mitgenommen. Die werden endlos lang und werden viele, viele Links enthalten.
Cool. Ja, dann machen wir das. Ich freu mich drauf. Und, äh, genau, wir bedanken uns fürs Zuhören.
Hoffen, dass der Teil zwei nicht allzu lang auf sich warten lässt.
Und ich bedanke mich auch bei dir für den tollen Austausch.
Ich bedanke mich bei dir. Ich hab wieder viel mitgenommen. Dann bis zum nächsten Mal. Macht's gut. Tschüß!
[1:22:34] Music.