Revision 587: Event Handling und Shadow DOM

Transcript

[0:00] Diese Weakmaps, wie die eigentlich arbeiten, ist ja, dass quasi in dem Objekt, glaub ich, ein Hidden-Attribut eingehängt wird, richtig?
Dass quasi mit dem Objekt dann auch gelöscht wird? Nee, nee, das ist tatsächlich einfach egal, ob das eine Weakmap ist oder ein Array oder so was.
Aber Idee ist halt, du hast ein Custom Element im Constructor, machst du außerdem noch irgendwie Datenstruktur.addThis.
Hör mal, du arbeitest doch an einer Webanwendung für den Geheimdienst, die so sicher sein muss, wie's nur geht.
Äh, nee, tatsächlich nicht.
Nee, woran ich arbeite, sind immer noch meine Web-Component-Decorators.
Ich weiß nicht, ob du gestern meinen Mastodon-Post des Tages gesehen hast.
Äh, hab ich gesehen. Ich glaub, ich hab nicht viel geschnallt.
Wie das häufig so ist.
Diese Revision von Working Draft wird euch präsentiert von Midwild.
Next-Level-Hosting für deine Projekte.
Ihr fragt euch bestimmt, wie kann so was Langweiliges wie Hosting Next Level sein?
Ganz einfach, Midwalds hochperformantes Cloud-Hosting ist perfekt abgestimmt auf die Anforderungen von Freelancern und Agenturen.
Es gibt 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.

[1:22] 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. Egal, ob mit Curl oder mit so einem grafischen Browser, es schreibt sich auf jeden Fall mittwald.de.
Und alle Infos zu Midwald findet ihr natürlich auch noch mal in den Show Notes zu dieser Revision.
Wir danken Midwald für die Unterstützung Revision von Working Drive. Revision 587.

[2:02] Music.

Revision 587: Event Handling und Shadow DOM

https://workingdraft.de/587/

[2:28] Sag mal, du machst Event Delegation immer mit Capturing, das habe ich richtig in Erinnerung.
Ja, genau. Okay. Einfach weil du halt alle Events damit dann bekommst. Es macht ja dann so gesehen eigentlich auch nicht wenig Sinn. Ja man kann ja nicht alles.

[2:45] Per bubbling abfrühstücken. Ja, ja, ja. Gut, gut. Dann muss ich mal an so ein Ding, das ich hier habe, noch was anbauen, damit man das machen kann.
Ja, und manchmal ist das Capturing ja auch ganz gut, wenn man sich vor ein Event, was wer anderes dran geklatscht hat, quasi nachträglich mit seinem Code dranhängen möchte.
Weil dadurch, dass die Capturing-Faser zuerst ist, normalerweise werden ja Event-Händler in der Reihenfolge abgearbeitet, wie sie angeheftet werden.
Aber so kannst du dich quasi dann noch mal davor einhängen.
Also und quasi das abfangen und dann auch vielleicht, wenn du möchtest, ein Stop Immediate Propagation werfen. Und dann hast du den anderen quasi, der schon da war, den du aber nicht kontrollieren kannst, aus dem Verkehr gezogen.
Das heißt, du würdest dich dann sozusagen am anderen Ende der Schlange wieder anstellen?
Statt an dem, wo du dich normalerweise anstellst. Im Grunde gibt's ja dann zwei Schlangen. Ja, stimmt.
Es gibt die Bubbling- und die Capturing-Schlange. Die Capturing wird immer zuerst gefragt, was sie bestellen möchten, und danach die Bubbling.
Aber in der gleichen Reihenfolge werden die Schlangen abgearbeitet?
Ja.
Genau, nur die Element-Reihenfolge ist dann ja natürlich ... Mhm.
Genau, aber vom Handling her, was Event-Tage und so angeht, ist mir da im Grunde eigentlich nix aufgefallen, was da unterschiedlich wäre.

[4:13] Wollte ich gerade noch was fragen, hab ich vergessen. Passive Events?
Ne, das wollte ich nicht fragen, aber eine weitere gute...
Also ich hab was gebaut, das macht Event-Handling im weitesten Sinne.
Und da hab ich noch nicht was dran geflanscht, womit man sagen kann, also womit man im Prinzip, den Listener angeben kann.
Nicht den Listener die Optionen angeben kann.
Und wenn das die Möglichkeit gibt, dann kannst du dir ja aussuchen, ob Capturing und Passive und was nicht alles.
Ja. Also, ich hab ja so eine ... Ich hab ja so eine quasi ...
Mir so eine Event-Delegation-Library gebaut.
Und die arbeitet so, dass die quasi dann ... Also, du sagst, die macht immer Capturing, weil es spricht eigentlich nichts dagegen.
Mhm.
Und, ähm, dann guck ich halt, was ist das für ein Event.

[5:00] Also, was sie auch macht, ist halt so ein bisschen syntaktischen Zucker, dass du quasi ...
Dass halt du mehrere Events auch so space-separiert übergeben kannst, so wie das bei Jackquery war.
Das war ja alles schlecht bei Jackquery, genau. Nee, nee, auf jeden Fall.
Ähm, genau. Und dann guck ich halt, was sind das für Events, und dann setz ich die Optionen auch automatisch zum Beispiel auf Passiv.
Also, weil dann ... Also, wenn das jetzt irgendwie ...
Ich glaub, Touchmove und Touchend sind ja solche Events. Und Scroll, glaub ich, auch. Ich bin mir nicht sicher.
Mhm. Ähm, also vier Stück, glaub ich, sind's. Genau das mach ich.
Und wenn es so Events sind wie Resize oder Scroll, dann hab ich quasi so ein automatisches Debouncing drin, was die nicht öffnet. Also, das debounst dann quasi auf einmal pro gezeichneten Frame.
Ach, automatisch.

[5:51] Beziehungsweise nicht debouncen, sondern im Grunde throttling, ja.
Na ja, beziehungsweise Synchronisierung mit der Framerate.
Genau, weil du willst ja nicht ... Im Grunde willst du ja nicht ...
Also, es bringt dir ja gar nix, das öfters zu feuern. Also, ich wüsste jetzt keinen ...

[6:07] Also, es gibt wahrscheinlich einen Use-Case, aber ich müsste wirklich sehr lange, sehr, sehr lange, wochenlang nachdenken, um diesen Use-Case zu finden.
Und in der Regel willst du ja irgendwas quasi synchron auf dem Bildschirm verändern mit deiner ... deinem Scroll oder deinem, weiß ich nicht, Resize oder vielleicht ein Mouse Move auch.
Da du das eh nur einmal jedes Frame dem Benutzer oder der Benutzerin zeigen kannst, ist es eigentlich okay, das so zu throtteln.
Und das machst du jetzt sozusagen für diese jeweiligen Events, die du jetzt angesprochen hast? Oder ist das so eine allgemeine Faustregel, das passiert immer?
Nee, nee, das mach ich dann schon für diese Events. Also, es gibt ja bei anderen Events.

[6:56] Da kann ich mir vorstellen, das schon eher ein bisschen Backfire erzeugt.
Also, je nachdem, also, äh ...
Na ja, zumindest, wenn du die Reihenfolge durcheinanderbringst.
Die ist ja manchmal dann schon entscheidend, wenn du so aus mehreren Ecken irgendwelche Events auf Dinge drauflegst.
Mhm.
Genau, und im Grunde, dem Ganzen liegt halt immer dann zugrunde ein einziger Eventlistener, der Buch führt über die, äh ...
Die Elemente. Also, beziehungsweise im Grunde, du kannst halt übergeben Selektoren, wie bei J.Curry, also die, die jetzt benachrichtigt werden möchten.
Oder Elemente kannst du übergeben, also quasi so eine Art Parameter-Overload.
Oder du kannst sogar eine Funktion übergeben, falls das irgendwie wichtig ist. Mhm.
Verstehe. Mhm.
Aber der Punkt, den du angesprochen hast bezüglich, dass du dir aussagen kannst, in welche Schlange du dich stellst, um da irgendwie was zu Propagation zu machen, Das brauchst du ja tatsächlich mehr so Workaround-mäßig.
Das ist ja der kleine Google-Tag-Manager, würd ich sagen.
Ja, genau. Also, wenn du sozusagen nicht irgendwo reingrätschen musst, dann willst du immer Capturing machen.
Also ...

[8:16] Vielleicht willst du ja auch, weiß ich nicht, vielleicht willst du bewusst irgendwelche Dinge nicht bubbelnd mitbekommen.
Also, aber was sollte das sein?
Und bei Event-Delegation macht's sowieso Sinn, Capturing zu verwenden, weil sonst die Hälfte der Events irgendwie ja gar nicht gedelegated werden können.
Das ist tatsächlich ein ganz guter Hinweis.
Und warum das, glaube ich, nicht so viel benutzt wird, ist einfach, weil's halt ein extra Parameter ist Und ich glaub, dass einfach der oft links liegen gelassen wird.
Also der auch gar nicht so thematisiert wird. Und wahrscheinlich immer noch sozusagen, früher ging das nicht, weil erst IE9 konnte das.
Und IE8 und kleiner konnten es nicht. Ich weiß auch gar nicht, ob das erst später in den Standard gewandert ist oder so.
Aber so, deswegen ist das Capturing irgendwie, Wird das Stiefmesser mütterlich behandelt.

[9:28] Warte mal kurz. Ähm...
Diese Options, die man bei App-Event-Listener mitgibt, sind aber... Warte mal.

