Anmelden

Working Draft· Folge 735

Revision 735: Glücksrad mit Custom States, Foreign Objects und toten HTML-Elementen

Dienstag, 27. Oktober 2026 · 1 h 17

MP3

Shownotes

Wir holen nach längerer Pause wieder das klassische Working Draft Webtechnologie-Glücksrad (workingdraft.de/gluecksrad) hervor. Der Zufallsgenerator serviert uns Webstandards aus HTML, CSS, JavaScript und Browser-APIs, zu denen wir uns ohne Vorbereitung etwas Sinnvolles zusammenreimen müssen.

Diesmal landen wir unter anderem bei Service Workern als ES Modules, Custom States und Shadow-DOM-Styling, Iteratoren, SVG und foreignObject, parametrisierten SVGs sowie einem Stück HTML-Archäologie rund um <cite> und das längst verblichene <blink>.

Unser Sponsor

mittwald.de/workingdraft?ref=workingdraft.de

Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft?ref=workingdraft.de

Shownotes

[] ServiceWorkerGlobalScope und ES Modules (developer.mozilla.org/en-US/docs/Web/API/Servi…)
Das erste Thema führt uns zu Service Workern und der Möglichkeit, sie als ECMAScript-Module zu registrieren. Gegenüber importScripts() bekommen wir damit die gewohnte Modulsemantik mit import und export, eigenem Scope und Strict Mode. Wir sprechen darüber, warum das auch jenseits der Syntax angenehm ist: Utilities können in Webseite und Worker nach demselben Modulmodell organisiert werden und wir müssen weniger zwischen zwei leicht unterschiedlichen JavaScript-Welten umdenken. Der eigentliche ServiceWorkerGlobalScope ist dabei grob das Gegenstück zu window im Service Worker und stellt unter anderem Worker-spezifische APIs bereit.
[] moveBefore() und zustandserhaltendes Verschieben (developer.mozilla.org/en-US/docs/Web/API/Eleme…)
Von globalen Objekten kommen wir zu Schepps Praxis, vorhandene DOM-APIs zu patchen. Anlass ist moveBefore(), mit dem Elemente im DOM verschoben werden können, ohne ihren Zustand durch ein Entfernen und erneutes Einfügen zu verlieren. Bei Custom Elements hat das Konsequenzen für die Lifecycle-Callbacks: Ein zustandserhaltendes Verschieben verhält sich anders als das klassische Disconnect-und-Reconnect und bringt dafür den connectedMoveCallback() ins Spiel.
[] Custom States mit :state() (developer.mozilla.org/en-US/docs/Web/CSS/Refer…)
Mit :state() können Custom Elements eigene Zustände nach außen für CSS sichtbar machen. Über attachInternals() und die Custom-State-API lässt sich beispielsweise ein eigener Open-, Closed- oder Disabled-artiger Zustand definieren, auf den Styles anschließend mit :state(...) reagieren. Wir vergleichen das mit eingebauten Zuständen nativer Elemente und diskutieren einen Haken: Wird der Zustand erst durch später ausgeführtes JavaScript hergestellt, kann es zu sichtbarem Flackern kommen. Für einen Dark-Mode-Schalter kann deshalb ein bereits beim Parsen vorhandenes Attribut die robustere Single Source of Truth sein.
[] JavaScript Iteration Protocols (developer.mozilla.org/en-US/docs/Web/JavaScrip…)
Die Iterationsprotokolle haben wir zwar schon früher erwischt, bekommen diesmal aber einen schönen realen Anwendungsfall geliefert: Eine paginierte Web-API lässt sich als asynchroner Iterator modellieren, sodass Konsumenten mit for await...of Seite für Seite abarbeiten können, ohne eine getAll()-Funktion anzubieten, die zwangsläufig sämtliche Daten lädt. Wer tiefer einsteigen möchte, findet das Thema ausführlicher in unserer alten Iteration 323: (Asynchrone) Iteratoren (workingdraft.de/323) aus dem Jahr 2017.
[] developer.mozilla.org/en-US/docs/Web/HTML/Refe…
Mit part lassen sich Teile eines Shadow DOM gezielt für Styling von außen freigeben. exportparts setzt noch eine Ebene darauf: Enthält eine Web Component weitere Web Components in ihrem Shadow DOM, kann sie deren Parts durch die eigene Shadow-DOM-Grenze hindurch weiterreichen und dabei auch umbenennen. Damit lassen sich verschachtelte Komponenten von außen stylen, ohne die Kapselung vollständig aufzugeben. Wir diskutieren aber auch, ob gröber geschnittene Web Components viele dieser Probleme von vornherein vermeiden können.
[] SVG foreignObject (developer.mozilla.org/en-US/docs/Web/SVG/Refer…)
<foreignObject> erlaubt es, Inhalte aus einem anderen XML-Namespace in SVG einzubetten, insbesondere HTML. Daraus ergeben sich einige interessante Anwendungen. Wir sprechen über das Rendern eines DOM-Ausschnitts über SVG und Canvas als Screenshot, über HTML als Ausweg aus dem unbequemen Textlayout von SVG und über die Frage, wie weit sich unterschiedliche Dokumenttypen ineinander verschachteln lassen. Bei inline eingebettetem SVG lässt sich das HTML innerhalb eines foreignObject außerdem abhängig von Klassen des umgebenden SVG stylen. Ist das SVG dagegen als externe Bilddatei eingebunden, stehen solche Beziehungen nicht auf dieselbe Weise zur Verfügung.
[] Screen Capture API (developer.mozilla.org/en-US/docs/Web/API/Scree…)
Vom Screenshot-Hack mit foreignObject kommen wir kurz zur Screen Capture API und getDisplayMedia(). Dabei schauen wir uns die Unterschiede beim Browser-Support an und stellen fest, dass sich insbesondere die feineren Möglichkeiten zur Auswahl und Aufnahme einzelner Fenster, Tabs und Audioquellen zwischen den Browsern unterscheiden.
[] CSS link-parameters (developer.mozilla.org/en-US/docs/Web/CSS/Refer…)
Für extern eingebundene SVGs könnte link-parameters künftig eine interessante Brücke bilden. Die CSS-Eigenschaft erlaubt es, Parameter an verlinkte Ressourcen zu übergeben. Im Ziel lassen sich diese Werte über env() (developer.mozilla.org/en-US/docs/Web/CSS/Refer…) wieder auslesen. Damit könnte dasselbe SVG beispielsweise mit unterschiedlichen Farben parametrisiert werden, ohne dafür verschiedene Dateien zu erzeugen. Wir überlegen weiter, ob sich Änderungen solcher Parameter innerhalb des SVG auch mit CSS Transitions kombinieren lassen und ob die Werte bis in HTML innerhalb eines foreignObject durchgereicht werden könnten.
[] Das <cite>-Element (developer.mozilla.org/en-US/docs/Web/HTML/Refe…)
Zum Abschluss beschert uns das Glücksrad HTML-Archäologie. <cite> zeichnet nicht das Zitat selbst aus, sondern die Referenz auf das zitierte Werk. Ein längeres Zitat gehört beispielsweise in ein <blockquote> (developer.mozilla.org/en-US/docs/Web/HTML/Refe…), während <cite> dessen Quelle benennen kann. Wir verfolgen das Element zurück bis HTML 2.0 und stellen dabei fest, wie schwer bei solch alten Features überhaupt sinnvoll zu bestimmen ist, ab wann ein Browser sie „unterstützt“.
[] Das nicht existente blink-Element (developer.mozilla.org/en-US/docs/Glossary/blin…)
Von <cite> geraten wir zum abgeschafften <blink>. Moderne Browser behandeln es wie ein unbekanntes Element, gleichzeitig erwähnt der HTML-Standard solche historischen Elemente ausdrücklich als nicht zu verwendende Elemente. Das führt uns zu der etwas philosophischen Frage, was es technisch eigentlich bedeutet, dass ein HTML-Element „nicht existiert“, wenn Parser und Entwicklerwerkzeuge dennoch besondere Regeln für seinen Namen kennen. Die Entstehungsgeschichte von <blink> (web.archive.org/web/20220331020029/http://www.…) liefert dazu noch die passende Webhistorie: Die Idee entstand laut Lou Montulli bei einer Unterhaltung in einer Bar und wurde anschließend über Nacht implementiert.

Links

Fronteers Dark Mode …

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Funfact am Rande natürlich, also für die Trolls unter uns, Global This, auch nur ein variabler Name. Also kann man genauso shadowen wie so Spaß wie Undefined Infinity oder ähnliches. Niemand hält einen davon abzuschreiben, let Global This gleich 42. Nicht schön. Doch, das macht das Leben erst interessant. Text-Layouten in SVG ist Pain in the Ass. Ist es tatsächlich ja auch. Du hast ja keine Umbrüche und nix.

Das ist eine Verschwörungstheorie und die wollen uns einreden, das Element würde nicht mehr existieren und indem sie das behaupten, wird es nur noch deutlicher für mich, dass das da ist. Das ist quasi das Blitzdings der HTML-Spezifikation. Revision 735. Wir sind heute zu zweit. Da hätten wir aus dem Team den Peter.

Hallo Peter. Moin, moin. Und ich bin der Shep und wir haben keinen Gast und wollen nach langer Zeit mal wieder ein wenig Glücksrad spielen. Und zwar nicht Accessibility-Glücksrad, was wir ja ein paar Mal mit einem Stammgast-Team gemacht haben, sondern das andere, das wir früher immer gemacht haben. Glücksrad Classic.

Glücksrad Classic, genau. Und die Katze will auch mitmachen. Ja, Stecki kam gerade wieder rein und Tobi muss dann natürlich erst mal das große Begrüßungsgeschrei anstimmen. Okay, ich dachte, die wäre mit so einem. Griff, mit Haken, und hätte die Katze dann so da rausgezogen aus dem Raum. Nee, nee, nee, das ist einfach das normale Prozedere. Diese Tonlage gibt es halt in so genau zwei Anlässen am Tag. A, jemand kommt durch diese Tür rein.

Fütterung kommt so drauf an, das geht. Wenn man die richtigen Handgriffe in der richtigen Reihenfolge macht und der Herr weiß, die Routine wird normal abgespult, dann gibt es keinen Grund, sich zu verausgaben. Aber zur Begrüßung wird es halt eben angesetzt. Und es ist natürlich so, der Herr, der ja als Ragdoll-Katze noch nie das draußen gesehen hat, hat irgendwann...

Unklar woher, gelernt, dass man Mäuse, im Sinne von Spielmäuse, fangen und dann den Dosenöffnern zum Geschenk machen kann. Ja, das stimmt. Habe ich auch schon mal bekommen, man hat mir sogar eine tote Maus in mein Bett beim Schlafen gelegt. Und ich dachte, das wäre ein Traum und habe die so weggeworfen.

Und dachte so, ja, das war ja echt ein komischer Traum. Am nächsten Tag gucke ich so, liegt die dann wirklich da auf dem Teppich. Okay, aber das kann ich ja noch verstehen, weil das ist ja irgendwie draußen so, die Maus ist echt. Das kann man dann ja auch irgendwie von anderen Katzen sich vielleicht abgeschaut haben, aber der Kollege hier mit seinem Stammbaum, der im Kreis ist, keine Chance, der hat halt irgendwann wirklich erst vor ein paar Jahren, da war der schon ewig hier, damit angefangen und das Problem ist halt wirklich, man liegt im Bett, man ist schon halb am schlafen und dann kriegt das halt eben hin, diese Maus so in Bettnähe zu tragen und dabei halt eben auch zu jaulen wie am Spieß und wenn man nicht hingeht und ihn dafür lobt, was er tolles gefangen

hat, dann hört er auch nicht auf. Und das verstärkt das Verhalten. Und jetzt ist es halt wirklich so, wir kriegen jedes Mal Plastikmüll angeschleppt. Jetzt ist halt die Frage, echter Kadaver versus Plastikmüll. Was ist besser, was ist schlechter? Weiß ich nicht. Ja, auf jeden Fall nervig. Ja, da machst du nix.

Tja, machst du nix. Ist ja auch ganz lustig, wenn es nicht gerade Nacht ist. Wenn man nicht gerade schlafen will. Ja, und das ist ja, wenn man schlafen möchte. Oder wenn man in der Dusche steht, auch sehr gerne genommen. Machst du nix. So, aber wir spielen heute klassisches Glücksrot. Ja. Das heißt, nochmal erklärt für diejenigen, die hier zum ersten Mal zuhören, wir haben ja einen Zufallszahlen, äh, nee, einen Zufallszahlen, einen Zufallsgenerator, der grasst Lab-Standards ab, spuckt uns irgendwas aus, das kann CSS sein, das kann JavaScript sein, das kann HTML-Tag sein und dann müssen wir ad hoc dazu irgendwas Schlaues sagen.

Und da wir die Vorbesprechung damit verbracht haben, darüber nachzudenken, wie man am besten Dinge ausdrucken kann, sind wir definitiv hier, dass die Kompetenzzentrale 2026 halt. Es ist so, wir haben wirklich unsere Ansätze verglichen, wie man am besten was ausdruckt. Und wir konnten uns nicht entscheiden, ob Dokument per WhatsApp zu schicken an die eine Person, bei der das Drucken funktioniert oder Screenshots ausdrucken die bessere Variante ist. Man weiß es nicht. Ja.

Bring back Diskette. Tipps gerne in unseren Kommentaren. Bring back Diskette, sag ich. Ja, und ZipDrive. Ja, und hier, LTT-Port, ne, für Drucken per Kabel. Ja, stimmt. Ja, Parallelport, ne, Parallelport. Ich hab, ich bin, ich bin zu jung dafür. Du hast FTP-Port gesagt, oder? Kann das sein? LTP, ist das nicht der Drucker? Ja, das stimmt, LTP war das, ja, genau. Ja.

Okay, ich bin doch nicht jung. Komm, lass uns mal auf den Zufallszahlen generieren. Ja, willst du drücken? Ich drücke jetzt einfach mal als Erster, was kann schon schief gehen. Wir haben den Service Worker Global Scope am Start. Hey, da fällt mir tatsächlich was zu ein. Und zwar ist das ein Thema, das wir bei unserer letzten Revision ausgelassen hatten.

Da gab es ja die Neuerung, die da eingeführt wurde. Da weiß ich jetzt nicht, was der Browser Support ist. Aber offenbar ist es so, dass im Kommen ist, dass wir tatsächlich Module für Service Worker bekommen. Da gab es ja bei dem ServiceWorker Instanzierungs-Function-Call, an den ich mich nicht mehr genau erinnere, tatsächlich ja, die Option, dass man sagen konnte, jawohl, das ist jetzt ein ECMAScript-Modul, und dadurch kriegt man dann halt eben tatsächlich ECMAScript-Modul-Semantik, in ServiceWorkern und kann halt eben dann so Sachen machen wie Import-Export, Default-Strict-Mode, vernünftiges Scoping, den ganzen Spaß.

Genau, kurze Frage noch, man kann ja Import-Scripts machen, warum würde man das bevorzugen in dem Fall, weil man mit irgendwie Third-Party arbeitet, das in ES-Modules aufgegliedert ist, oder gibt es da noch andere Argumente dafür? Das ist ein Argument, aber generell ist so, Import-Scripts ist gleichbedeutend mit einem Script-Tag in HTML, ohne Type-Module dran.

Und würdest du in deinem HTML-Dokument ein normales Script-Tag verwenden, ohne Type-Module dran, wahrscheinlich nur unter sehr ausgesuchten Umständen. Also, kommt drauf an. Also, ich meine, das Problem ist ja, dass das, ja, also, warum, also, was spreche ich dagegen? Also, was dagegen spricht, vielerlei. Das Erste ist erstmal, also, ich sage immer so, wenn ich meinen Leuten irgendwie beibringe, warum man Module verwenden sollte, statt Scripts.

Da ist natürlich das, was jetzt im Service Worker nicht wichtig ist, aber in HTML sehr wichtig ist, die Script-Type-Module blockieren nicht den HTML-Parser, sondern sind eingebaut asynchron und das ist ja tendenziell eher gut. Genau, aber kannst du ja auch so haben, ne? Mit Async oder Differ. Genau, das kann man halt eben haben. Da kann man per Opt-in rein und das würde halt eben dieses eine spezifische Problem lösen.

Und dieses Problem besteht beim Service Worker tatsächlich nicht, weil es ja nicht im HTML-Barser... Genau, da blockiert ja keinen Renderer. Exakt, das ist also gar kein Problem. Das kann man also außen vor lassen. Dann haben wir aber natürlich in Modulen den etwas sinnvolleren Scoping-Mechanismus, dass die Module alle tatsächlich einen eigenen Variablen-Gültigkeitsbereich darstellen und nur das, was exportiert wird, tatsächlich auch von außen erreichbar ist.

Und weil halt Import-Scripts tatsächlich im Prinzip ein Script-Tag, aber programmatisch ist, bedeutet das natürlich auch, dass alle Variablen, die da drin in Anführungszeichen public sind, public werden für die importierende Partei. Was okay sein kann, was aber auch zum Problem werden kann und was man vielleicht einfach ausschließen möchte.

Okay, also einfach ein bisschen die Bude ein bisschen sauberer halten. Genau, und dazu kommt natürlich auch der Strict-Mode. Module immer im Strict-Mode, Scripts halt nicht. Man kann sein Script in den Strict-Mode versetzen, aber warum würde man sich außerhalb des Strict-Modes bewegen wollen im Jahre des Jahres 2026?

Gibt nicht wirklich viele Argumente, also nimmt man doch Module, dann ist man im Strict-Mode. Auch easy. Und dann kommt natürlich dieses ganze Import-Export-Zeug, das natürlich in Abwesenheit von irgendwelchen primitivistischen Modul-Bundlern, auch noch den Vorteil hat, dass das natürlich auch dem ECMAScript-Modul-Resolution-Mechanismus folgt.

Und am Ende ist es ja so, der Browser baut sich im Prinzip einen Key-Value-Store und sorgt dafür, dass jedes Modul, das man importiert, nicht nur einmal nur geladen, sondern auch tatsächlich nur einmal evaluiert wird. Und das kann am Ende tatsächlich, wenn man irgendwie Utilities hat, die in der Webseite gebraucht werden, wie auch ein Service-Worker, tatsächlich zu Performance-Benefits führen, weil man sich Downloads erspart und auch die Ausführung erspart.

Das heißt quasi, der Browser kann das auch quasi für den Main-Thread und den Service-Worker-Thread quasi. Also der spart sich da auch Arbeit, wenn beide zum Beispiel das gleiche Modul importieren. Exakt. Wenn es halt der exakt gleiche Pfad ist, der gleiche Modul-Identifier ist, dann wird halt sich das, und das ist halt wichtig zu sagen, nicht nur das Laden erspart man sich, weil das könnte man ja mit Caching auch mit dem Script-Tag hinkriegen, aber es wird sich vor allen Dingen das Evaluieren erspart und so groß wie heutzutage die JavaScript-Payloads sind, ist das vielleicht nicht die schlechteste Idee.

Okay. Und das sind so die Headline-Features. Außerdem ist es natürlich so, die Unterschiede sind nur klein. Okay, klar. Aber ich gehe mal davon aus, dass die meisten tatsächlich in der Modulwelt heutzutage primär unterwegs sind. Und wenn man halt noch so den Service-Worker oder den generellen Web-Worker, also die eine Ausnahmesituation hat, wo man die gleiche Programmiersprache betreibt, aber viele Semantiken halt so dezent anders sind, ist das halt einfach ein mentaler Overhead, den man sich ersparen kann.

Man kann Utilities schreiben, die man in beiden Welten gleich verwenden kann. Man muss nicht irgendwie Cross-Compilation machen, damit das eine Modul-Syntax hat und das andere nicht. Es macht einfach alles ein bisschen einfacher und stopft halt so ein Loch. Rettet jetzt niemanden akut, aber ist halt besser als Import-Scripts.

Ja, ist so ein bisschen Polish und also gut einfach, ja. Ja, und ich meine, ich sage den Leuten ja schon immer, vergesst einfach, dass es Classic-Scripts gibt. Nehmt einfach Script-Type-Module als die einzig wahre Syntax und vergesst den Rest. Und das war bisher halt nie richtig, weil es halt immer noch so diese Grenzfälle gab, wie irgendwie so Legacy-Node-Module, die halt nur mit Gehackse in so ein ECMAScript einzubauen waren oder eben Worker.

Und wenn das jetzt weg ist, dann ist das, was ich schon seit Jahren sage, irgendwann endlich mal wahr und das ist nicht schlecht. Okay, und jetzt haben wir aber hier erwürfelt Service Worker Global Scope. Gibt es schon länger? Also ist jetzt nichts Neues? Nee, das ist quasi das Window-Objekt vom Worker.

Okay. Mehr ist es eigentlich nicht. Und halt eben die APIs, die da drauf wohnen, da gibt es ja so diverse, also APIs, auf die man einfach so Zugriff hat, wie zum Beispiel Fetch. Das gibt es im Worker, logischerweise. Das gibt es im Main-Thread auch. Und von daher gibt mir, es gibt ein paar Worker-spezifische APIs, wie so Krempel, der dann mit Notifications und Background-Sync und ähnlichem zu tun hat. Die gibt es dann halt eben nur im Worker.

Und andere Dinge gibt es halt auf dem Window, die im Worker nicht existieren, wie irgendwie DOM-Gewinsel. Und gab es, hier ist das nicht, gibt es nicht irgendwie, ist das nicht auch irgendwie global oder so, dass das irgendwie in, dass man mit global irgendwie beide, oder, ja, oder ist das... Du meinst Global This wahrscheinlich? Global This, ja, genau.

Genau, wenn du halt wirklich dein Cross-Scope-Utility-Tool bauen willst, kannst du da drin ja weder verwenden. Self, was man per Konvention einfach üblicherweise im Webworker verwendet hat, oder Window, was es halt eben im Worker nicht gibt, sondern im Browser, kannst du Global This verwenden und dann hast du relativ gute Chancen, dass du das globale Objekt jeweils da rausbekommst, was du halt vor allen Dingen brauchst, wenn du eine globale Variable anlegen willst, oder auf eine globale API zugreifen willst, die geshadowed ist, ja.

Ja, okay. Fun Fact am Rande natürlich, also für die Trolls unter uns, Global This auch nur ein Variable-Name. Also kann man genauso shadowen wie, so Spaß wie Undefined Infinity oder ähnliches. Niemand hält einen davon abzuschreiben, let Global This gleich 42. Nicht schön. Doch, das macht das Leben erst interessant. Ja, das stimmt. Naja, ich patch ja auch gerne manchmal Sachen, die es im Browser gibt. Zum Beispiel?

Ach, hatten wir ja letztens schon mal so. Ich habe zum Beispiel das Letzte, was ich gepatcht habe, war, ich habe nicht gerade, das Letzte, was ich gepatcht hatte, war diese DOM-APIs, die quasi, wenn die ein Element woanders hinbewegen, dann war ja das ja früher so, dass die das abgerissen haben an einer Stelle und wieder dran gebaut haben an anderer und dann war es aber ein neues Element und jetzt kannst du das ja moven und, weil es halt Third-Party gibt, die das noch nicht weiß, habe ich das dann gepatcht, sodass quasi hintenrum das Move benutzt wird.

So was. Das sind so meine Sachen, die ich mache. Also es gab Third-Party-Sachen, die hätten Move benutzen sollen, aber die wurden halt von Leuten entwickelt, die nicht wussten, dass es das gibt. Und aus einer Zeit entwickelt, wo es das noch nicht gab im Browser. Okay, gut. Gut. Ja, so Sachen. Ja. Okay. Also es ist natürlich nicht unriskant, das.

Weil was du ja machen kannst, ist zum Beispiel eine Web-Component bauen und die Lifecycle-Callbacks haben tatsächlich spezifisch den Connected-Callback. Naja, wenn die nicht darauf ausgelegt sind, meinst du, ne? Naja, was heißt nicht darauf ausgelegt? Also weil die ja nicht neu connecten, also musst du ja quasi diesen neuen Lifecycle-Hook verwenden.

Wir haben darüber irgendwann mal gesprochen. Und wenn die sie nicht haben, dann sind die kaputt. Das kommt halt drauf an, die sind nicht notwendigerweise kaputt, kaputt. Also ich meine, man muss ja davon ausgehen, wenn ich so eine Web-Component entwickle, dass ich tatsächlich benutzt werde von Honks.

Man kann nicht davon ausgehen, dass ich einen Shep habe und entsprechend muss ich natürlich trotzdem halt eben Connection und Disconnection-Logik haben. Aber ich will nur sagen, der Effekt könnte halt ein beobachtbarer sein. Ist halt so die gleiche Kiste wie machst du deinen Web Component Tag und dann das Script, das blockierende Script in dem Fall, oder erst das Script und dann das HTML Tag zum ersten Mal.

Führt ja beides am Ende dazu, dass du die Komponente kriegst, aber es gibt halt eben an den Ecken beobachtbare Veränderungen und das muss man halt irgendwie auf dem Schirm haben. Aber ich gehe natürlich davon aus, dass du das testest und oder so neumodischen Blödsinn wie Web Components gar nicht erst am Start hast.

Das ist korrekt. So sieht es aber aus. Genau, wie war das denn hier? Connected Move Callback war es. Genau. Genau, das kann ich ja mal hier dann auch verlinken. Ja, ist auch ein Supername für diese... Diese Web-Component-APIs sind echt super. Wenn man wirklich so richtigen OOP-Entwicklerinnen und Entwicklern das Gehirn schmelzen möchte, zeigt man denen einfach, wie so ein Web-Component aufgebaut ist und fragt dann so, wo ist jetzt dein, Private-Protected-Public-Gott jetzt?

Ja. Also Connected-Move muss Public sein, aber wird niemals von irgendwas aufgerufen, was nicht privilegiert ist, aber nicht in der Fairbox-Hierarchie drin ist. Also ist es Public, aber Protected nur halt eben nicht, sondern was anderes. Das ist super. Ja, schön weird. Ich drücke. Jo, drück mal. Aha. Ah, super. Das gefällt dir, glaube ich. Natürlich, Web Component Blödsinn, neumodischer Kram, den Shep niemals einsetzen würde.

Ja, nee, also sagen wir mal so, ich glaube, ist das nicht schon eher nicht nur Web Component, sondern so geht es nicht schon so ein bisschen in Richtung Shadow DOM oder sowas? Nee, weder noch. Das ist so ein zweimaliger nicht. Also wir müssen da sagen, wir haben die Pseudoklasse Doppelung State oder Pseudoklassen Funktion, Function, Doppelung State, Klammer auf, Klammer zu.

Genau, die State-Pseudo-Klasse für Custom-States. Gesetzt im Custom-State-Set. Und bevor ich jetzt Blödsinn rede, muss ich mir eben kurz etwas live kurz suchen. Ich sag kurz, was ich noch weiß. Das ist ja, dass du quasi einfach in einem Custom-Element ein Stage. So was wie Dialog, und er hat ja diese Open-Pseudo-Klasse, wenn er halt offen ist.

Und so kannst du quasi eigene States definieren und dann kann man die mit CSS über diese State-Pseudo-Klasse eben stylen, indem man dann, den Identifier, den du dir eben für diesen State überlegt hast, dann in diese Funktion reingibt. Exakt. Bestens erklärt. Wer hätte es nicht besser machen können, genau dafür ist es. Meine Custom-Element hat irgendwie einen Zustand.

OpenClose oder RedGreen, was auch immer. Und dann, ja, ist das einfach ein State, den man setzt in Form von einer SetAPI. Und mit der Pseudoklasse kann man halt eben dann CSS schreiben, das darauf anspringt, ob das Element dann in diesem oder jenem State ist und kann halt eben dann entsprechend sich stylen.

Ich bin dann irgendwie in einem selbstgestrickten Disabled State oder ähnliches. Das klappt damit ganz hervorragend. Und ich habe jetzt nochmal genau recherchiert bis runter in die Spezifikationen. Das, was du sagtest, stimmt halt doch. Es ist Custom-Element-spezifisch. Das hat nichts mit dem Shadow-Dom zu tun.

Der Mechanismus, wie das funktioniert. Es gibt eine Methode auf dem HTML-Element. Das ist Attach-Internals. Damit kriegt man ein Objekt zurück, das enthält die Internals-APIs und das sind im Prinzip JavaScript-APIs für Features, die HTML-Elemente früher immer nur intern hatten, mit so Sachen wie, ich setze all solche States zum Beispiel.

Und im Prinzip ist das eine JavaScript-API, um interne Dinge zu kontrollieren. Andere Beispiele wären so Sachen wie, ich baue mir mit Custom-Elements ein Formularelement und ich muss meinen Form-State setzen, der am Ende dann submitted wird. Wenn auch beim Formular auf Senden geklickt wird, macht man auch über diese API.

Und ich habe mir gerade noch mal genau die Spezifikation angeschaut und die sagt halt eben auch, wenn diese Methode aufgerufen wird auf einem Element, das nicht zu einem Custom-Element gehört, dann gibt es eine DOM-Exception. Das heißt, obwohl die API verfügbar ist auf HTML-Element, wenn ich mich nicht täusche, ist es halt trotzdem so, man kann sie halt nur verwenden auf Custom-Elements. Ja.

Okay. Ja, und das Feature ist prima. halt eben für genau so Styling-Kisten, Open-Closed und sowas alles, hat halt nur ein Problem. Shep, kannst du es ahnen? Also Browser-Support ist es wahrscheinlich nicht, weil den gibt es wohl seit Mai 2024 schon. Ja, mittlerweile können im Übrigen auch so die CSS-Tooling-Geschichten, die ja generell auch von irgendwelchen rückwärtsgewandten Steinzeitmenschen entwickelt werden, das, also lange Jahre war das so, dass die sich an der Syntax komplett verschluckt hatten, weil, was?

Einmal nie gesehen, geht ja gar nicht. Aber mittlerweile sind die auch nicht mehr das Problem. Ja, gut. Die haben, glaube ich, aber auch bei CSS mittlerweile ganz schön viel zu tun, irgendwie Schritt zu halten mit allem, was an Rules und Selektoren und so möglich ist. Die kriegen das mit JavaScript hin, dann kriegen sie es mit CSS auch hin.

Ist CSS nicht eigentlich eh dieser Vibes-Kram, der weg abstrahiert werden soll und richtige Programmierer prompten, damit JavaScript rauskommt? Komm, komm. Das weiß ich nicht, ich weiß es nicht, ich bin unsicher. Das unterstelle ich denen ja seit jeher, diesen ganzen Compiler-Freeze. Ja, nee, aber... Nee, weiß ich nicht, ja. Flash of Unstyled Content.

Weil der State noch nicht sofort gesetzt ist. Exakt, exakt. Du hast gegebenenfalls JavaScript, das halt irgendwann später erst ausgeführt wird. Vielleicht von einem Modul, weil es ja Asynfon. Ja, genau, wollte ich gerade sagen. Exakt, exakt. Und dann befindest du dich halt in der Situation, dass. Deine Seite irgendwie schon halb da ist, dass JavaScript, egal wie schnell du bist, versucht nochmal eben schnell da irgendwie sich was zu erarbeiten.

Aber das kann halt eben tatsächlich einen ganz gewaltigen Unterschied machen. Bestes Beispiel, das ich gerne dafür nehme, ist, das Use Case von der Web Component ist zum Beispiel so ein Dark Mode Toggle und da wäre ja super, wenn man da so ein State Selector hätte für ist light oder ist dark. Ja. Das Problem ist halt, wenn erst, wenn die Seite schon halt fertig geladen ist, irgendwann das JavaScript merkt, dass es halt diesen State hätte instanziieren müssen und deshalb plötzlich ein CSS merkt, dass es im komplett falschen Mode ist, dann flackert es halt und sieht doof aus.

Genau, aber gibt es nicht die Möglichkeit, auch wenn so ein Custom-Element noch nicht initialisiert ist, gibt es auch eine Pseudo-Klasse dafür, oder? Gibt es nicht eine? Ja, es gibt die Pseudoklassen Defined und Not Defined aber das hilft dir ja in dem Fall nicht, weil du musst dich ja beim Laden der Seite entscheiden, bin ich jetzt im Dark Mode oder im Light Mode und wenn die Wahrheit darüber in einem Element wohnt, das halt irgendwann später erst geladen wird ist ja die Information ich weiß noch nicht welcher Mode es wird, bis das den geladen ist, ja nicht wirklich hilfreich, weil du musst ja irgendwie entscheiden, was nehme ich denn jetzt als Hintergrundfarbe Okay, das Element selber steuert dann auch, also das,

ist nicht nur da zum irgendwie, Local Storage Wert zu setzen und anzuzeigen und den Knopf dahin zu schieben, wo es gerade eingestellt ist, sondern es steuert auch tatsächlich dann ob das Light Scheme gerade aktiv ist oder nicht und dann ist das natürlich so. Single Source of Truth hielte ich für sinnvoll, weil dann kannst du halt sowas schreiben wie Root Element has Dark Mode Toggle im State so und so.

Ja, okay. Dann setzt du die CSS-Bariable. Ich glaube, mit Has kannst du keine Pseudo-Klassen, nee, du kannst keine Pseudo-Elemente, glaube ich. Nee, Pseudo-Klassen sollte geben. Pseudo-Klassen geben, Pseudo-Elemente geht nicht. Ja, das ist dann natürlich, genau, das funktioniert dann nicht. Das ist doof.

Ja, also doch, lieber eine Checkbox nehmen. Naja, nee, was ich halt bei meinem Dark Mode Selector gemacht habe, ich habe halt einfach das Mode-Attribut so gemacht wie das Disabled-Attribut auf einem Input, dass halt eben, wenn diese DOM-Property sich setzt, halt eben manifestiert sich auch ein Content-Attribut und umgekehrt.

Das ist einfach ein Bullshit-Attribut. und das kann ich ja tatsächlich mit so einem Document Current Script Tag tatsächlich während der HTML-Parser das Element baut da schon mal reinschreiben, das hat dann erstmal keine Bedeutung, aber für den CSS-Elektor für meine Root Has und so weiter funktioniert es halt eben trotzdem.

Ja. Das ist glaube ich ein Edge-Case und ich glaube im Normalfall ist State ganz nett, weil das ist halt eben, wie du schon sagtest, ganz zu Beginn der Open State des kleinen Mannes und das kennen die Entwicklerinnen und Entwickler und dann geht's ab dafür und ist easy. Cool, cool. Diese Revision von Working Draft wird euch präsentiert von CodeTalks.

Dass ich ein Developer-Konferenz-Feinschmecker bin, überrascht wahrscheinlich niemanden, der diesen Podcast abonniert hat. Aber es muss dann auch passen. Eine Mikrokonferenz, die sich anfühlt wie ein Firmenseminar, kann mir genauso gestohlen bleiben wie die XXL-Messe mit Zehntausenden, wo dann die Hälfte der Talks eh nur Werbung ist.

Wie wäre es stattdessen mit einer inhaltlich wertvollen Konferenz im größtentechnischen Sweetspot? Ich würde euch hierfür gerne die Code Talks in Hamburg ans Herz legen. 4. und 5. November. 3.500 echte Entwicklerinnen und Entwickler. Über 100 Talks auf 14 Tracks, aber auf der Bühne Inhalte statt Produktpitches.

Ihr pflanzt euch in Kinosessel, Popcorn-Flatrate inklusive, zieht euch das Neueste von AI über Security bis Frontend rein und macht am Abend Party auf der Repa-Bahn. All das ist in eurem Konferenz-Ticket enthalten und an diesem Ticket könnt ihr jetzt sogar sparen. Denn mit dem Code WORKINGDRAFT15 gibt es 15% Rabatt auf euer Ticket.

Dieses Ticket, die Agenda und alle übrigen Infos findet ihr auf Codetalks.com. Das war nochmal Codetalks.com und der Code WORKINGDRAFT15 für 15% auf euren Ticketpreis. All diese Infos findet ihr natürlich auch nochmal verlinkt in den Shownotes zu dieser Revision. Wir wünschen euch viel Spaß in Hamburg.

Cool. Soll ich nochmal drücken? Ja. Okay. Der Zufallszahngenerator ist aktiviert. Oh, das Batsignal. JavaScript Iteration Protocols. Aber hatten wir, glaube ich, tatsächlich jetzt auch... Ja, da haben wir schon ein paar Mal drüber gesprochen. Oder? Ist tatsächlich so. Ich muss tatsächlich sagen, ich gehe ja mittlerweile, das haben vielleicht noch nicht alle mitgekriegt, einer ehrlichen Arbeit nach.

Und tatsächlich habe ich heute mal so ein Commit gesehen, wo ich zum ersten Mal jemanden das asynchrone Iterationsprotokoll habe nutzen sehen für einen Use Case, der total viel Sinn macht. Also so Anwendungsfall, ich habe hier irgendwie so eine paginierte Web-API und ich muss die halt eben abiterierbar machen für so ein Get-All- Use Case, aber ich will den Leuten nicht eine Get-All-Funktion geben, weil dann laden die ja alles und brechen nie ab.

Also war einfach so ein for a wait of next request, blablabla Ding und ich dachte so, yield awesome, super, muss so sein. Aber mehr muss man dazu, glaube ich, auch nicht sagen. Nee, genau. Haben wir ja, glaube ich, schon ein paar Monate darüber gesprochen. Und das ist ja im Prinzip, wenn du diese Building-Blocks auf beliebige Objekte setzt, dann werden die auch so Iterators.

Ja, und dass man das halt ausdehnen kann auf Dinge, die auch nicht wirklich einfach nur Listen von Zeug sind oder Datenquellen sind, sondern das kann man ja allgemein für Performance-Fool-Management nutzen. Durfte ich erst letztes Mal für eine Konferenz aufwärmen. Warum, weiß ich auch nicht. Es war auch fast keiner da.

Hast du es selber ausgesucht oder hat man es sich gewünscht? Es war mehr so ein, komm nochmal auf die Konferenz, boah, ich will nicht, jetzt komm schon. Du darfst auch das Iterator-Zertum machen. Nee, mehr so, es ist völlig egal, was du erzählst und dann habe ich halt das genommen, was am wenigsten Vorbereitungsarbeit braucht.

Und das ist halt eben das, was ich seit fünf Jahren erzähle. Okay. Ja, kann man machen. Das war jetzt mal nichts, deswegen lasse ich mal lieber dich drücken. Du hast da eine etwas bessere Erfolgsquote. Ich versuche es. Export Parts, HTML Global Attribute. Da muss ich jetzt auch mal ganz... Das läuft heute nicht so für dich. Da muss ich auch mal...

Nee, ist das auch... Das klingt ja... Klingt jetzt auch so ein bisschen hier Shadow DOM-haft. Ding, ding, ding. Ist es. Aber warum würde man Exportparts haben wollen? Also, Part ist ja, glaube ich, klar. Genau, du kannst einfach. Bestimmte Dinge in deinem Shadow DOM-Tree mit Part markieren und dann kriegt Part einen wieder irgendeinen arbiträren Wert, einen Namen.

Und mit dem kannst du dann, glaube ich, da kannst du dann quasi von außen auch reingreifen mit CSS, indem du die Part-Pseudo-Klassen- Funktion benutzt, richtig? Pseudo-Element, aber bis dahin ist perfekt. Pseudo-Element natürlich, logisch. Und Export-Parts ist ein globales Attribut, das heißt, du kannst es theoretisch auf alles drauf tun, wahrscheinlich ist das wieder so ein Ding, das kann man theoretisch überall drauf tun, aber macht nur Sinn auf einem, wahrscheinlich Shadow- Exakt.

Und der kann dann vielleicht irgendwie sagen, was es für Parts in ihm gibt oder so? Nee. Die Idee ist, du hast irgendwie eine Web-Component und die hat Parts und die verwendest du in anderen Web-Components und du willst diese Parts von der Component, die du beinhaltest in deinem Shadow-Root, exportieren.

Damit die Außenwelt, die dich nutzt, durch deinen Shadow DOM in den Shadow DOM deines Child Elements reingreifen kann, um die zu stylen. Okay, ja, okay, ist ein Use Case. Also dieses Shadow DOM Ding, das ist ja auch so ein, also was sie da für eine Can of Worms mit aufgemacht haben, unglaublich. Ich glaube wirklich, wenn sie das am Anfang durchdacht hätten, hätten sie es sein gelassen.

Ich glaube auch, ja. Weil es ist echt super. Du liest irgendwie ein random Stück Text in der Webspezifikation, wie man das halt so macht. Und du findest halt immer in jedem Algorithmus so den Absatz, der so sagt, ja okay, und für Shadow DOM braten wir diese und jene Extrawurst. Ich meine, es ist super. Das Funktionsset ist so brillant. Das ist alles von der Usability her drei Stufen schlechter als alles, was man in den Frameworks findet. Aber es ist halt da und es funktioniert halt einigermaßen akzeptabel.

Es ist halt einfach so ein 70er-Jahre-Auto, weißt du? Das funktioniert. Das gewinnt keinen Preis in Sachen Komfort, Sicherheit oder generell ästhetische Ansprüche. Aber wenn das halt hast und es funktioniert, dann kannst du damit auch... Dann musst du es auch nie wieder anfassen. Genau, wenn es kaputt geht, dann kannst du es halt eben wirklich mit einem Schraubenschlüssel selber reparieren.

Und das ist halt so, dass dieses Ding bei Exportparts irgendwie... Ich meine, auch das ist wieder so ein Ding, weil diese Web-Components auch so unglaublich langsam sich weiterentwickeln, im Vergleich, ist es halt auch so, dass jedenfalls mir das so geht, dass solche relativ neuen Sachen wie Exportparts.

Ähm, it's been available across browsers since 2020. Ich glaub, stimmt das? Kann ich mir schwer vorstellen. Oder wenn, dann haben halt so Sachen wie die Park-Pseudo-Klasse vielleicht nicht so gut, äh, Park-Pseudo-Element nicht so gut funktioniert. Oder doch? Also Chrome so in den 70ern, so da, 73, Firefox auch und Safari 13.

Okay, dann ist das wohl doch relativ alt. Naja, jedenfalls, was ich nur sagen wollte, ist, das dauert halt eine gewisse Zeit, bis du was halt immer auch schon in die gelebte Praxis rein sickert, weil es halt eben, wie du schon sagtest, schon so ein Can of Worms ist und halt eben nicht trivial ist. Aber im Prinzip könnte man... Ja, das ist immer so, man kriegt was Neues und dann merkt man, okay, ah, wow, also diese Use Cases gehen ja alle gar nicht damit.

Okay, da müssen wir jetzt wieder was für bauen. Oder umgekehrt, weil was du jetzt mit Exportparts ja tatsächlich machen könntest, ist theoretisch, du könntest so Legacy React-Style Higher Order Components bauen. Also du kannst wirklich eine Komponente bauen, deren Shadowdom bloß daraus besteht, was anderes zu wrappen und halt einfach so extra Logik daran zu tackern und du könntest halt wirklich quasi verlustlos das, was du da wrappst, solange du halt die Parts alle kennst, kannst du halt eben wieder exportieren und halt eben praktisch transparent sein.

Weil du kannst die Parts exportieren, damit halt eben das Styling funktioniert. Du kannst dich selbst auch auf Display-Content setzen oder irgendwie so ein Blödsinn. Und kommst halt dann wirklich diesem transparenten Komponenten-Modell sehr viel näher. Ja, das ist schon cool. Und wie ist das denn, sagen wir mal, was wäre denn, wenn das Dreiebenentief ist, das Verschachteln, dann müsste die oberste Komponente bei Exportparts nicht nur, also muss es seine eigenen Parts auch auflisten, nee, nur die zusätzlich zu sich selber.

Genau, die, die halt exportiert werden müssen, die halt als Kind-Elemente im Shadow-Done sind. Aber kann man Exportparts irgendwie auf einen Wert setzen, oder ist es einfach nur, ist es eine Property, die da ist, oder enumeriert die die Parts, die sie exportieren? Die werden enumeriert, weil du willst ja gegebenenfalls, je nachdem, was dein Use Case ist, nicht alles exportieren, was du halt hast.

Möglicherweise ist ja Teil deiner Wrapping-Logik, dass du gewisse Dinge so Partial Application-mäßig schon mal festlegst und andere reichst du halt durch. Ist halt wie wenn du eine Funktion wrapst in JavaScript. Da kannst du auch schon mal aus einer dreistelligen Funktion eine zweistellige machen, weil in dem Use Case der erste Parameter immer der gleiche ist.

Aber es ist ja dann blöd, wenn man. Sowas baut und gar nicht weiß, welche zukünftig welche anderen Web Components da hineinverschachtelt werden? Oder? Geht das? Was meinst du mit Web Components reinverschachtelt werden? Weil du würdest ja also das Export Parts. Baust du ja mit der Komponente, ne? Also, okay, also die Komponente, die da drin ist, die weiß man zwangsläufig, weil es geht gar nicht anders, ansonsten würde man Slots benutzen, wenn man das quasi offen halten wollte und dann, wären die Slots ja auch sichtbar von außen.

Und Slots ist ja der umgekehrte Mechanismus, da kommt ja von außen was nach innen und die Exportparts und Parts-Idee ist ja eher so, von innen wird was nach außen exposed. Ja, okay. Und dann, okay, aber wenn du dann drei Ebenen tief gehst, dann müsste quasi, die mittlere Ebene die Parts exporten von der untersten Ebene, die Parts, die es da gibt, und dann müsste die oberste Ebene in Exportparts die quasi zuvor, genannten Exportparts plus die Parts der in sich, also darin befindlichen, mittleren Komponente exportieren.

Weil indem das, was exportiert wird, wird es ja quasi von der exportierenden Komponente zu ihren eigenen erklärt. Also man hat hier seine eigenen Parts und halt noch die, die ich exportiere unter diesem und jenen Namen und dann ist das halt einfach Teil der Oberfläche. Okay. Ja. Ja, macht Sinn. Ja, cool. Man kann auch so eine Mapping-Logik machen von wegen, dass das, was da jetzt von innen exportiert wird, heißt Foo.

Aber ich will es als Bar exporten, dann geht das mit, ja, Foo-Doppelpunkt-Bar. Ja. Ja, okay. Und ist wahrscheinlich auch dann gut, wie in dem Beispiel, was ich gerade genannt habe, wenn man zwei Komponenten, also zwei Ebenen tief reinverschachtelt verschachtelt und beide dieser, also die mittlere und die unterste Komponente, beide Parts haben die gleich heißen.

Also sowas wie Content oder sowas. Dann wäre das ja ein bisschen blöd. Also müsste man da ein Remapping dann durchführen, damit man weiß, welches von den beiden man jetzt meint. Genau. Du hast so eine Card-Component und die besteht aus einer Header-Component und einer Body-Component und die Header- und Body-Component haben irgendwie beide Parts, die Content heißen.

Dann könnte man das trotzdem bequem auflösen, indem man die halt eben ummerkt. Wobei ich ja ganz ehrlich sagen muss, in meiner persönlichen Web-Component-Praxis schneide ich die Komponenten sehr viel gröber, als ich sie früher mit so Frameworks wie React gemacht habe. Gröber heißt, also du schneidest sie größer oder so weniger klein?

Genau, also ich habe nicht irgendwie, was man jetzt in React zum Beispiel hat, man hat irgendwie so eine Text-Span-Komponente und eine Headline und irgendwie für Icon eine Komponente und sowas. Und ich persönlich tendiere halt einfach dazu, Web-Components zu verwenden als dann so ein Gruppierungsmechanismus für andere Konzepte oder andere Entitäten, die auch so, einen Komponenten konzeptionell sind, aber sich nicht als Web-Components ausprägen, weil der Web-Component-Overhead das halt unattraktiv macht.

Das heißt also, ich habe in meinem Universum dann sowas wie Web-Components, aber die sind relativ groß geschnitten und enthalten dann in sich drin so Konstrukte wie zum Beispiel BEM, um halt Subkomponenten auf diese Art und Weise aufzugliedern, damit ich halt den Benefit habe, aber ich mache halt nicht alles so Mikrokomponenten-React-Style, und das scheint mir irgendwie sinniger zu sein, als dem hinterherzurennen mit halt so Sachen wie Export-Path.

Ich will nicht sagen, dass das jetzt nutzlos ist, auch in meinem Universum, sondern mehr so, ich habe dafür einen sehr weniger großen Bedarf, wenn ich einfach sage, ich schneide meine Komponenten einfach sehr viel größer, und muss dann halt eben inhärent pro Baustein auch weniger Flexibilität einbauen.

Und hast halt dann auch eine weniger tiefe, Web-Component-Verschachtelung. Und natürlich ist es so, dieser Ansatz führt automatisch dazu, dass du weniger Flexibilität einplanen musst. Weil wenn du nichts hast, was wirklich so auf Atom-Ebene, wie man vielleicht sagen würde, unterwegs ist, also ich habe keine Design-Atoms als Web-Components in meinem Universum, weil das sind normalerweise auch die, wo du am meisten dann Flexibilitäts-APIs einbauen musst.

Und wenn du die nicht hast, wenn du einfach sagst, du willst ein Icon haben, dann baue da halt ein SVG ein und denk dir kein Custom Tag aus, dann gehen halt sehr viele Probleme damit einfach auch weg. Nachteil ist halt, du machst so eine Komponente auf und sie ist wirklich ein Miniprogramm, aber meine Güte, stelle ich halt nicht an, sondern finde ich damit ab.

Und damit fahre ich sehr gut und sehr No Tag, dann brauche ich halt so Kram wie Export Parts oder auch Parts sehr, sehr selten. Und dann hat man auch weniger von den ganzen Shadow DOM Can of Worms an den Backen und Und obwohl man weiß, okay, hier B-Dragons, muss man sich nur mit einem sehr kleinen Teil davon im Alltag befassen. Und dann wird das alles sehr viel besser.

Also Web-Components sind sehr nett, aber ich glaube, es gibt sehr viele Möglichkeiten, da in die You're holding it wrong-Falle zu rennen. Sowieso. Bei denen auf jeden Fall. So, dann soll ich mal? Okay, wir schaffen es jetzt aber mal bestimmt auf irgendwas zu kommen, was nicht irgendwie Bizabo-Peter-Thema ist. Komm.

Oh, SVG Foreign Object. Das ist, wenn ich was einbetten möchte in SVG. Das ist, wenn du einen, wie soll man es nennen, einen anderen Dokumententyp in deinen SVG einhängen willst. Also zum Beispiel ein HTML oder wahrscheinlich auch ein MathML. Ein XHTML-Dokument. Da ist der Use Case. Ja, genau. Ich überlege gerade, ob das, also ich glaube, dass das nicht zwingend erforderlich ist, dass es dann, dass du dann quasi XML, also HTML in XML Serialisierung schreiben musst.

Also ich glaube, das ist okay, das musst du nicht. Ich glaube auch nicht, aber wir schauen mal in die Spezifikation. Foreign Objects. Nee, SVG compatible with other XML languages. Foreign Object allows for inclusion of elements in a non-SVG namespace. Also muss das, glaube ich, dann doch. Adding a block of complex CSS formatted HTML.

Das wäre aber bestimmt auch eben MarfML. Okay, nee, MarfML sowieso, weil das ist ja auch nur ein anderer XML-Namespace, aber jetzt steht hier auch noch, bla bla bla, Commercial Web Browsers sollten halt eben auch ein normales HTML da einbauen. Das soll also gehen. Auch wenn das jetzt technisch gesehen nicht wirklich XML ist.

Aber ja, das ist also, Also ich baue ein HTML-Dokument in mein SVG-Dokument ein, damit ich, wenn ich mein SVG-Dokument in mein HTML-Dokument einbaue, ich ein HTML-Dokument in meinem SVG habe. Yo, Doc. Genau. Und eigentlich die coolste Art der Nutzung dafür ist eigentlich immer schon gewesen, dass wenn du ein Screenshot von deinem, also wenn du jetzt zum Beispiel so ein, sagen wir mal, du hast ein Support-Tool, und wo man so draufklicken kann, wenn man irgendein Problem hat, dann kannst du ein Screenshot der aktuellen Seite machen, indem du das ganze DOM nimmst, und in ein SVG for an Object reinsteckst, also von einem SVG, und das dann in eine Canvas rein renderst und, dann quasi das als PNG exportierst zum Beispiel. Ja.

Und dann hast du deinen Screenshot gemacht. Ich glaube, sollte es nicht auch sogar mal eine Screenshot-API geben oder sowas? Das weiß ich gerade nicht. Die spannendere Frage ist eigentlich, ist das nicht eigentlich ein Datenexfiltrationsvektor, den man vielleicht eher nicht haben möchte? Ja, kann schon sein. Screen Capture API gibt es. Was bedeutet, gibt es? Limited Availability.

Interessanterweise gibt es das nur in Edge. Was soll das denn? Nur in Edge, das ist ja sehr ungewöhnlich. Eigentlich ist ja immer alles in Edge und Chrome. Ja, klar, ist ja das Gleiche. Okay, da geht es aber mehr so um Videotelefonie. Da kannst du genau, also wenn du deinen Screen sharest, aber das geht ja auch.

Das machen wir ja tagtäglich fast mit Google Meet und Co. Tja, warum ist die Browser-Compatibility da oben so im Baseline? Naja, weil das in Safari nicht funktioniert und vieles davon läuft in Firefox nicht. Aber Chrome und Edge supporten das weitgehend. Okay, es gibt vielleicht dann so Sachen, wie, dass du nicht einzelne Tabs abgreifen kannst, aber so generell Git-Display-Media kann der Safari auch.

Ja. Und der Firefox auch, aber dann kannst du quasi nur das ganze Display kriegen wahrscheinlich und diese Feinheiten wie ein Monitor oder ein Fenster oder ein Tab, diese Geschichten, das können dann nur die, können nur Edge und Chrome. Oder Window-Audio. Window-Audio, ja, stimmt. Okay, aber also unten in der Browser-Matrix, da ist es irgendwie Gleichstand zwischen Chrome und Edge, aber ganz oben bei dem Baseline-Moped, da ist es irgendwie nur der Edge, der das supportet.

Da ist bestimmt irgendwas kaputt. Das ist auf jeden Fall nicht korrekt, weil streng genommen, es kann Chrome mehr. Also weil eben zum Beispiel die Window-Audio-Option der zumindest teilweise supportet und edge einfach mal so gar nicht. Stimmt. Da werde ich aber mal denen einen Brief schreiben. Ja, das ist eine gute Idee.

So, aber ansonsten Foreign Object. Weitere Use Cases? Weitere Use Cases? Naja, ich könnte mir vorstellen, also ich meine, du kannst ja auch mit CSS, kannst du im HTML Dinge stylen und da also mit Filtereffekten versehen und verweisen auf ein SVG, was du irgendwo an anderer Stelle in deinem Dokument liegen hast.

Das geht ja auch. Indem du dann eine ID auf einem SVG-Filter legst und dann verfinzierst du den eben mit der Raute. Genau. Und man könnte halt irgendwie sonst im SVG HTML einbetten und das dann filtern direkt im SVG selber. So, das wäre noch ein Anwendungsfall für Foreign Object, aber muss halt auch nicht sein.

Also die spannende Frage ist natürlich in dem Fall, wie viele Verschachtelungen kann man machen? Also wie tief, was ist wirklich so Code-Golf-mäßig, wie tief kann man verschiedene Mechanismen von ich bette Dokumente in anderen Dokumenten ein, wie weit kann man es treiben? Weil ich bin sicher, es gibt irgendwie so harte Limits für irgendwie, du kannst nur irgendwie drei I-Frames ineinander verschachteln oder zwei oder was auch immer.

Aber was ist halt eben, wenn man nach dem zweiten I-Frame sagt, okay, danach bastle ich halt ein Dokument irgendwo rein, indem ich halt ein PDF ins Foreign Object stecke und baue mir da rein dann ein MathML-Dokument oder irgendwie sowas. Also, weil ich bin sicher, da gibt es halt irgendwelche Dinger von wegen, man kann nicht mehr von denen machen.

Aber die Frage ist halt, wie sind diese Grenzen definiert und kann man dann diese Grenzen umschiffen? Ja, du willst ja immer hacken. Ich bin 100% Whitehead. Also, ich will hier niemanden das Kreditkartendaten klauen. Ja, das ist alles. Above board. Aber definitiv mal eine Frage. Ja, guck mal hier. ich habe noch einen Use Case und zwar ist ja Text, das ist ja glaube ich auch bei den Browser-Leuten dieses Jahr gewesen, was finden die an SVG scheiße?

Und dann haben die meisten Entwicklenden gesagt, ja, also Text Layouten in SVG ist Pain in the Ass, ist es tatsächlich ja auch, du hast ja keine Umbrüche und nix. Genau und das ist natürlich dann nochmal so ein Use Case, wo du vielleicht dann auf die Fähigkeiten von HTML zurückgreifen kannst, indem du überall da in SVG, wo du lange Text hast, eben umschaltest auf HTML. Das ist eine sehr gute Idee, die Gefälte.

Ja, genau. Aber vielleicht habt ihr ja noch ein paar coole Hacks auf Lager, was ihr mit Foreign Object gemacht habt, weil das sich einfach so wahnsinnig gut an, also es bietet sich einfach an. Also ein Hacks auch im Sinne von valide, coole Ideen, die man damit lösen kann. Dann schreibt uns mal. Also ich überlege mir noch eins.

Kann ein per Foreign Object eingebettetes HTML-Dokument etwas über die Attribute-Konfiguration des Hosts wahrnehmen. Also kann ich in mein HTML-Dokument eine CSS-Regel schreiben, die den Hintergrund grün macht, wenn auf dem SVG-Element, in dem das Foreign Object drin steckt, die Klasse Foo gesetzt ist und wenn die Klasse Bar gesetzt ist, wird die Farbe eine andere.

Das weiß ich nicht. Ich würde... Ich würde... Nee, ich weiß es nicht. Es könnte beides sein. Ja. Kann ein SVG-Element ein Shadowhost sein? Ich würde tippen, das nicht. Angestrengtes Googlen. Leider hier wieder die Single-Page-Version des HTML-Standards. Bis der geladen ist, vergehen hier wieder drei Jahre.

Ich glaube nicht. Ich glaube, Shadow Hosts war ja eine endliche Liste von Elementen, die das machen konnten. Attached Shadow. Weil dann wüsste ich, dass es geht. Ich überlege ja immer noch, ob ich irgendwie die Möglichkeit kriege, meine bescheuerten Code-Animationen irgendwie in einen HTML-Tag zu paketieren.

Dass ich den Leuten einfach sagen kann, schmeiß dieses Ding irgendwo rein und vergiss es. Aber jenseits von einem, ja, nee. Gibt's halt praktisch nicht. Ja. Also man könnte ein Diff mit irgendwie Shadow Root Mode oder irgendwie so ein Kram machen, aber dann geht halt eben die Steuerbarkeit flöten über, Setzattribut, dann hast du den Frame überkriegt.

Aber das geht alles nicht und das ist auch alles nicht notwendig. Interessiert keinen, braucht keiner. Ja. Also. Genau, ich habe jetzt gerade auch mal geguckt, also es geht wohl, wenn du, wenn das SVG geinlined ist in wiederum HTML, dann geht das. Dann geht was, genau. Aber es geht nicht. Also dann kannst du Sachen, die im SVG wiederum als foreign element eingebunden sind, stylen auf Basis einer Klasse, die auf dem SVG-Element sitzt.

Das war auch deine Frage, oder? Ja, weil dann das eingebundene Objekt per foreign object gilt als ein Kind-Element von dem SVG-Element. Genau, aber angeblich, um es zweimal ausprobieren, funktioniert das eben. Nur... Ja, genau. Okay, ja, okay, ja, macht... Nee, nee, genau. Und dann ist es blöd, weil dann kann ich den Leuten nicht sagen, binde diese SVG-Datei ein und auf magische Weise tut es dann.

Genau, also wie meinst du mit ein, binde die SVG-Datei ein dann als Image oder was? Ja, genau. Und dann kannst du irgendwie auf dem Image am besten irgendwie, weil du hast ja tatsächlich eben, also mein Traum-Szenario ist, binde dieses SVG ein, das hostet mein HTML, das diese generierte Animation ist.

Und auf dem Image kannst du ja theoretisch mit der Raute dann ja auch zwischen IDs selektieren. Die könnten mir dann ja gelten als tatsächlich die Frame-Indikatoren. Ja. Aber das funktioniert halt aus einer Reihe von Gründen nicht. Unter anderem, weil der Wechsel von der ID, wenn die Adresse sich ändert von dem Image, dann tritt das keine CSS-Transitions los in dem SVG.

Und das ist ja, was ich bräuchte. Hast du, ich glaube, darüber haben wir auch schon mal ein bisschen drüber gesprochen, aber SVG-Linked Parameters oder Linked Parameters? Die jetzt kommen, vielleicht sind die die Lösung. Und zwar kannst du... Wenn ich das in meinen Browser eintippe, kommt als erstes ein Artikel raus, der SVG-Linked Parameters Workaround heißt. Ja, ja, ich weiß.

Von Roma Kumaro. Den habe ich übrigens getroffen. Am Freitag. Der war auch hier bei der Frontiers. Ja, ja, ich weiß, Chef, nächstes Jahr komme ich da auch hin. Ja, sehr gut, genau. Kommt alles vorbei, erst im Oktober. Wenn ihr Karten kauft oder mehr wissen wollt, schreibt mich an. Ja, aber genau, was hat es damit auf sich? Erklär nochmal.

Du kannst mit, also es gibt dann demnächst in CSS eine Eigenschaft Link. Und da kannst du mithilfe der Param-Funktion also die oder du kannst als Werte, als Values übergibst du Param-Funktion und, da definierst du einen Custom Property oder einen Identifier und dann dessen Wert, also Identifier zum Beispiel dash dash color 1, Komma Wert red, und davon kannst du eben von diesen Param Key-Value-Kombinationen kannst du halt beliebig viele dann in diese Link-Parameters-Eigenschaft, CSS-Eigenschaft eingeben.

Und im SVG kannst du dann über die N-Funktion, also für Environment, das kennen wir ja schon. Von anderen Dingen, wie zum Beispiel... CSS allgemein, glaube ich. Das ist doch einfach ein allgemeines Feature für Umgebungsvariablen. Genau, ja, genau. Also CSS-Variablen, die vom System gesetzt werden und nicht von uns Autoren.

Genau. Damit kannst du die dann wieder auslesen, glaube ich. Ja, genau. Okay, das macht Sinn. Also quasi habe ich in meiner URL von meinem SVG extra Parameter, die darüber hinausgehen. Das ist jetzt diese ID, sondern ich kann tatsächlich auch sagen, quasi über so eine Art Name Parameters, Funktionalität wie bei so einer Funktion in der Programmiersprache.

Ich setze jetzt den Custom Identifier Color auf Green, das steht in der URL drin und dann kann ich die URL ändern und dann kriege ich das gleiche SVG, aber unterschiedlich parametrisiert. Genau. Und ich will jetzt wissen, ob mir das dann Transitions macht in dem SVG, weil wenn es das tut, ist das, was ich haben möchte.

Ja, also okay, wann würde die Transition nochmal loslaufen, wann sollte die loslaufen? Deiner Meinung nach? Ich habe ein Image eingebunden mit meinem SVG, Foo SVG, und dann habe ich da drin einen Parameter, der sagt zum Beispiel Color Green, und dann ändere ich das Source-Attribut von dem Image auf Color Red.

Und dann habe ich in dem SVG drin gesagt, jo, da wo ich am Ende diese Environment-Variable verwende, um halt zum Beispiel, eine Farbe von irgendwas zu ändern, durchaus auch ins CSS, habe ich gesagt, hier Transition, eine Sekunde, ease, ab geht's. Okay, also wo dann quasi, dass die Farbe so lange, also quasi animiert in den neuen Wert rein. Bingo.

Bingo. Und natürlich in meinem Fall auch noch speziell nicht nur im Falle von, SVG, sondern das müsste dann natürlich in meinem Fall transportiert werden in Logik, die dann von einem HTML-Dokument in einem Foreign Object wahrgenommen wird. Ich würde sagen, ausprobieren. Ich würde auch sagen, das werde ich einfach mal testen müssen, weil ich brauche keinen separaten SVG-Renderer. Geh mir recht damit. Ja.

Aber das ist gut. Naja, vielleicht musst du auch einfach dann noch eine Element Scope View Transition auf dieses SVG-Bild setzen und dann hättest du deine Transition. Weil die ja sowieso den neuen Wert per JavaScript setzt, oder? Nee. Nee? Nee. Also ich meine, faktisch passiert das, weil JavaScript der einzige Mechanismus ist, um diese Adresse zu verändern.

Aber theoretisch könnte man ja auch einfach diese SVG-Datei meines Traums aufrufen in einem Browser, indem man dann in der Adresszeile eintippt und dann in der Adresszeile was ändert. Mhm. So, und ich hätte halt schon ganz gerne irgendwas, wo ich nicht ... Also wo ich halt so ein bisschen Graceful Degradation habe, wo ich irgendwie sagen kann, du kannst die Webseite einfach in einen Zustand versetzen, wo du dann auch ohne JavaScript etwas Definiertes siehst.

Und nicht so Single-Page-Application-mäßig. Und warum machst du das nicht einfach mit einem Hash und dann arbeitest du irgendwie mit Doppelpunkt-Target der Pseudoklasse? Weil das in diesem Anwendungsfall, den ich genannt habe, wo ich wirklich mit einem Image ein SVG einbaue, in diesem Fall mit den Hashes, dass es keine Transition gibt.

Okay. Ich hätte es so viel einfacher, wenn ich einfach wie irgendwie so ein, React-Affe sagen würde, wir machen alles mit JavaScript, aber nö. Das können die machen. Ich betreibe hier eine andere Sportart. Und ich will das, was so funktioniert, wie ich das will. Und sonst mache ich das halt nicht. Geht mir weg.

Ist ganz einfach. Okay, sollen wir einmal drücken nochmal hier? Einen drücken können wir noch. Wer ist dran? Ich glaube, ich bin dran, oder? Ich glaube auch. Du bist dran, komm. Ich drücke. Ah, jetzt wird es aber, jetzt wird es zum Schluss nochmal entspannt. Das Site-Element. Das Site-Element. C-I-T-E. Shep, wann hast du das zuletzt eingesetzt? Ja, erstmal die gute Nachricht.

Es ist supported seit Juli 2015. Ich wette, das ist länger supported als Juli 2015. Ja, auf jeden Fall. Wahrscheinlich enden die Support-Matrix-Daten. Also ist das wahrscheinlich der Beginn der MDN-Support-Matrix-Daten. starten oder so. Ich wette, dass es irgendwie seit 2000, 2000 supportet. Ja, ja, mindestens.

Genau, das ist ja ein uraltes Element eigentlich. Weißt du noch, was man früher zitiert hat und Quellen angegeben hat? Ja, aber wie ist das denn bei Site? Ganz so easy ist das ja nicht. Also man kann es auf jeden Fall, okay, ich sehe hier Blockquote, in Blockquote nutzt man es aber jetzt irgendwie ja meistens nicht.

Das ist ja auch hier in dem Beispiel nicht der Fall. Das heißt, die haben diese Blockquote in eine Figure gesteckt, weil man kann ja Figure auch für Nichtbilder nehmen, eigentlich für alles Mögliche, was man irgendwie annotieren möchte. Und dann haben die in der Fig Caption dann einen, quasi eine Erklärung plus Site-Attribut, in dem ein Link ist.

Und dann ist ein genau, Verweis, auf das 1984, das Buch von George Orwell. Weil die ein Zitat rausholen. Zeit ist die Quelle und nicht der zitierte Inhalt. Genau, Blog-Code ist der zitierte Inhalt und Zeit ist die Quelle. Genau, ich habe mich derweil zurückgearbeitet bis mittlerweile 1997. Da ist es auch schon Bestandteil von HTML. Ja.

So, aber wo kriege ich jetzt die ältere Spezifikation her? Hm. Hm. Ja. Wahrscheinlich irgendwie mal hier. Englische Wikipedia, das EN steht ja für Enhanced. Da kriege ich möglicherweise einen etwas besseren Überblick. Aber es gibt auch das Site-Attribut, das kann man auf Blockquote oder auf Q, das war Q, das ist ja auch sowas, aber wo ist ja nochmal die Feinheit?

Quote ist dann der Zitier, das Inline-Äquivalent zum Blockquote. Genau, da kann man auch das Site-Attribut draufsetzen und dann würde man auch da eine URL reinpacken. Ja, ich bin mittlerweile auf meiner Reise zurück in die Zeit bei HTML 2.0 angekommen. Da ist es auch schon drin. November 95. Das macht ja eigentlich Sinn, weil HTML ja, für wissenschaftliche Geschichten entwickelt wurde. Und da zieht man ja ständig irgendwie andere Wissenschaftler. Ja, exakt.

So, hier, info.journ, hier, browse the first website, da müsste es eigentlich auch drin stehen. Technical, wo finde ich jetzt nochmal, hier, syntax of HTML format, das wollte ich haben. The tags, gib her, site, nee, in der ersten ist es nicht drin. Also da brauchen wir schon HTML 2.0 für. Und das heißt, das Ding ist tatsächlich supported nicht seit 2015, was die Lügenpresse von NDN da behauptet, sondern tatsächlich mehr so seit 1995. Ja.

Und Browser-Compatibility, da steht Safari erst ab Version 4. Aber wahrscheinlich ist das auch so ein Ding. Boah, das ist, glaube ich, echt so irgendwie so Technologie-Archäologie. Ja. Wo du wirklich irgendwann fragen musst, okay, kannst du dann überhaupt noch irgendwas ausgraben, was dir das Gegenteil beweist?

Es gibt auf jeden Fall, also ich weiß auch gar nicht, was Support überhaupt bedeutet. Was müssten Browser überhaupt tun, um das zu supporten? Also im Grunde, es hat keine ARIA-Roll auch. Also Accessibility-mäßig ist da irgendwie, passiert da auch nichts. Hatte ich dich nicht letztens schon mal damit gefoltert mit der Frage, ob das Blink-Element supported ist?

In den Browsern? Ja. Lass mal überlegen. Ja, Blink haben die doch rausgebaut. Das war das Einzige, was die rausgebaut haben wieder. Warum auch immer, oder? Okay, dann habe ich dich mit der Frage noch nicht malträtiert. Also ich weiß noch, das war, vielleicht war es vor 10 Jahren oder so, da wurde es doch rausgebaut.

Irgendwie aus Performancegründen. Ich weiß gar nicht, warum das rausgebaut wurde. Rausgebaut? Und was heißt denn rausgebaut? Also es ist so, dass die Browser, wenn du ein Blink-Element nimmst, glaube ich, dann musst du jetzt einen Polyfill haben, der das blinken lässt. Nee, warte, warte, warte, warte, warte. Ich sehe genau, wie du jetzt gerade von irgendwelchen Bildschirmen liest.

Aber kommst du dich mal kurz auf mich und beantworte jetzt mal im Abstrakten die Frage, was es bedeutet, aus einem Softwareprodukt wie einem Browser etwas auszubauen. Wie stellst du dir die Implementierung dieses Arbeitsschrittes vor? Ich denke, also entweder man klemmt das am Parser ab oder man sucht sich den Codeschnipsel in der Codebase, der dafür früher zuständig war, und wirft den raus.

Ja, also du würdest sagen, der primäre Implementierungsmechanismus ist der des Löschens. Ja. Und das würdest du sicherlich auch auf die HTML-Spezifikationen ausdehnen, da müsste ja was Ähnliches passieren. Okay, jetzt ist es bei Blink tatsächlich so, dass wenn du hingehst und du guckst in die Spezifikationen, steht da drin, dass das Blink-Element nicht existieren soll und dass, wenn der Browser ein Element mit dem Tag Blink vorfindet, er dem Ding das HTML-Unknown-Interface verpassen muss, also den gleichen Parsing-Mechanismus an den Start bringen muss, den er halt eben auch macht, wenn ich dann plötzlich behaupte, es gäbe ein Shep-Element in meinem Dokument.

So, jetzt weiß ich ja nicht, ob ich da jetzt einfach nur einen besonders seltsamen Blick auf diese Dinge habe. Aber ist das nicht ein bisschen seltsam, dass nicht nur das Blink-Element, sondern diverse andere aufgelistet werden im HTML-Standard als Elemente, die nicht zu supporten sind? Das widerspricht sich doch, oder? Wenn das Dokument hier auflistet, hier ist die Liste von allen Tags, die es nicht gibt, aber es ist ja keine endliche Liste, weil da drin ja zum Beispiel nicht drin steht, dass es keinen Shep-Tag geben soll, aber einen Shep-Tag gibt es auch nicht.

Das wird auch ein unknown Element, aber nicht, weil in der Spezifikation steht, dass es unknown sein muss, sondern weil es unknown ist, weil es nicht in der Spezifikation steht. Exakt. Weil es darauf zurückfällt. Vielleicht eben, weil es ja mal anders gerannt habt wurde. Absolut, das wird der Grund sein. Nur ist das nicht ein bisschen seltsam, Nicht-Unterstützung und Nicht-Existenz von diesem Element einzubauen in die Spezifikationen?

Dass man da wirklich sagen muss, weitergehen, hier gibt es nichts zu sehen, das Ding existiert ganz bestimmt nicht. Es gibt viele, die nicht existieren, aber das hier existiert besonders nicht. Macht man doch quasi das Gegenteil mit. Du meinst, dass die Leute es erst recht benutzen wollen? Nein, überhaupt nicht. Sondern nur, dass das eine sehr seltsame Implementierung von Nicht-Existenz ist. Ja.

Warte mal, ich teste mal hier. Ich habe noch etwas viel Verrückteres. Ich habe auch noch etwas. Wenn du Visual Studio Code aufmachst und du machst ein HTML-Dokument auf und du machst Spitzklammer auf, Shep, Spitzklammer zu. Also verwendest du einen HTML-Tag, der kein gültiges Custom-Element ist, aber den es auch nicht gibt.

Dann wird der Visual Studio Code Editor und viele andere auch, die werden das highlighten wie ein normales HTML-Element wie halt Diff oder was ähnliches. Wenn du das gleiche mit Blink machst, highlighten die das nicht als HTML, sondern highlighten das als Plaintext. Okay. Das heißt, irgendwo in der Logik von Visual Studio Code ist implementiert, dass es Blink nicht gibt, indem sie einen extra Code-Pfad definieren, der sagt, if tag blink, then highlighting ausstellen.

Vielleicht habe ich ja eine Schraube locker. Aber ganz ehrlich, irgendwie sieht mir das so aus, als wollten die uns einreden, etwas würde nicht existieren, das aber tatsächlich existiert. Und sie machen riesigen Aufriss und bauen in ihre Produkte extra Code-Fade ein, in ihre Spezifikationen extra Abschnitte rein, wo sie auflisten, das und das und das existiert nicht, weitergehen, hier gibt es nichts zu sehen.

Ja, don't press this button. Ist so, ne? Das ist eine Verschwörungstheorie und die wollen uns einreden, das Element würde nicht mehr existieren und indem sie das behaupten, wird es nur noch deutlicher für mich, dass das da ist. Das ist quasi das Blitzding der HTML-Spezifikation. Ja, das Blitzding hat ja wenigstens funktioniert.

Ja, und ich glaube auch nicht, dass hier irgendwie so Sachen wie das Blink-Tag mit irgendwie einem besonderen Soundtrack oder ähnlichem daherkommen. Also da ist wirklich nichts dran. Jetzt versuche ich die ganze Zeit noch rauszufinden, ob es irgendwie für das Side-Element irgendeine Art von materiellen Feature gibt.

Also bevor wir dahin kommen, wollte ich noch ergänzen und das ganz nett hier in der MDN steht. The Blink Element was apparently created after conversation in a bar in Mountain View between Netscape Engineer Lou Montulli and colleagues. When he went into the office the next morning, he found that one of his fellow engineers had stayed up all night and implemented it.

Also genau, ich verlinke mal die ganze Geschichte. Und das haben sie offenbar einfach über Nacht hingekriegt, aber heutzutage kannst, du keine zwei Zeilen mehr schreiben, ohne irgendwie erstmal Claude aufzumachen. Ich weiß ja nicht, alles ist seltsam. Tja. Ich finde, du solltest auch in den Browser mal was rein implementieren.

Wenn mich dafür jemand bezahlt, irgendwo muss das Katzenfutter herkommen. Und im Moment, weiß ich nicht. Meinst du, ich kriege einen Storyblock-Tag durchgesetzt? Zum Beispiel? Ich bin mir nicht sicher. Genau. Aber ich finde, wir haben auf jeden Fall ein paar schöne Sachen hier gezogen, die wir noch gar nicht hatten vorher.

Das ist ja dann nach so langer Zeit und so vielen Glücksrädern und so vielen anderen Dingen auch nicht mehr selbstverständlich. Ja, ich meine, der einzige Griff daneben waren die Iterationsprotokolle. Genau, aber nur, weil wir die auch irgendwann schon mal gemacht haben. Mindestens einmal. Ja. Ich muss mal gucken, ob ich die Folge nochmal rausfinden kann, wo wir da ein bisschen tiefer drauf eingegangen sind. oder du, besser gesagt.

Wahrscheinlich war ich das, ja. Das ist anzunehmen. Genau. Und weißt du, was du machen solltest, Shep, du solltest dich auch an der Webstandardsentwicklung, beteiligen und dafür sorgen, dass diese ganzen Standardsdokumente einfach mal ein bisschen besser funktionieren. Die sind alle so langsam. Also, klar, ich mache die jetzt auch irgendwie so in der brutalen Version auf, also so das Single-Page-Dokument, EGMA-Skript schon das HTML-Standard, aber trotzdem würde ich doch erwarten, dass wenn ich einen hochgezüchteten modernen Rechner habe, der in der Lage sein sollte.

Also, das geht doch bestimmt, oder? Aber was hast du, der blockiert dann oder was, dein Rechner? Genau, also ich suche jetzt gerade nach der Zeichenkarte Site in dem Dokument, drücke hier halt F3, F3 und jedes Mal, wenn er halt eben dann scrollen muss, weil er im aktuellen Viewport kein weiterer Hit mehr ist, dauert das 10 Sekunden.

Okay, ja, das ist krass. Okay, ist jetzt Firefox auf dem PC, das geht vielleicht mit Chrome auf dem Mac besser, aber trotzdem. Na, der Jake Archibald, der hatte doch irgendwann mal als Content Visibility neu war, hatte dann, also da hat er noch bei Google gearbeitet, glaube ich, hatte demonstriert, wie anhand des HTML-Standards, der HTML-Standardseite, wie man da quasi so eine Art Lazy-Rendering machen kann, eben nur der Dinge, die gerade im Viewport sind.

Und hat dann demonstriert, wie viel schneller die HTML-Spec dadurch wird. Aber es hat wahrscheinlich dann nie den Weg in diese Speck-Dokumente gefunden. Was halt echt schade ist, weil ich würde davon sehr profitieren. Ja. Aber vielleicht ist die Leidensdruck mit richtigen Laptops weniger groß als jetzt mit meinem alten Eimer hier.

Genau, aber die benutzen ja wahrscheinlich immer ein und dasselbe Style Sheet für alles. Also eigentlich könntest du wahrscheinlich einfach einen Pull-Request machen, wo du Content Visibility hinzufügst zu dieser einen Template, die die für all ihre Standards nutzen. Ja, weiß ich nicht, weil ich glaube, das Problem ist tatsächlich am größten, bei den Monolithen, wie WhatWG HTML.

Und das sieht ja anders aus als Standard W3C oder ECMAScript. Das ist ja auch was anderes. Wenn du eine einzelne CSS-Spezifikation hast, die jetzt nur in Print ausgedrückt ein paar hundert Seiten hätte, da ist das nicht so schlimm. Aber wenn wir halt eben über 1000D reden, dann wird es halt schon knifflig und dann ist es halt auch so eine Sache, die individuell auch ein bisschen schwieriger ist mit der Durchsuchbarkeit und da ist dann tatsächlich auch noch wahrscheinlich anderes, was da mit reinspielt, weil hier in dem Dokument hier kannst du einfach Text markieren, und dann poppt halt ein UI hoch, womit du sagen kannst, ich kann direkt mal ein Issue aufmachen zu diesem Text, den ich markiert habe.

Und da könnte ich mir auch vorstellen, dass man ein bisschen Performance flöten geht. Das ist, glaube ich, echt nicht ganz so trivial. Ja, aber ein spannendes, eigentlich ein spannendes Projekt, das mal quasi zu profilen und Wege zu finden, das schneller zu machen. Ich glaube also, wenn man wirklich irgendwie einen Blogpost schreiben möchte, der abgeht, könnte ich mir das als Thema ganz gut vorstellen.

Kostenlose Idee für alle Zuhörenden. Genau. Und ich habe die Version gefunden, oder die Revision gefunden, in der wir über diese Literaturen gesprochen haben. Und jetzt darfst du mal raten, welche das ist. 621. Nein, niedriger. Du bist noch weiter weg. 521. Immer noch weit weg. 321? 323. Wow. 2017. Wann war das? 2017, im Dezember.

2017, aber da gab es noch keine asynchrone Iteration, oder? Die Folge heißt, tatsächlich heißt die auch nicht Revision, sondern sie heißt Iteration 323 und in Klammern asynchrone Iteratoren. Und deswegen war bei meinem Konferenz-Talk letzte Woche war keine alte Sau da, weil ich halt seitdem das durch die Gegend trage. Mittlerweile nur noch eben unter Protest, aber so lange rede ich schon drüber.

Und so selten sehe ich es in freier Wildbahn umgesetzt. Das ist ein Jammer. Guck mal, ich sehe auch hier, genau da, genau, die Asynchron-Iteratoren waren damals aber noch Stage 3 bei der TC39, also waren noch nicht, in den Browsern, aber das hast du dir natürlich mit Babel alles zurechtgezupft, dass du es benutzen konntest. Selbstverständlich.

Hervorragend. Genau. Also, Hör-Empfehlungen für diese alte Folge. Ich weiß nicht, was ich damals für ein Blödsinn geredet habe, aber ich trage es einfach mal mit. Ja, genau. Also, die ist so alt, da haben wir auch noch keine Transkripte. Also, musst du dann auch tatsächlich durchhören. Aber es waren nur 29 Minuten. Also...

Die Hans und du darüber sprach. Okay. Wir zwei Kompakt-Kommunikatoren können tatsächlich auf eine halbe Stunde kommen. Das kann ich mir vorstellen. Ja. Wir sind auf etwas über eine Stunde gekommen. Ich sage vielen Dank. War wieder sehr schön. War mir ein Vergnügen, wie immer. Wieder viel gelernt über Web-Components und Service-Worker und so.

Und ich habe wieder viele Ideen für Tests, die niemand machen sollte. Ja. Du machst mal hier wieder, nimmst SVG nochmal schön in den Mangel. Ich muss gucken, es scheint sich einiges getan zu haben, seitdem ich das letztes Jahr angesehen habe. Also wer weiß, vielleicht taugt es. Ja, ich glaube, bei SVG wird auf jeden Fall jetzt noch vermehrt was gemacht, weil das einfach so einer dieser großen Pain-Points ist für Entwicklende.

Ja, das Ding ist halt, fehlgemacht werden heißt halt immer, es gibt viele Features. Aber was halt wirklich dann das Problem ist, ist halt wie mit allen Computersystemen, es ist halt da, wo die Interaktion stattfindet. Also können diese SVG-Features wie jetzt diese Link-Parameters, gehen die dann mit.

Transitions konform, spielt das zusammen. Oder so die gleiche Frage hatte ich ja schon mal vor Ewigkeiten. Okay, ich kann Custom-Properties setzen, inklusive Typen, aber wenn ich Custom-Properties dann in einer Animation habe, interpoliert das dann auch entsprechend. Ja, das war doch das, was der Firefox nicht gemacht hat, oder? Exakt.

Aber jetzt macht er es doch, oder? Das war nur lange Zeit nicht und jetzt kann er es, oder? Ich glaube nicht. Ich glaube, ich bin immer noch da auf diverse Bugs subscribed, und kriege hier nur wieder ein Update, wenn da mal wieder irgendwie so ein Spammer sagt, hier. Okay. Kauf meine Bitcoin oder was. Ja, okay. Dann musst du da wohl auch mal den Jake Arkebild nochmal dem in seine DMs sliden. Oder du gehst auf die Frontiers-Confidence und triffst ihn da. Der war nämlich unser MC.

Ja, okay. Dann kann ich ja fragen, warum man nicht schon längst irgendwas zurechtgepromptet hat. Wie schwer kann es schon sein? Genau. Dann gibst du einfach ein paar Bier aus und dann tütest du das ein. Dann macht er das für dich. Ist der nicht brittig und elendig groß? Also der ist Brite und ist ungefähr so groß wie ich.

Okay, dann ist er nicht elendig groß. Nee, elendig groß ist er nicht. Das heißt, dann werde ich nur einfach vernichtend geschlagen, wenn es um Bier geht. Ach, weißt du, wenn man sitzt, wenn Leute sitzen am Tisch mit Bier, dann sind sie alle gleich groß. Und überhaupt, wahrscheinlich bist du trinkfester als er.

Ich befinde mich hier in dieser Wohnung mit einem Mädchen und drei Katzen. Und ich bin von allen der am wenigsten Trinkfeste, das kann ich dir sagen. Okay, du liegst als erster drunter, unter dem Tisch. 100 Prozent, ich muss das nur angucken und dann liege ich schon. Ja, okay, da musst du mit unfairen Methoden kämpfen, da musst du dir selber immer ein alkoholfreies Bier geben lassen und ihm eins mitgeben.

Äh, ich denke mal drüber nach, wie ich diesen Plan genau implementiere. Mhm. Alles klar, du hast auf jeden Fall noch ein Jahr Zeit. Ähm, also mehr als genug Zeit, dir was zu überlegen. Genau, und vielleicht hast du ja Glück und bis dann ist der Bug ja dann doch gefixt und dann kannst du deinen ganzen Plan abblasen.

Nö, dann tut nämlich den nächsten Bug. Ich habe viele Firefox-Bugs. Ja, dann halt die. Alles klar, genau, wenn euch die Folge gefallen hat, dann liked sie und subscribe seid ihr ja schon und kommentiert, entweder in unserem Community Slack gerne oder zum Beispiel auch was ihr mit dem Foreign Object Element so treibt, oder schickt einfach irgendein Lebenszeichen in unsere Richtung auf Mastodon oder Blue Sky und wir hören uns nächste Woche wieder, genau, ich habe den Oliver Schöndorfer angeschrieben, wegen Font-Geschichten.

Haben wir ja darüber gesprochen. Der hat Bock. Vielleicht ist das dann auch schon die nächste Revision. Das wäre doch mal was. Alrighty, dann schönen Abend allen, schönen Tag und vor allem dir auch, Peter. Danke und zurück. Dankeschön. Bis zum nächsten Mal. Tschüssi.

Anmelden oder registrieren

Jetzt

0:00 / 0:00