[9:42] Naja, früher war das ja quasi... Der dritte waren Boolean.
Dann wurde das ja geupgradet, weil ja sozusagen die API-Design-Guidelines des W3C, sich dahingehend geändert haben, dass sie eben sagen, Also quasi die erforderlichen Parameter bleiben weiterhin, äh, sozusagen einzelne Parameter.
Und alles, was sozusagen variabel ist, das wird dann in so einem Dictionary, also quasi in einem Options-Objekt, dann soll übergeben werden.
Und darum haben die dann später eben, als dann diese Passive-Event-Listener noch dazukamen und noch irgendwas, ich glaub noch was, ich hab vergessen, was das ist, ach ja, Once gibt's ja auch noch.
Und ein weiteres? äh, död, död, död, äh, keine Ahnung, weiß ich nicht.
Äh, Signal. Ein Abort-Signal, dass du triggern kannst, damit der Ding aufhört.
Ja. Ja, ja, okay. Nee, ich wollt grad nur nachschauen, weil speziell so die Unterscheidung zwischen Capturing und Bubbling ist ja eine sehr DOM-spezifische Sache.
Event-Target ist ja ein sehr allgemeines Interface.
Mhm. Und ich wollt nur grad mal nachgeschaut haben, ob das sozusagen ...
Ob das AddEventListener für DOM-Elemente speziell ist, Konzept gibt oder ob das im Event Target selber drin ist, aber das ist da selber drin.

[10:59] Plus der ganze Rest. Also ja, wenn ich da so ein Event Listener irgendwo anbringbar mache.
Muss ich da diese Options auch zugänglich machen, sonst wird der Chef unzufrieden.
Aber hallo, ja, ja, und so Sachen wie das Board Signals und Wants will man ja auch haben, das ist ja schon. Ja, korrekt.

[11:22] Was ja der Stefan Judis hatte letztens, also, ich glaub, diese Woche oder so was, ein schönes Blogpost, wie man irgendwie alle Event-Listener von einem Element runterbekommt.
Also, wenn man eben nicht selber Autor davon ist.
Äh ...
Das, find ich, ist ja auch noch so ein Dings, was fehlt. Also, in den APIs.
Also, was er halt macht, ist ...
Äh, dass er quasi die DOM-Node klont. Und dann verliert die diese ganzen Event-Listener.
Tute sie das? Ja, anscheinend schon.
Äh, warte mal.
Tödödödödödödödödöt.

[12:12] Aber doch. Ich glaub, es wird ja dann eine Kopie, also eine exakte Kopie davon erstellt, von dem DOM-Element.
Aber eben, es ist ein anderes. Und darum, also wahrscheinlich, also wenn du dann quasi ein Gleich-Gleich-Gleich machen würdest, würde da Falls rauskommen.
Äh ... Ja, klar. Nee, nee, das ist tatsächlich ... Ich hab letztens auch zu meinem Erstaunen rausgefunden, das wird nicht einfach nur geklont, sondern tatsächlich rekonstruiert.
Und das läuft dann, wenn du ein Custom Element hast, auch durch deinen Constructor durch und so Zeug.
Oh, okay. Ja. Ja gut, das macht ja aber auch Sinn, ne? Müsste ja eigentlich auch, weil du sonst ja quasi ...

[12:54] Die gleiche Instanz hättest von der Klasse. Ja, nicht notwendigerweise.
Du könntest ja möglicherweise tatsächlich sozusagen unter der Haube ähm, so einen Nullen-und-Einsen-Klon machen.
Also tatsächlich das Objekt eins zu eins reproduzieren. Abzüglich, wo befinde ich mich in meinen Parent-Nodes und so weiter.
Hätte ich jetzt auch nicht für unmöglich gehalten.
Ja, so warte mal, das heißt, wenn das aber stimmt, dann ist.
Also entweder stimmt das nicht, oder was anderes ist, was sie mich nicht, was mich überraschen würde, das probiere ich mal eben kurz aus, warte mal, ich habe jetzt mal ein Diff gebaut, Diff.inner.html gleich, warte mal.
Hallo so und dann mache ich das Punkt on Click, weil das gibt's ja auch noch die Möglichkeit.
Ja, das bleibt, das bleibt, das hat er auch geschrieben.
Okay. Weil das ja sozusagen ein Attribut von dem Element. Genau, ist ein ideal Attribut direkt auf dem Ding drauf und, Wohingegen dieses Eventgebimsel, das mit Eventlistener ja tatsächlich nur gefühlt, nicht wirklich, aber gefühlt ja irgendwie so ein angeflanschtes Ding in irgendwie so einer...

[14:20] Externen Speicherungsgeschichte ist. Also eine Map, die im Hintergrund läuft.
Wobei natürlich, wenn du Custom Elements hast, und die legen innerhalb ihres Constructors, Referenzen in irgendwelchen Weakmaps oder so an, und du klonst eine Node, dann, weil ja tatsächlich das Klonen ein neu aufstellendes Element ist, kriegst du auch eine zweite Referenz in dieser Map dann drin.
Also ... Ja, genau, weil die, glaub ich, diese Weakmaps, irgendwie so, wie die eigentlich arbeiten, dass quasi in dem Objekt, glaub ich, so ein Hidden-Attribut eingehängt wird, richtig?
Dass quasi mit dem Objekt dann auch gelöscht wird? Nee, nee, das ist tatsächlich einfach egal, ob das eine Weakmap ist oder ein Array oder so was.
Aber Idee ist halt, hast ein Custom Element, im Constructor machst du außerdem noch Datenstruktur.addThis.
Und weil du beim Clonenode auch noch mal durch den Constructor läufst, weil du das Ding ja komplett reproduzierst, wird dann auch dieser Klon in diese Weakmap reingeschoben.
Was irgendwie Sinn macht auf der einen Seite, auf der anderen Seite überraschend ist, weil das nicht dieses Ich-mach-einfach-ein-1-zu-1-Abziehbild ist.
Und bedeutet natürlich, wenn diese Mechanik funktioniert, dass es ja ein bisschen seltsam ist, dass das für Eventlistener nicht funktionieren soll.

[15:35] Ja, aber vielleicht liegt's auch einfach daran, dass die vielleicht furchtbar alt sind oder I don't know.
Ich glaub, vor allen Dingen, es interessiert halt keinen, was da vor sich geht, und deswegen ...
Ich hätte halt gerne aber so eine Funktion, wo man eben sehen kann so, also bei Event Delegation ist das ein bisschen schwierig, aber dass man sagen kann, liste mir alle Event-Listener auf, die gerade an diesem Element dran oder daran drauf zeigen.

[16:08] Der Use Case, wir hatten ja vorhin diesen einen Use Case mit, ich möchte mich vor ein Event hängen, um vielleicht noch irgendwelche Funktionen durchzuführen, bevor das eigentliche Event, das ursprüngliche, bevor das dann feuert. Ja.
Dann wär's ja eigentlich ganz cool, wenn man sagen könnte, also, liste mir bei diesem Element alle Klick-Event-Händler zum Beispiel auf, die da grade dran horchen.
Dann könntest du den quasi erst mal removen. Deinen ranhängen, und dann könntest du deinen wieder Add-Event, wieder dranhängen. Und das kannst du halt nicht.
Naja, oder du könntest dir sowas auch ausmalen wie ein AddEventListener.
Das sozusagen, also du hast ja dein eigenes AddEventListener gebaut.
Mit dem könntest du ja noch ein Parameter hinzufügen, dass du einer gewissen Funktion eine Priorität mitgeben kannst.
Genau, aber wenn ich jetzt zum Beispiel irgendwas, also sagen wir mal, ich benutze, ich binde irgendein fremdes, keine Ahnung, Upload-Dings ein oder so und das hat irgendwelche Event-Listener drauf, dann ...

[17:20] Also dann ist es ja schon zu spät. Also ich könnte natürlich das AddEventListener irgendwie vorher mit einer eigenen Methode überschreiben, die dann irgendwelche neuen Features kann.
Das wäre eine Möglichkeit. Das wäre jetzt mal eine Idee, wo du sozusagen bei deinem, wo ja eh alles durch deine eigene Funktion durchgetunnelt wird, okay, aber du musst wieder mit der Inkompetenz irgendwelcher Dritten zusammenarbeiten.
Ja, genau. Und klar, ich könnte das jetzt auch irgendwie in meine Library reinbasteln.
Wär kein Ding, aber schön wär's vielleicht auch, wenn das eben einfach standardmäßig möglich wäre.
Aber das gibt's halt irgendwie nicht.
Oder wenn du auch irgendwie vergessen hast, oder wenn irgendwer vergessen hat, die Funktion ...
Also die Händlerfunktion auszulagern, dann ...
Kannst du die auch nicht mehr removen. Weil du ja bei RemoveEventListener musst du ja als zweiten Parameter, die gleiche Funktion, Händlerfunktion wieder übergeben, damit er weiß, welche eben removed werden soll. Mhm.
Und, äh, genau, also, das ist schon ... Da müssen so ein paar Bedingungen schon erfüllt sein, und ich denke, da könnten die vielleicht mal ein bisschen mehr Developer-Experience schaffen.
Aber vielleicht müsste ich auch einfach mal eine entsprechende Issue aufmachen irgendwo.
Mhm.

[18:47] Ich überlege gerade.

[18:53] Wäre es nicht so?
Also dein Ziel ist, du willst eine Funktion gezielt einfügen an Anfang oder Ende von einer der beiden Warteschlangen. Zum Beispiel, ja.
Vielleicht möchte ich auch eine, ein Eventlistener entfernen können.
Ja. Der den irgendwelche Third Parties dran gebaut haben.
Okay. Ja, wird halt echt schwierig, weil ab wann gilt ein Eventlistener als auf einem Element befindlich, wenn du halt Capturing und Delegation hast?
Schwierig.
Ha, ha, ha, ha.

[19:41] Aber das ist vielleicht auch dieses, ähm ... Ja, es gibt ja so ein paar alte APIs.
Weiß ich nicht, wie die Document Cookie API ... Ich weiß nicht, wie da der Stand ist.
Da gibt's ja jetzt auch einen Nachfolger.
Ähm, aber es gibt ja so ein paar alte Legacy APIs, die einfach noch mal einen Revisit bräuchten, um sie benutzerfreundlicher zu machen.
Aber das vergisst man dann irgendwie.
Also ... ich denk da ja auch nur dran, wenn ich den Case vor mir habe, oder wenn ich mit dir spreche.
Und mein Leben ist ansonsten auch okay. Aber es wird halt immer viel neue APIs werden gebaut, und vielleicht, müsste man noch mal öfters alte revisiten.
Ja, wobei ...
Events sind halt auch wirklich sehr, sehr Schwierig, also weil ich glaube, dass das Problem ist weniger eins der API, würde ich behaupten, als vielmehr, die Viecher sind in sich so kompliziert.

[20:53] Dass es wahrscheinlich relativ schwierig wäre, sich überhaupt eine, sagen wir mal, API zu überlegen, die da irgendwie ein konsistentes Weltbild bietet.
Also, weil ich meine, die Experience ist, du hast einen Button, du klickst drauf, es passiert in der Reihenfolge 1, 2, 3, die Abfolge BCA.
Und darauf willst du ja einwirken. Aber das kann ja sein, dass diese Dinger halt eben auf dem Button existieren oder auf irgendeinem seiner Parents und oder Kinder.
Kinder. Und die können ja halt eben auch so Sachen sein wie irgendwie...

[21:30] Ja, auch sehr unterschiedlich funktionieren darüber, ob die jetzt passive sind oder nicht, und auch der ganze Mechanismus bezüglich, was passiert, ist ja auch davon abhängig, ob das jetzt sozusagen, ob das jetzt irgendwie ein eingebautes Event ist, also wirklich ein Click, oder ob ich ein Developer-definiertes Event dispatche.
Das ist dann ja schon synchro und nicht mehr asynchron. Und da irgendwie so die, also erst mal die Aussage machen, ich kann durch Betrachtung der Funktionen, die da definiert wurden, Dir sagen, dass in der Reihenfolge die Effekte ABC auftreten.
Mhm. Allein das kannst du ja schon kaum garantieren. Ja, aber ich glaub, das bräuchte ich auch gar nicht.
Also, wenn ich jetzt zum Beispiel ...
Also, ich hatte jetzt grade den Case, dass, äh, also jeder, der UI-Interface baut, muss ja irgendwann früher oder später so eine Combo-Box, ne, klar?

[22:24] Und die Combo-Box brauchte dann aber noch ein Feature, dass es möglich ist, auch komplette Freiformen, also aus vorausgewählten Dingern, was du auswählen kannst.
Beim Tippen hat er dann quasi gefiltert den Dropdown. Dann konntest du aussuchen und mehrere auswählen, in so kleinen Chips, die du dann auch wieder wegklicken konntest.
Aber was noch fehlte, war, dass du quasi was, was nicht in der Liste drinsteht, hinzufügen konntest.
Und genau das Problem war, wenn du dann Enter gedrückt hast, dann hat er quasi diesen Chip erzeugt, der quasi einen Text enthält, der noch nicht in der Dropdown-Liste vorhanden war, hat den da auch hinzugefügt.
Und ganz im Hintergrund ist halt so ein verstecktes Select mit Options.
Und da habe ich dann eine Option eingehängt mit diesem neuen Wert und den auf Selected gesetzt.
Sodass, wenn dann das Formular submittet wird, dass quasi der ganze Kram dann mitkommt.
Ähm, also, genau, so im Hintergrund speichert der quasi den State und die Optionen, die es gibt, inklusive deiner neuen zugefügten sozusagen, deiner, die bisher noch nicht da war, in so einer Optionsliste.
Also, du hast ein Fake-Select als Frontend für ein echtes Select.

[23:48] Genau. Okay. Ja. Äh, und ...
Aber jetzt gab's halt diesen Bug-Report, dass eben diese Freieingaben, die werden nicht mitgeschickt.
Und dann stellte sich heraus, dass das daran lag, dass eben die Person direkt ZAP mitgedrückt hat, anstatt noch Enter zu drücken nach der Texteingabe.
Sodass dieses Select gar nicht auf die Idee gekommen ist, dass jetzt quasi alles fertig ist und dieser Wert jetzt quasi eingefügt werden soll.
Weil die Eingabe nicht signalisiert wurde, jetzt hier so das Wort ist fertig, sondern es wurde dann quasi getippt und direkt mit dem Cursor dann auf Submit gegangen.
Und genau, es wäre halt, das wäre so ein Use Case gewesen, wo ich gerne mich da eingehängt hätte vor dem Submit, um dann noch diese Änderung quasi zu committen in dem Select.

[24:52] Und da hatte ich das Problem, dass ich eben so Runtime, so Race Conditions hatte, wo das eben nicht geklappt hat.
Okay, also dieses Frontend-Backend-Select-Doppelding war jetzt nicht aus deiner Feder, sondern das musstest du hacken? Oder wie verstehe ich das?
Nee, nee, das war im Grunde, war das schon aus meiner Feder, aber da ich ja auch komponentenbasiert arbeite, fände ich es halt schön, wenn diese Komponente in der Lage wäre.

[25:26] Quasi das Mutter-Form-Element entsprechend zu modifizieren, wenn es so ein Case hat, wo es noch was machen muss vor dem Submit.
Und da wäre es halt eben auch cool, wenn man Einfluss nehmen könnte drauf. Und die Chrome DevTools, die können das ja.
Auswählen und dann kannst du sagen, hier, zeig mir mal alle Eventlisten, die da drauf sind, also irgendwie machen die das ja.
Und ich müsste mal nachgucken in deren Codebase, wie die das machen.
Viel Erfolg. Ich hab ja seinerzeit nachgeschaut, als ich mit Hans da an Warhol gebaut habe, wo die denn her wissen, wie so CSS-Variablen, die irgendwie so eine Shorthand für Background oder so hatten, wie die sozusagen wieder rekonstruieren können, welcher Part da jetzt irgendwie Background-Image und welcher Background-Position ist oder so, weil das geht ja laut Standard nicht.
Ich bin nicht sehr weit gekommen, aber vielleicht ist das ja mit Event-Händlern einfacher.

[26:30] Ja, naja, aber das sind jetzt so Edge-Cases auch. Ja, weiß ich nicht. Meine allererste Idee wäre ja tatsächlich da gewesen, wenn ich das hätte machen wollen, was du da probiert hast.
Hast du probiert, da einfach ein On-Click-HTML-Attribut reinzuschreiben?
Meinst du, das wird dann noch mal vor der Capture-Phase ausgeführt?
Das weiß ich jetzt nicht sicher.
Aber ich würde ja annehmen, die Dinger werden ja eingefügt in der Reihenfolge, wie sie auftauchen.
Und ich würde ja annehmen, dass wenn du ein Stück HTML irgendwie in die Seite reinwirfst, und du da wirklich ein On-Irgendwas-Attribut hast, dann ist das ja zuerst da, weil das Element muss ja erst verarbeitet werden, bevor ein JavaScript hingeht und da was draufsetzt.
Mh, na ja, das stimmt. Solange, wie du nicht mit Event-Delegation arbeitest und das Setup dafür schon quasi zu Beginn machst, weil du diese Event-Delegation-Library sozusagen, allen Elementen zur Verfügung stellen willst von Anfang an.
Ja, plus natürlich, du hast ja sowieso Capturing am Start und diese Event-Terminologie.
Heißt das jetzt Händler oder heißt das Listener?
Das heißt, Händler, diese inline-Dinger, okay.
Die sind auch sowieso grundsätzlich Non-Capture.
Mhm. Also vielleicht nicht das, was du brauchst.

[27:56] Ja. Ja. Ja, das heißt, die richtige Lösung wäre da, irgendwie eine Art von Mechanismus von außen dran zu flanschen.
Aber es ist auf jeden Fall schwierig, wenn du nicht den direkten Durchgriff hast.
Andererseits, wenn du direkten Durchgriff hättest, wär ja auch Blödsinn, weil dann könntest du dich ja, nicht darauf verlassen, dass der in der Reihenfolge passiert, weil ja jedes Skript hingehen könnte.
Und weil ja jedes DOM-Element de facto public ist, könnte ja jedes Skript hingehen und jede Eventlist nach Reihenfolge in jede beliebige Reihenfolge bringen. Das willst du ja auch nicht.
Ja, also letztendlich kannst du dann bei dem Submit oder so, da machst du eben Windows Set Timeout und wrapst dann sozusagen alles da rein, außer dein Event Prevent Default und Event Stop Immediate Propagation.
Das musst du ja dann quasi, darfst du da nicht reinstecken, aber damit es funktioniert.
Ja. Aber dadurch gewinnst du sozusagen die Zeit beim Submitten.
Also bis das halt die anderen Elemente dann ihren Krempel machen können, wenn sie das denn möchten.
Und dann submittest du das Formular erst im Anschluss. Ja, und wahrscheinlich ist das völlig okay, weil das merkt ja keiner. Nee, nee.
Nee, es ist schon okay, aber man findet ja immer irgendwelche Workarounds, aber...

[29:19] Das ist dann immer so ein Moment, wo man denkt, ja, wär cool, wenn man da irgendwie so ein bisschen mehr Tooling drum hätte.
Ja, aber wie gesagt, da überhaupt die Wahrheit zu formulieren, die man dann irgendwie exposen oder manipulierbar machen möchte.
Mhm.
Also, ich meine, das schaffen die Dev-Tools, aber seien wir mal ehrlich, die Nutzeroberfläche davon ist ja schon relativ komplex.
Ja. Wie willst du das in Mia-API-Formen gießen?
Ja, man könnte ja zumindest vielleicht so was machen wie...
So bei... Es gibt ja ClassList.entries oder so was. Und das gibt's ja so bei diversen APIs mittlerweile, dass man quasi so die sich die Entries ausgeben lassen kann.
Dann kommt so ein Iterator.
Vielleicht könnte man das eben auch für Events machen.
Ja, dann bräuchte es halt zwei. Einen für Capturing und einen für...
Oder mit Parameter dann. Oder du kriegst die zurück und quasi da steht dann drin, da müsste ja eh im Prinzip sowas drinstehen wie Event-Typ, auf den der gelistet wird, dann Händler und dann könnten ja die dann könnten ja die Optionen irgendwie auch noch zurückkommen.
Äh, was hat man da verkehrt?

[30:45] Du willst ja nicht nur die Händlerfunktion haben. Du willst ja dann auch noch wissen können, was für eine Art Event ist das denn, wann dieser Händler ausgeführt wird.
Im Prinzip müsstest du eigentlich genau das zurückbekommen, was du in AddEventListener reinsteckst.
Ja, was ja sein kann. Also, AddEventListener haben wir halt eben auf der einen Seite.
Und auf der anderen Seite haben wir natürlich auch noch meine guten alten Freunde, die Inline-Event-Händler.
Das heißt, du würdest also eine Funktion rauskriegen. Es gibt ja auch die EventListener-Objekte. Was sind die nochmal?
EventListener-Objekte. Warte mal, ein EventListener consists of bla bla bla, warte mal.
AddEventListener, TypeEventListener, da. CallbackInterfaceEventListener, nee, dann habe ich mich doch vertan.
Okay, dann ist es halt eben also entweder eine Funktion oder ein beziehungsweise man könnte halt eben überlegen, ob man dann schon den kompilierten String, der wird ja im Prinzip einmal eine Funktion gerappt und geevalt, ob man den ausspuckt. So, aber jetzt ist die Gretchenfrage.
Was machst du mit dem Delegation-Krempel? Taucht der auf? Ja? Nein?
Vielleicht? Also ich glaube, in den Dev-Tools, ich glaube, da taucht der auf, meine ich.
Ja.
Genau, aber, ähm, genau, dass ich ...

[32:11] Ich denke, dass das nicht auftauchen sollte. Sondern nur Events, die direkt an Element drangeheftet werden.
Gut, das würde nämlich auch meine zweite Frage. Was machen wir mit den Dingen, die dann detached sind?
Würde das natürlich auch bequem in den Griff bekommen, dann hast du ja kein Delegation-Problem.

[32:33] So, und da muss das natürlich auch noch irgendwie manipulierbar sein, dass du dich da irgendwie reinziehen kannst. Genau, aber wenn du jetzt zum Beispiel ...
Das ist ja dann möglich, ne? Also, du könntest verschiedene Dinge machen.
Du könntest sagen, ich nehme die Funktion, die da drauf ist, und mach erst mal quasi einen Remove-Event-Listener mit dieser Händlerfunktion.
Dann wär das Event weg. Du hättest aber die Händlerfunktion immer noch da.
Du könntest sie also wieder dranheften.
Also auf jeden Fall müsste unsere API dann in dem Fall aber auch mitgeben, ob das tatsächlich ein mit AddEventListener zugefügtes Ding ist oder einer von diesen Inline-Event-Händlern.
Weil die kannst du ja nicht mit RemoveEventListener ansetzen, sondern da müsstest du ja tatsächlich hingehen und die, ja, eine dir genehme Entfernungsvariante wählen.
Also weil da ist es ja so, das Content-Attribut und das IDL-Attribut, die reflektieren einander ja nicht.
Also du setzt den String, dann kriegst du eine Function raus.
Aber wenn du die Function auf null setzt, bleibt das Attribut ja weiterhin da.
Es ist halt nur deaktiviert. Ja.
Das heißt, ich würde vielleicht vorschlagen, dass du dann rausbekommst, so was wie Event-Namen auf der linken Hand und auf der rechten Hand nicht die Functions.

[33:50] Weil mit denen würdest du ja nicht notwendigerweise was anzufangen wissen.
Also weil du bräuchtest halt entweder die Information noch, ist es Event-Listener oder ist es ein Event-Händler?
Entweder das, oder du gibst gar nicht die Funktion selber zurück, sondern du gibst zurück einfach eine Funktion, die du aufrufen kannst, um das Ding zu removen.
Entweder per RemoveEventListener oder per On irgendwas auf null setzen.
Genau, und die würde dann aber nicht nur removen, sondern du würdest quasi die ursprüngliche Funktion würdest du dann im Idealfall bekommen.

[34:27] Aber was, wenn du keine Funktion hast? Weil es könnte ja ein String sein.
Mhm, aber dann ist es doch ein String, der einfach in eine Funktion gerappt ist.
Das wäre jetzt ja auch nicht schlimm, würde JavaScript ja nicht stören.
Nee, nee, es ist ja so, du gibst ein String an bei OnClick und dann macht der unter der Haube tatsächlich eine Function mit einem Parameter, dem Event.
Und das, was du in dem Attribut angegeben hast, also WindowAlertE zum Beispiel.
Ist dann Inhalt dieser Funktion.
Genau, das wird sozusagen GI-Welt, und das GI-Welte wird dann gerekt.
Also, nee, nicht GI-Welt, es wird quasi in Function Constructor gesteckt mit einem Parameter, so kannst du dir das vorstellen.
Genau, quasi New Function im Prinzip macht er daraus.
Richtig, aber das Ding ist ja nicht identitätsgleich mit irgendwas.
Es wird ja ad hoc erzeugt. Ja, stimmt.
Ja, aber dennoch willst du das haben, denn du könntest ja auch so was machen wie ...
Es ist okay, dass der ganze Quatsch da submitted wird.
Daran will ich nichts ändern. Ich möchte nur vorher meine eigene Funktion ausführen.
Dann könnte ich am Ende meiner eigenen Funktion wieder die ursprüngliche Funktion einhängen.
Und das könnte ich dann wieder als Event dranhängen.

[35:40] Das wäre ja zum Beispiel so ein Use Case, wo du quasi non-destruktiv einfach die alte Funktion, also du willst die einfach haben, um nicht, um sie kaputt zu machen, sondern um sie anders einzusortieren und wieder dran zu hängen.
Ja, ich hätte noch eine Idee. Man könnte ja sowas machen wie linke Hand die Event-Namen, rechte Hand gibt es weder die Funktionen noch die Strings noch irgendwas, sondern du kriegst so eine Art Kontextobjekt, wie bei den JavaScript-Decorators, wo du nicht irgendwie direkt die Objekte kriegst, aber halt so eine API für Operationen auf den Dingern. Und wie wäre es, wenn du einfach bekommen würdest Du hast zwei Functions, die da heißen runBefore und runAfter.
Und dann kannst du die benutzen, um sozusagen dir einen Insertion-Point auszusuchen aus der Liste.
Also irgendwie bei Klick passiert dies, dies, dies.
Auf irgendeine Art und Weise kannst du identifizieren, welchen du haben willst, und kannst dann sagen, vor oder nach dem würde ich gerne irgendwas tun.
Würde das dein Use Case bedienen? Weil dann umschiffen wir diese ganze Frage, was kommt raus und mit, was ist das Identitätsgleich? Mh.

[36:51] Klingt schon so, als würde das auch einen ans Ziel bringen, ja.
Und man müsste aber eben auch die Möglichkeit haben, dann nicht nur Run Before und Run After zu machen, sondern eben auch, ähm, weiß ich nicht, Abort oder Delete, Remove.
Um eben die Möglichkeit zu haben, äh ... Da, wo das eben nicht remove-freundlich platziert wurde, das eben auch hinzubekommen.
Sofern man das denn möchte. Ja.
Ja. Wir sollten mal unseren ersten ... Genau, wir müssten einen Editors-Draft machen. Das dürfen wir doch.
Wir machen in der W3C-Community-Group machen wir so einen ...
Oder wie nennt sich das? Community-Draft.
Community Report ist es, glaube ich.
Ja, okay. Ja, das ist immer so, wenn Google irgendwie so sagt, so bau doch bitte dieses Spezialfeature für die Kommunikation mit.
Weiß ich nicht.
90er Jahre Kassettenrekorder irgendwie in den Browser ein, wir müssten doch ganz dringend mal.

[38:08] Was wahrscheinlich aber dein Problem auf andere Weise lösen könnte, wo ich ja zuletzt fest dran war, wäre, wie wär's, wenn man einfach Events, also den Event-Objekten selber, irgendwie ein bisschen Agency verleiht?
Weil ich meine, so ein Event-Objekt, also das wird ja, du schmeißt ein Event, da irgendwie Klick auf irgendwie was, und wenn das da so durchpropagiert durch die ganze Kaskade, dann hast du auf dem Event ja tatsächlich Methoden, womit du irgendwie sagen kannst, prevent default, stop propagation, blah, keks.
Mhm.
Äh, wie wär's, wenn das Event, ähm, so was sagen könnte, wie, wenn du sozusagen dem Event was mitgeben könntest, eine Function, die die Entscheidung darüber trifft, ob das Event für einen gegebenen Event-Listener einen Effekt erzeugt oder ob es es gibt.

[39:05] Weil skippen kannst du ja nicht. Du kannst ja sagen, okay, hier ist Schluss mit Stopp Propagation.
Aber du kannst halt nicht sagen, ja, nee, aber den jetzt nicht.
Also du kannst quasi nicht das Ding selber ...
Du kannst nicht das Event entsprechend aufschlauen. Ja. Ja, aber dann hast du doch gar keinen Zugriff mehr dann drauf.
Also wenn irgendwer anders so diesen Eventlisten ersetzt und seinen Händler dran klatscht, dann guckst du ja doof aus der Wäsche, dann kommst du ja nicht da rein.
Wie nicht? Im Moment ist es ja so, du hast ein Event und dann läuft die event-händelnde Funktion los und die event-händelnde Funktion entscheidet, was sie mit dem Event macht.

[39:45] Ja. Wie wäre es, wenn das Event da mitreden könnte? Also es ist sozusagen ein zweiteiliger Aushandlungsprozess. Einerseits bekommt die Funktion das Event übergeben und sagt so, hm, was mache ich denn mit dir?
Und andererseits bekommt das Event die Funktion übergeben und entscheidet, will ich überhaupt mit dir reden?
Okay, und dann, wie würdest du dann, wie würdest du dann damit arbeiten?
Du könntest ja zum einen return true false rausgeben, für false wie ich will für dieses Ding unsichtbar sein.
Aber du hast dann zu dem Zeitpunkt ja die Funktion in die Finger bekommen.
Und dann hast du die. Und dann ist es auch egal, ob es tatsächlich als String definiert wurde oder anders, weil du befindest dich ja im Prozess der Ausführung.
Dann ist das Ding evaluiert und du hast definitiv die Function, die dich ausgeführt hätte.
Und du könntest ja theoretisch dann so Späßchen machen wie, okay, ich nehm dich, ich lehn dich erst mal ab, aber ich speichere dich irgendwo in einer Map, und wenn ich das nächste Mal durch eine Funktion durchlaufe, bei der ich sage, ist okay, führ ich dich vorher wieder aus.

[40:44] Mhm, okay. Das Event würde sozusagen auf einer Case-by-Case-Basis entscheiden, in welcher Reihenfolge es, also erst mal so, es wäre ja, er hätte erst mal prinzipiell bloß die Funktion, Händler abzulehnen.
Und könnte halt sozusagen als Nebenwirkung dann später noch entscheiden, eventuell wieder was damit zu tun.
Okay, aber wie würdest du dem denn beibringen, dass es eine, sagen wir mal, du musst ja immer den Use-Case berücksichtigen, dass irgendein Third-Party dieses Event auf was draufgesetzt hat.
Und ich möchte das irgendwie verhindern. Wie könnte ich das dann machen?
Weil, woher wüsste ich denn, wie die Funktion genau ausschaut?
Also, wie würde ich halt diesen Vergleich machen? Wie würdest du sie identifizieren?
Ja, das wäre ein bisschen das Problem, wenn es von irgendwelchen Third-Party kommt und irgendwie unbenannt, unexportiert irgendwo herumliegt.
Das stimmt, das haut nicht. Ich glaube, dieses Abort-Signal ist ja auch so ein bisschen so eine, sagen wir mal, nicht genau das, aber so ein bisschen so, wenn du selber die Kontrolle über die Dinge hast, deinen Weg, das zu machen.
Ja, aber das Bot-Signal hat auch kein Konzept von Skipping. Das hat ja nur ein Konzept von Schluss.
Das wäre ja gleichbedeutend mit Stopp Propagation.
Nö.

[42:07] Das ist alles nicht so einfach. Nee, weil was ich letztens probiert habe, irgendwie hinzukriegen und was nicht geklappt hat, ist, ich wollte Events haben, die sich nur auf bestimmten Targets dispatchen lassen.

[42:23] Weil das ist ja eigentlich, also erstmal ist das ja irgendwie sowieso de facto logisch.
Das passiert ja. Du hast Input-Events auf Dingen, in denen du rumtippen kannst.
Dein Title-Element wird niemals ein Input-Element abschicken.
Warum muss das überhaupt im Bereich der Möglichkeiten bestehen?
Und das ist speziell lästig, wenn du irgendwie TypeScript am Start hast, weil du hast irgendwie dein Input-Event-Element, und da setzt du addEventListener drauf.
Und dann hat das Event-Objekt ein Target-Typ, der ist entweder null oder Event-Target.
Und null macht ja Sinn, weil das Event, wenn es erzeugt ist, bevor es dispatched ist, hat halt noch kein Target. Also könnte das null sein, das ist okay, das kann man halt nicht wegdiskutieren.
Aber Event-Target ist halt so generell, dass es halt echt nutzlos ist, weil du kannst damit ja nichts anstellen.
Und aus dem Kontext heraus, weißt du ja meistens, mit was du hantierst.
Weil ich hab ja AddEventListener auf dem Input gemacht.
Ich weiß, dass das Target dieses Input-Elements sein wird.
Es sei denn, irgendwas läuft schief, oder ich mache sehr seltsame Verrenkungen mit meinem Handling-Capturing.
Oder du baust halt eine Web-Component und hast halt ein Event gebaut, dass du weißt, das ist ein Custom-Event, das schmeißt sich nur aus dieser Komponente heraus.
Es gibt unter gar keinen Umständen auch nur die Möglichkeit, dass das was anderes ist.

[43:33] Und das steht ja halt meistens so bei TypeScript rum. Und das ist auch kein Problem.
Du kannst mit TypeScript etwas konstruieren, das sagt, wenn dieses Event irgendwie gehandelt wird, dann ist das Target entweder null oder diese spezifische Komponente.
Das kannst du TypeScript behaupten lassen, aber du kannst es zur runtime nicht entforcen.
Weil jedes Event sich von jedem dahergelaufenen Scheißteil dispatchen lässt.

[43:57] Ja, genau. Du könntest ja... Naja, bei Title ist schwierig, aber du kannst ja theoretisch, ein Content-Editable-Attribut auf alles setzen, und dann hast du ja, glaub ich, auch das Input-Event, oder?
Okay, das Input-Element. Aber mein Custom-Component-Event halt nicht.
Mhm.

[44:14] Das wohnt in meiner Custom-Component.js. Das wird nur darin verwendet.
Ja, und das Submit ist ja auch nur ...
Also, geht ja auch nur auf Forms. Oder, also ... Außer ich hab jetzt irgendwas vergessen, aber ...
Ja gut, und selbst wenn du sagst, Content-Editable, Ich kann ja alles Content-Editable machen, okay, sicherlich, aber was ist, wenn nicht?
Also willst du nicht irgendwie die Möglichkeit haben, auch so Dinge, die passieren könnten, aber die du dir halt eben wegdefiniert hast?
Du könntest auch evil und das with-Statement und lauter anderen Blödsinn verwenden, aber du tust es halt nicht. Und du kannst halt tatsächlich auch auf Basis der Annahme, das passiert nicht, operieren. Und ich kann TypeScript auch behaupten lassen, diese Annahme würde zutreffen, aber ich habe halt keinerlei Möglichkeit.

[44:57] Zur Laufzeit das zu garantieren.
Ja, es sei denn, ich hacke irgendwie hier, Dispatch-Event. Das kann ich auf meiner Komponente machen, aber das bringt mir nix, weil ich ja sowieso weiß, dass ich das nur da dispatche.
Ich möchte aber die Garantie haben, dass niemand anderes das machen kann.
Weil wenn das Event bubbelt, kann's ja irgendwer in die Finger kriegen und kann sich ja Event.Constructor rausholen.
Und kann damit, auch wenn's nicht exportiert wird, theoretisch Events von der Sorte erzeugen.
Und dann guck ich wieder in die Höhle. Hör mal, du arbeitest doch an einer Web-Anwendung für den Geheimdienst, die so sicher sein muss, wie es nur geht.
Äh, nee, tatsächlich nicht.
Nee, woran ich arbeite, sind immer noch meine Web-Component-Decorators.
Und deswegen hab ich dich so gerade mit dem, ja, ganz zu Beginn mit dem Event-Capturing genervt, weil es fehlt halt noch die Möglichkeit, also da hab ich so einen Subscribe-Decorator, und der kann halt subscriben entweder auf ein Signal, irgendwie hohoho, ich bin quasi React sein möchte. Und das ist ja einfach, weil das ist halt im Prinzip in Observable mehr oder minder so, das ist easy darauf zu subscriben.
Aber auf dem Event-Target ist halt schwieriger, weil äh...

[46:09] Aus den ganzen genannten Gründen. Weil du willst natürlich auch, wenn du jetzt irgendwie ein modernes JavaScript-Tool schreibst, willst du ja zumindest irgendwie TypeScript nicht komplett nicht berücksichtigen.
Du klatschst also so einen Decorator für Handle ein Click-Event auf mir selber in so eine Klasse rein.
Dann willst du ja, dass TypeScript irgendwie das dich nur machen lässt, wenn die Methode, auf die du das Ding drauf klatscht, als Parameter auch ein korrekt typisiertes Event-Objekt hat und du willst für die Developer Experience dann ja wissen, Man kann ja wissen, okay, das ist ein Klick-Event auf mir selber, also wird das Target ja wohl meiner selbst sein.
Du willst das alles automatisch garantieren, dass man sich nicht in den Wolf tippen muss.
Sonst kommen die Leute wieder unter Typing-Script.
Das willst du ja alles nicht. Und es ist mit TypeScript alles hinzukriegen, aber man kann's zur Laufzeit nicht garantieren.
Weil wenn du das Offensichtliche probierst und irgendwie so ...
Also, das Target ist ja komplett Magic.
Das Event hat einfach dieses Read-Only-Feld. Und sobald es durch Dispatch geschickt ist, passiert irgendwas.
Und das ist komplett unter der Haube. Da hast du null Zugriff drauf.
Da kannst du keinen Getter-Setter definieren, da kannst du auch keinen Proxy vorhängen, weil das ist jetzt schon die zweite API, die ich gefunden habe.

[47:20] Die einfach Proxys kategorisch ablehnt.
Ja, und dann schaust du halt in die Röhre. Und nur, weil ich halt wirklich so irgendwie probiere, irgendwie so mit irgendwie 3KB, irgendwie so ein Min-Max-Webcomponents schreiben, aber ohne, dass ich halt mir irgendwie 17-GB-Framework reinladen muss, Da steck ich halt auf so ein Kram im Moment rum.
Allerdings bin ich gestern durch die To-Do-MVC-Mauer durchgelaufen.
Ich hab gestern so gedacht, hey, kann ich das eigentlich machen?
Dann hab ich's runtergeschrieben, 17 Bugs gefixt, und dann lief's tatsächlich.
Und das Einzige, was halt fehlt, ist, ja, Event Capturing.
Und wahrscheinlich sollte das Capturing der Default sein.
Ach so, würd ich vorschlagen, ja. Weil sonst kann man ja nicht davon ausgehen, dass es funktioniert.
Ja.

[48:08] Ja, okay. Dann muss sie das machen. Das wird spaßig.
Ich bin gespannt, was dabei rauskommt. Funktioniert. Ich hab schon meine Präsentationssoftware so umgeschrieben, dass sie die Sachen benutzt.
Das klappt alles ganz gut, aber die macht auch nicht so viel mit Shadow DOM und so Gewurschtel. Das ist alles.
Also, relativ einfach. Boah, Alter, Shadow, das ist, glaub ich ...
Ich bin mittlerweile echt am Überlegen, ob das vielleicht ein gewaltiger Griff ins Klo war.
Ja, ja, also, das kristallisiert sich ja jetzt irgendwie an allen Ecken und Enden raus. Und, äh ...
Also ... Mir gefällt der auch nicht. So von der User-Experience oder Developer-Experience.
Ähm ...

[48:57] Genau, und es gibt ja jetzt auch immer mehr Leute, die sagen so, nimm halt Web Components, aber lass einfach das Shadow DOM weg.
Und ich glaube, so dieses Style Scoping und sowas, das kannst du ja auch im Prinzip mittlerweile, oder das quasi auch das Abschirmen von reinliegenden Styles.

[49:21] Da kannst du ja einiges machen, ne?
Also, dass du quasi, entweder du hast ein Build-Tool, das dir deine ganzen inheritbaren Styles aus der MDN zieht und die alle quasi auf Revert setzt.
Oder du nimmst Add Layer mit und machst da Importance drauf. Dann, glaube ich, überschreiben die ja auch quasi das.
Dann, Importance dreht ja quasi immer, wer hat Vorfahrt um sozusagen in der Kaskade und damit könntest du das ja auch machen, also wenn du Dinge überschreiben willst oder du kannst ja auch mit AdScope jetzt arbeiten, dass du quasi sogar mit Anfang und Ende deines Scopes, also so Donut-Verfahren, dass du deine Slots, wenn diese drin sind und die dann bestückt werden müssen mit Sachen, die von außerhalb kommen, du die dann Und dann wiederum nicht Styles mit deinem Krempel.
Mhm. Ich glaube aber, das Problem würde ich ein bisschen anders framen.
Weil ich würd sagen, Shadowdome ist voll gut für sehr ausgesuchte Use Cases.
Und das sind nicht die Use Cases, die Max Mütze haben will, wenn er Reactor setzen möchte.

[50:31] Stell dir vor, du baust dein Select, über das wir gesprochen haben.
Wo dieser ganze detaillierte Aufbau innen so drin ist, und du hast ein echtes Select, das hast du aber unsichtbar gemacht, aber das muss weiterhin irgendwie so funktionieren und so Zeug.
Das Ding, wenn du es wirklich wiederverwertbar und so universell einsetzbar haben willst, das in so einer Shadow Boundary einzudosen, die halt auch so hingeht und diese ganzen internen Events ja auch mitverschluckt, dass die da nicht rausbabbeln zum Beispiel.
Das halte ich schon für sinnvoll, und dafür wär Shadowdom wahrscheinlich irgendwie ganz gut.
Aber da haben wir ja wieder das Problem, dass das ja jetzt Formularelemente sind.
Aber ja, die kapseln halt sehr viel irgendwie Komplexität, und das wär halt ganz nett, das portierbar zu machen.
Genau, also, ich würde sagen, das ist kein Problem, weil das ein Formularelement ist, weil du gehst halt eben hin und baust ein neues Formularelement.
Und dann solltest du halt eben auch ein neues Formularelement bauen und halt eben einmal die API durchjonglieren.
Keinen großen Schaden an.
Wenn du jetzt sagst, ich mach das Anmeldeformular für irgendwie, keine Ahnung, die Airline, für die ich arbeite, und ich hab sieben Formulas in der Reihe geschaltet mit jeweils zehn Rows.

[51:40] Und da muss ich jetzt einfach nur sozusagen die ganz normalen Textinputs und Selects und so ein bisschen vorkonfigurieren, dass die die richtigen Styles haben und Behaviors oder so.
Dafür ist das halt völlig Banane. Und das ist auch okay, dass das dafür völlig Banane ist, dafür sind die anderen Nicos Cases, die du grad gelistet hast, Shadow DOM, Griff ins Klo, würde ich jetzt eher so sagen, das Ding wird extrem nützlich sein für einen Use Case, von dem sehr viele profitieren werden, den aber sehr wenige tippen werden.
Die meisten werden sagen, NPM, Import, Chaps, feines Select-Element.
Aber für die ganz normale Komponenten-Story brauchen wir, glaub ich, echt was anderes.
Weil selbst wenn du weißt, wenn du Shadow DOM lebst und atmest, am Ende des Tages machst du trotzdem auf Autopilot irgendwie dann Styles in deine Webseite, und dann wunderst du dich, warum wirken die nicht, Natürlich, sieben Ebenen in Shadow DOM drin.
Aber das sollte halt wirklich nur mit den Dingern passieren, wo du gar nicht auf die Idee kommst, die zu stylen. Es sei denn, du machst wirklich sowas wie, wenn du native Formularelemente hackst, wo du sowieso weißt, okay, jetzt muss ich halt an einer Stelle mal was nachbessern.
Ja.
Aber so allgemein ist das halt echt mega, mega fies.
Naja. Weil, warum, was ich für einen Stunt machen musste, also ...

[52:52] Ich will irgendwie sagen können, dass du eine Klassenmethode hast, und da baust du einen Decorator oben drüber, gibst da an einen Event-Namen, gibst da an einen Selektor, und dann macht der unter der Haube halt ein ...
Also, sieben Sachen, aber unter der Haube am Ende dann halt eben AddEventListener auf einem Ding mit dem Event-Namen und einem EventTarget.Matches-Selektor.
Mhm, ja. Okay, alles tutti. Und das ist genau der Punkt, wo ich noch mal diese Event-Optionen einbauen muss.
Was im Moment noch nicht geht.
So, aber jetzt baust du eine Web-Component im Sinne von deinem Select.
Also du willst eine Shadow DOM Encapsulation Boundary haben.
Wie kriegst du die zu fassen in diesem Decorator? Weil dieser Decorator ist ja etwas, das modifiziert ja das Klassenobjekt-Methode, wo ich das oben drüber schreibe.
Das ist das Ziel von dem Decorator, das bedeutet notwendigerweise, der muss laufen, so früh wie möglich, wenn diese Klassendeklaration ausgewertet wird.
Das bedeutet notwendigerweise, bevor die Klasse instanziiert wird, und das bedeutet automatisch, es gibt gar keinen Shadowroot, den ich da referenzieren kann.
1

[54:02] Das kann ich also nicht sagen. Ich kann nicht sagen, handle das Light DOM, handle das Window-Objekt, handle den Shadowroot, weil die Möglichkeit, auf den Shadowroot zuzugreifen, geht erst mal per se gar nicht.
Ja. Okay, was machen wir? Da willst du aber ja deinen Events dranhängen.
Genau. Ich will ihm also sagen, ich geb dir was, das ist nicht der Shadowroot, weil den gibt's noch nicht, aber ich will dir was geben, wo du den Shadowroot rausholen kannst, sofern es dann eines Tages einen gibt.
Mhm. So, jetzt sagst du natürlich, das ist easy, einfach eine Function. Diese Function wird aufgerufen, wenn das Element sich instanziiert.

[54:37] Und ein Shadow Root bekommt. Das ist ja ohnehin der Moment, wenn du das Event anbringen willst, also du musst dich notwendigerweise mit dem Zeitpunkt der Instanzierung abklären und dann kannst du bei der Gelegenheit einfach eine Callback-Funktion abfeuern, gibst dem als Dis das Dis der Klasse, badabing, badabung, kannst du machen. So, kannst du auch machen, Aber wenn du das machst, kannst du das nur machen, wenn dein Shadowroot tatsächlich irgendwie publicly available ist.
Weil du hast eine Klassendeklaration, außen drum, von oben bis unten, da drin hast du die Methode.
Du kannst in der Klassendeklaration diese privaten Felder benutzen mit der Raute.
Du kannst in der Methode die privaten Felder benutzen in der Raute.
Aber das geht halt im Kontext der Klasse. Und der Decorator ist ja tatsächlich nicht Bestandteil der Klasse, ein die Klasse modifizierender Function Call, der damit eigentlich nichts zu tun hat.
Das heißt, obwohl in der Zeile vor diesem Decorator ich Raute irgendwas verwenden kann, in der Zeile darunter, ich Raute irgendwas verwenden kann, kann ich das nicht in der Function machen, in der das dann drin ist.
Jetzt könnte man sagen, meine Güte, scheiß dich halt nicht ein, nimmst halt ein Public-Feld, so ist halt dein Shadowroot Public, was soll's, wenn du da irgendwie Shadowroot-Mode open machst, ist das Ding sowieso Public.
Die ganzen, die ganzen OOP-Nazis um die Ecke und sagen, das muss aber private sein.

[55:55] Okay, was machst du dann? Natürlich machst du Folgendes, du baust eine Weakmap im Constructor des Custom Elements, sagst du, okay, ich mach einen Shadowroot, speichere den in einem privaten Feld ab, aber speichere die Referenz auf das Shadowroot auch in der Weakmap indiziert by this und in der Function kannst du dann ja diese Weakmap wiederverwenden, einfach so qua Closure-Logik, und du hast das this, also kriegst du deinen Shadowroot raus, den du dann returnen kannst, damit du dann Event-Listener draufpacken kannst.
Und das kann man alles machen, Und das funktioniert ganz, ganz wunderbar.
Und das kannst du auch so abstrahieren. Diese Decorate das in Plus Function, machst eine Partial Application, exportierst die aus irgendeinem Modul, keiner weiß, dass das unter der Haube vor sich geht. Aber es ist eklig.
Es ist halt eklig. Wie gesagt, den Ekeleffekt kann man in den Griff bekommen.
Ich finde, der sollte halt die meisten Leute nicht betreffen.
Das sollte halt wirklich diejenigen betreffen, die wirklich sagen so, ich geh jetzt all in und baue ein neues, besseres Select. und diese besseren Selects werden wir brauchen.
Dafür ist dann auch Shadowroot ganz nützlich.
Aber als Komponenten-Encapsulation-Boundary, wie das so im allgemeinen Sprachgebrauch gedacht wird, ist das halt echt mit Schiffsartillerie auf Bakterien schießen.

[57:07] Ja. Ja, da kommt ja noch dazu, dass es ja auch ... encapsulated ist im Sinne von DOM-Access und CSS und so.
Aber wiederum nicht eine eigene JavaScript-Welt in diesem Dings leben kann, ne?
Ja.
Das ist ja so der auch noch ein Baustein, der fehlt und der irgendwie seltsam ist.
Aber warum das so ist, das kann ich nachvollziehen.
Da gibt's ja dann irgendwann mal, glaub ich, diese Realms, die dafür gedacht sind.
Ich wollt grad sagen, Shadow Realm hab ich grade gegoogelt, der was anderes ist, aber hier gibt's das Proposal auch.
Ja. Stage drei. Mhm. Also, ich weiß nur nicht, ob die dann am Ende ...
Also, ich glaube, dass das ein wichtiger Baustein ist, aber du trotzdem recht hast, dass es im Prinzip so ein bisschen wie bei WASM ist.
So cool, dass das geht.
Und wer damit umgehen kann, super.
Aber ... äh, genau, die meisten Leute sollten eigentlich gar nicht damit arbeiten müssen.
Und höchstens die Früchte ernten in Form von fertigen Paketen, die sie benutzen können.
Die sie auch benutzen werden, weil genau wie bei Wysom würd ich deiner Aufzählung von Attributen hinzufügen, es ist voll nützlich und wichtig, dass es das gibt.

[58:30] Aber es wird halt im Moment, glaub ich, echt so als Werkzeug propagiert für das Falsche irgendwie. Ich hab ... ja.
Also, das ganze Gewurschel mit so dem Zugriff und dem Shadow DOM und so, das kriegt man alles noch irgendwie hin, dass das alles funktioniert mit Event Delegation. CSS zu schreiben.

[58:47] Weil CSS halt einfach konzeptuell komplett kaputt geht. Sobald du damit anfängst.
JavaScript wird halt komplizierter. Und dein DOM nachvollziehen zu können, wird halt komplizierter.
Aber CSS geht halt einfach völlig kaputt.
Und die wenigen Vorteile, die es hat, ich schreib halt einmal, wo war es hin, und dann gilt das überall, der geht halt einfach kaputt. Und dann hat das halt wirklich nur noch Nullvorteile.
Und das ist echt so der Tritt in den Allerwertesten, das halt nicht sein müsste.
Was ist denn hier mit diesem Shadow Realm? Wann gab's denn das letzte Update?
Vor ... äh, letzten Monat. Okay.

[59:28] Ja, aber ... ja. Das wäre was, ein distinct global environment.
Das wäre super. Du kannst einfach Prototypen patchen, bis der Arzt kommt und keinen stört.
Ja. Also, ich ... Genau, ist ja auf jeden Fall gut, dass so Leute wie du und auch diverse andere so das alles testen und quasi mal in die Praxis bringen teilweise auch also bei dir ist ja so du bringst es ja auch in die Praxis du hast ja aber so die das dann auch in so wirklich customer facing Projekten in die Praxis bringen und die finden dann eben einfach so die ganzen Probleme und vielleicht auch Workarounds und das schon gut ist, dass Leute das erforschen, aber das sollten eben nur ein paar Leute vielleicht tun erst mal.
Und ...
Dann gucken wir mal. Oh. Hm. Hm. Weiß nicht.
Weiß nicht. Es kann sein, dass Shadow DOM nicht optimal ist, aber ist im Moment für viele Fälle vielleicht das Beste, was wir haben.
Und vielleicht gibt's ja Workflows, bei denen das eine sinnvolle Boundary darstellt.
Weil ich meine, die meisten wollen ja kein CSS schreiben.
Das ist ja irgendwie voll IBA und wir wollen lieber irgendwie Mr. JavaScript schreiben, dass das da reinbastelt.
Das funktioniert dann, glaube ich, schon relativ gut.

[1:00:55] Genau, aber dann nutzen die ja wahrscheinlich irgendwelche fertigen Pakete wieder, und machen das vielleicht nicht alles per Hand oder?
Ich bin zu der Überzeugung gekommen, dass das von Handmachen eine schlechte Idee ist, die unmöglich ist.
Mhm. Ich weiß nicht, ob du gestern meinen Master-on-Post des Tages gesehen hast.
Hab ich gesehen. Ich glaub, ich hab nicht viel geschnallt. Wie das häufig so ist.
Na ja, es waren Custom-Element-Upgrades. Also, du kannst ja ...
Du planst eine Custom-Element-Klasse irgendwie MyFu zu bauen.
Du kannst ja, bevor du die hast, schon sagen, und dann kriegst du halt ein HTML-unknown-Element.
Stimmt, das war so ein Zwischenstate, glaub ich, ne? Also, dass du so zwischen den Welten hingst auf einmal.

[1:01:41] So quasi startenlos war das Ding oder so. Nee, nee, schlimmer. Okay.
Also, pass auf. Du kannst ja zwei Dinge machen. Du hast eine Webseite und du hast ein blockierendes Script ganz am Ende, ganz am Anfang im Head.
Und machst ganz am Anfang im Head, custom elements define dieser TagName ist von dieser Klasse beschrieben.
Dann wird das Skript ja synchron ausgeführt, das heißt, der HTML-Parser wird im Head darüber in Kenntnis gesetzt, dass er im Body Elemente zu erwarten hat, die durch diesen Tag mit dieser Klasse implementiert werden.
Und im Rahmen seines Parsings kann er dann sofort sagen, aha, das ist myFoo, das muss ich mit dieser JavaScript-Klasse in die Welt setzen, und zack, läuft sofort.
Szenario eins. Szenario zwei ist, Webseite mit diesen Elementen da drin, aber dein Skript ist am Ende der Seite, oder es ist Async oder sonst irgendwas, Und dann muss der Browser ja auch das HTML durchparsen, darf dabei keine Exception schmeißen oder so, er muss es ja verarbeiten, um dann am Ende zum Skript zu kommen und zu merken, oha, ich hab ja diese Elemente alle falsch verarbeitet.
Und dann werden die nachträglich geupgradet.
Was auch kein Problem ist, du machst ja im Prinzip einen Prototype-Swap, was ja jetzt irgendwie nicht schön ist, aber was du ja machen kannst. Mhm. So.
Dieser Upgrade-Prozess passiert aber, habe ich gelernt, nur mit Elementen, die connected sind, oder die du manuell mit der Upgrade-Funktion von Custom Elements bearbeitest.
Mhm.

[1:03:02] Connected heißt, die sind im DOM. Die sind im DOM, genau.
Die sind irgendwo in einem aktiven Dokument drin. Die können ... Parents haben noch und nöch, aber wenn die Parents nicht auch irgendwo im Dokument sind, dann ist das Gesamtpaket nicht connected.
Und jetzt hast du halt aber nicht permanent Dinge, die connected sind.
Weil wenn du irgendwie zum Beispiel DOM-Diffing betreiben willst, du kannst ja so ein virtuelles DOM bauen, wie sie bei React das haben, wo du irgendwelche abstrakten Datenstrukturen hast Du hast irgendwelche echten Diffs und gleichst einfach andere Diffs denen an.
Wenn du also jetzt Custom Elements hast und du machst so eine Sache, wo du so sagst, ich definiere meine Komponentenklasse 1, 2, 3, und du hast in diesen Dingern, in zum Beispiel deren Constructors, was drin, was hat, muss ich jetzt vormüßig formulieren, was irgendwelche Logik verwendet, die irgendwelches DOM produziert, das erst später definiert ist, kannst du in die Situation kommen, dass du sozusagen bei deinem DOM-Diffing von Sachen ausgehst, die noch gar nicht geupgradet sind und die niemals geupgradet werden, weil die bei diesem Diffing-Algorithmus der Sollzustand sind, also niemals eingehängt sind, versus der Ist-Zustand, der eingehängt ist.
Das heißt, du gleichst den Ist-Zustand, der geupgradet ist, an das an, was ein Soll-Zustand ist, der nicht in dem Zustand ist, wo du ihn erwartest, weil er nicht geupgradet ist.

[1:04:25] Und ich war schon so dabei, ha, deine DOM-Defining-Library ist voll schlecht.
Hier ist mein Bug-Report. Und dann erst so, Moment, was?
Wieso sind diese ganzen Properties nicht da? Und das Schöne ist, der HTML-Parser frisst ja alles.
Und du kannst ja auch auf irgendwelche HTML-Elemente irgendwelche Properties setzen.
Also hast du eine Custom-Element-Klasse definiert mit einem Getter-Setup-Hub für ein Value.
Du kannst auf dem Ding ja, auch wenn es nicht geupgradet ist, irgendwie schreiben, meinElement.value. Und das auf irgendwie eine Zahl 7 setzen.
Die Zahl 7 wieder zurück. Alles easy. Aber die Getter und Setter, die irgendwelche Nebenwirkungen triggern, die laufen dann ja nicht. Und selbst wenn die nachträglich dazukommen sollten, sind die irgendwo auf dem Prototypen, aber die 7 ist dann ja schon da auf dem Objekt selber.
Ja.

[1:05:08] Cool. Und das muss alles nicht sein, das kann man alles in den Griff kriegen, Aber das ist so ein Jonglieren von so vielen...
Dass man da nicht um irgendeine Art von Software drumherum kommt, die das ein bisschen angleicht.

[1:05:21] Oder was du ja auch letztens meintest, dass es halt einfach ...
Genau, dass der Browser selber einen Diffing-Algorithmus bietet, der dann wahrscheinlich diese Edge-Cases irgendwie alle kennt und einfängt.
Das ginge natürlich.
Mhm. Wobei ... Ich glaub, hier die Sanitizer-API wurde ja irgendwie jetzt auch noch mal zurückgezogen und überarbeitet. auch wegen Shadow DOM oder Declarative Shadow DOM in dem Fall.
Jo. Jo. Also, das ist schon eine fiese Wurmdose, die da geöffnet wurde.
Ja, das ist halt so das größte Problem, wo ich halt so denke, also, du hast ja grad gesagt, das ist ja schön, dass Leute wie ich hier den Internet Robert Falcon Scott geben und wir sagen auf zum Pool.
Und egal, ob wir da beide raufgehen, wir gucken einfach mal, was da ist.
Ja, sehr gut beschrieben. Ist ja alles irgendwie ganz nett.

[1:06:13] Aber ... ist das wirklich nötig gewesen? Weil ich meine, wenn du heute mal durch die Spezifikationen durchskrollst, irgendwo im DOM für irgendwas, du siehst halt immer so, wenn was Neues eingefügt wurde, das irgendwie so relativ fundamental ist.
Dann prägt sich das halt immer daran aus, dass halt eben hier, da, dort alle möglichen anderen Sachen angeglichen werden müssen.
Nirgendwo scheint mir das so krass zu sein wie bei Shadow DOM.
Weil bei jedem DOM-Otto, der irgendwo stattfindet, muss halt in jedem Algorithmus, der sich Parents anguckt, auf irgendeine Art und Weise immer eine Extrawurst gebraten werden, Von Shadow DOM machen wir diesen Spezialfall.
Ja, genau. Also, wenn quasi das gleichzeitig ein ... Oder ... ja, letztlich auch, wenn du ...
Wenn du Elemente selektieren willst.

[1:06:59] Und das vielleicht über Shadow-DOM-Grenzen hinweg, wenn das ein offener Shadow DOM ist, dann musst du ja auch quasi gucken, ob ein Element ...
Dann musst du quasi alle Elemente absuchen, ob sie Shadow Roots sind.

[1:07:16] Um dann noch mal in ihm selbst ein Query-Selector-All durchzuführen und das gleiche Spielchen wiederzumachen da drin.
So Geschichten, genau. Und ich weiß ja nicht, wie dir das geht, aber wenn ich ein Stück Software habe und ich baue da was dran, und dann merke ich, dass ich im Zuge dessen an 39 anderen Stellen auch noch was anpassen muss ...
Ja, das fühlt sich nicht gut an. Nee, ist das vor allen Dingen ein Indikator, dass das, was du angebaut hast, so in der Form ...
Nicht immer, aber sehr oft nicht die optimale Wahl ist.
Ja. Und dass jetzt vielleicht der richtige Zeitpunkt für einen Spaziergang oder sonst irgendwas ist, um noch mal kurz drüber nachzudenken.
Ich mein das ernsthaft.
Ja, du hast recht, ich geb's dir vollkommen recht. Ja, das Problem ist natürlich, manchmal ist es halt eben so, dann muss das halt eben gemacht werden.
Aber es ist halt sehr oft ein Indikator, es ist halt im Prinzip ein Code-Smell, ein Module-Smell quasi.
Mhm. So. Hätte man bei Shadowdom vielleicht echt irgendwie sagen müssen, Ich glaube, ich habe deutlich runterscopen können und es sehr viel mehr auf diesen einen Use-Case, von deinem Fancy Select zuschneiden können.
Und dann hätten wir das ganze Problem nicht. Dann würden alle heute ihre Web-Components ins Lightdome rendern. Wie sie es vielleicht machen sollten, keine Ahnung.

[1:08:30] Ja. Und dann könnte man sich da was anderes überlegen mit, ja, Shadow Realms oder CSS-Scope.
Ich glaube, CSS-Scope ist eigentlich 80% von dem, was du so brauchst. Also du brauchst ein CSS-Scope und vielleicht wirklich irgendwie die Möglichkeit, dass du sagen kannst.

[1:08:50] Also, dass du vielleicht explizit Barrieren aufstellen kannst, die das Shadow DOM aufstellt. Das macht ja mehrere Barrieren.
Ne DOM-Barriere, ne CSS-Barriere, ne JavaScript-Barriere.
Dass du quasi dir auch sagen kannst, ich will nicht alle auf einmal.
Ich möchte gerne primitive Bausteine haben für die einzelnen Barrieren, die ich dann zur Anwendung bringen kann.
Weil ich könnte mir vorstellen, dass ich in einer Welt, in der Shadow DOM existiert, zufrieden wäre, also ich jetzt für meinen Use Case, funktioniert wie immer. Weil CSS gar nicht. Und jemand anderes, der die vielleicht nur React mit irgendwie JavaScript, mit JavaScript CSS gemacht hat, würde vielleicht sagen, nee, ich will die Komplettbarriere, weil ich schreibe sowieso mein CSS für jede Komponente neu. Das ist, wie ich es gewohnt bin, das kenne ich, ich habe die Libraries, blablabla, funktioniert. Dann sollen die halt das, machen. Oder, oder, oder, oder. Aber das ist halt einfach nur so ein so ein großes Ding, gibt so das ganze Paket so, wumms, schmeißen sie dir auf den Tisch. Hier, damit ist jetzt alles dicht. Viel Spaß Ja.
Hätte man die Dinger auch so stückweise ausrollen können, nicht eine große Spezifikation, sie alle zu knechten.

[1:09:57] Und das ist so der Grund, warum ich beim Declarative Shadow DOM im Moment halt immer so denke, boah, ich bin halt nicht so wirklich begeistert, dass jetzt irgendwie versucht wird, das zu reparieren, was ich vielleicht eher jetzt nicht für kaputt befinde.
Aber im jetzigen Zustand halt echt eingeschränkt sehen würde auf einen bestimmten Use Case, mach doch mal lieber diese primitiven Barrieren. vielleicht eher was.
Peter, du als alter Internet-Technologie-Philosoph solltest öfters mal beim W3C vorbeischauen und GitHub-Issues rumkommentieren.

[1:10:32] Hey, ich mach das mehr als früher. Mhm.
Früher hab ich ja bloß bei den HTML5-Spezifikationen die Tippfehler repariert.
Aber jetzt, wie gesagt, hab ich ja schon mal erzählt, bin ich ja stolzer Contributor zum Decorators Proposal.
Indem ich irgendwas so falsch verstanden habe, dass ein Bubblebug zutage getreten ist, der zutage gebracht hat, dass in der Spezifikation irgendwas nicht richtig formuliert ist.
Stimmt, hast du in der TypeScript 5.2-Folge mit Stefan erzählt.
Ja, ich weiß gar nicht, ob das im Hauptteil oder in der Post-Credit-Sequence drin war.
Weiß ich auch nicht, ja. Ich find das krass, du hörst ja diese Folge, das hört sich an, als hätten wir eine Sendung draufgenommen.
Ah ja, ich mein, das haben wir ja heute auch, ne?
Also, wir wollten ja eigentlich über Neues in HTML Teil 3 sprechen.
Ja, muss ja keiner wissen.
Nö, muss keiner wissen. Nee, ist ja auch in Ordnung. Ist ja eine coole Folge.
Ich hab das auch umbenannt jetzt.
Einfach mal den Titel in Events und, äh, Shadow Dom Smell.

[1:11:34] Mmh, Shadow Dom Smell, ja. Naja, also eins sag ich dir, wo auf jeden Fall für Shadow Root gut ist.
Ich hab einfach mal gegoogelt nach so Black-Metal-Fonts. Und ich werde mir jetzt ein schwarzes T-Shirt machen, auf dem einfach nur draufsteht in so einer entsprechenden Bandschrift, Shadowroot.
Ja, geil. Lass uns doch hier, wir müssten doch eh mal hier vor dem Podcast so einen Spreadshirt-Shop machen oder so was.
Vielleicht machen wir das in dem Kontext einfach.

[1:12:02] Wir sind aber, glaub ich, als Podcast nicht albern genug, als dass wir schon viele Catchphrases so hätten, die man da draufdrucken kann. weil du willst doch eigentlich so einen Wiedererkennungswert da drin haben.
Nicht einfach nur unser extrem schönes Logo. Meinst du, bei Spreadshot machen sie diese Farbe?

[1:12:23] Meinst du hier die Working Draft lila Farbe oder was? Ja.
Du kannst alle Farben hinschicken, also ist kein Problem. Also ob das dann am Ende, ob dein CMYK-Dokument dann im Druck exakt so rauskommt, wie du das denkst, das steht ja immer auf einem anderen Blatt geschrieben.
Okay, also T-Shirt-Design will ich auf jeden Fall haben. Einfach ein T-Shirt in der Farbe mit dem Logo drauf und dann irgendwie so Sternchen, Einhörner drumherum. tatsächlich ein harmonisches Gesamtbild geben, Punkt, ja.
Da kannst du ja auch mit Journey mal fragen, dass sie dir das ganze Zeugstum rumbaut.
Ja, ich glaub, das krieg ich noch selber hin.
Da brauch ich keinen ... äh ...
Außerdem muss man dafür nicht irgendwie nach Discord rein oder so? Ja, muss man.
Dann lassen Sie mich nicht rein, ich bin zu alt dafür. Oh, ich hab so einen Paid-Account, falls das hilft.
Den wollte ich eigentlich auch wieder kündigen. Genau, den kann man auf jeden Fall, könnten wir nochmal abfackeln.
Ja cool, sollen wir denn dann einfach die, den dritten Teil von Neuss und HTML ein andermal machen? Ja, würde ich vorschlagen. Ich glaube, wir haben jetzt eine Sendung beisammen.
Alles klar, dann danke fürs Zuhören. Bis dann. Tschüss.

[1:13:38] Music.