Transcript
[0:00] Das heißt, diese ganzen Beknackten, die da immer so im Internet rumlaufen und irgendwie sagen, ja, HTML sollte weiterhin ein Dokumentformat sein und diese ganzen User-Interfaces werden einfach jetzt per, WebAssembly-Kompiliertem-Qt jetzt umgesetzt, das ist der einzig richtige Weg vorwärts.
Und diese ganze Diff- und Button-Geschichte, das ist ja nix.
Ha! Das HTML-Bestandteil, das jetzt nur sich um Scripting dreht und das nicht das Script-Element selber ist. Mhm. Suck it!
Das ist auf jeden Fall eine coole Erkenntnis. Problem gelöst, würde ich vor allen Dingen sagen, also...
Working Draft Revision 586.
[0:33] Music.
[1:03] Kennst du das auch? Du willst mit einer neuen Technologie starten, aber das Internet ist zu voll mit wirrem Content in verschiedenster Qualität? Du suchst kompaktes Wissen, was dich direkt produktiv macht, mit echter Erfahrung von Experten und Expertinnen, die für deine akuten Fragestellungen da sind? Dann solltest du mal im TrainerInnen-Netzwerk von Workshops.de vorbeischauen. Hier findest du eine Community aus über 80 TrainerInnen, welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden, um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen. Es gibt sowohl Intensivschulungen über mehrere Tage, als auch Masterclasses, welche dich über einige Monate unterstützen.
Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung oder, möchtest du dich selbst als Trainerin einbringen?
Dann bist du bei workshops.de genau richtig. Schau einfach mal vorbei für alle Informationen.
Workshops.de Wir freuen uns auf dich.
Revision 586: Neues in HTML und Co, Teil 2 von 3
[2:20] Hallo und willkommen zu Revision 586 von Working Draft. Heute haben wir am Start den Shep. Hallöchen.
Und meine Wenigkeit. Und außerdem am Start haben wir wieder eine lange Liste von HTML-Features.
Wir machen einfach weiter mit Teil 2 unserer Tour durch die angedachten Features, die möglicherweise Gegenstand sind von einem State of HTML, der da möglicherweise dieses Jahr kommt oder auch nicht.
Man weiß es nicht.
Und ich hatte das ja so verstanden, dass wir dort irgendwie die spektakulären, die heißen, die neuen und die spannenden Features von HTML besprechen Und auf unserer Liste jetzt als Nächstes steht Tabindex.
Tabindex-Attribut
[2:55] Ja, ich glaube, das soll ja so eine Mischung sein aus eben neu und aber auch neuen Attributen oder neuen Elementen, aber eben auch erforschen, was an vielleicht uralten Elementen denn überhaupt zum Einsatz kommt.
Also, es gibt ja einfach so, sagen wir mal, etwas mit Liebe unterversorgte Teile von HTML schon seit jeher.
Du meinst die Image Maps?
[3:20] Image Maps zum Beispiel, genau, die müssten eigentlich mal wieder zurückkommen. Nein, Quatsch.
Ähm, ja, wobei ich sagen würde, das Tab-Index-Attribut, also, ich glaube, dass das eigentlich schon relativ häufig im Einsatz ist.
Wahrscheinlich zielen die darauf ab, zu fragen, wie man es benutzt und ob einem bewusst ist, welche Werte was irgendwie bewirken.
Genau, also man kann ja Tabindex mit einer Null bestücken, dann gibt's minus eins und, Dann gibt es ja noch die positiven Zahlen.
[3:57] Da hat sich ja so ein bisschen etabliert, dass man diese positiven Zahlen nicht verwendet, weil man damit sozusagen händisch eine Tab-Reihenfolge modelliert im Dokument und das meistens schief geht, wie alles, was man versucht per Hand irgendwie zu machen, was der Browser sonst automatisch tut.
Also man nimmt im Prinzip ja dann die Rolle des Browsers ein, die Reihenfolge zu bestimmen und zwar ganz, wenn man nicht so was macht wie einfach minus eins, Also wenn man sozusagen mehr macht, als den Startpunkt zu setzen.
Ja, genau.
[4:31] Und, tja, also im Grunde geht das eher schief, als dass es irgendwie hilft.
Vielleicht könnte man auch sagen, man könnte es dynamisch anpassen, wenn man weiß, dass ein Container möglicherweise durch ...
Durch irgendwie CSS und Flexbox oder so was in seiner Reihenfolge umsortiert wird.
Aber auch da muss man sich schon gut überlegen, ob man das möchte.
Ansonsten ist eigentlich der vorwiegende Einsatz von Tabindex Null und Minus Eins.
Wobei Minus Eins quasi ja bedeutet, man kann es nur per JavaScript, also programmatisch fokussieren, wenn ich mich recht erinnere.
Und Null ist, ich kann ein Element auch sozusagen ohne JavaScript per Tab-Key, fokussierbar machen für die Benutzerinnen und Benutzer.
Genauso fasst das auch den nonnormative Teil der Spezifikationen zusammen, den ich jetzt hier mal aufgemacht habe.
Und steht auch drüber, ne, developers should caution, blablabla, positive Werte vielleicht lieber sein lassen.
[5:37] Ja, und das war's eigentlich schon, ne, mit TabIndex. Ja, ist halt die Frage, wie man sozusagen den State of TabIndex eigentlich so findet.
Weil ich meine, die Idee, das halt eben so numerisch zu machen und zu sagen, ja, kannst du tatsächlich auch komplett von vorne bis hinten durchziehen, aber lass es halt lieber sein, hört sich ja für mich an, als hätte das sich irgendwer ausgedacht, so, ah, das ist die erste Lösung, wir geben halt einfach per Zahl an, in welcher Reihenfolge das passieren soll und fertig.
Aus einer Zeit stammend, als irgendwie so superkomplexe Webapplikationen, die von sieben Teams auf einmal zusammengeschustert werden, halt noch nicht so auf dem Schirm waren.
Man irgendwie so Tab-Groups oder irgendwie so Scoping von den Dingern, dass man tatsächlich sagen kann, innerhalb einer gewissen, eines gewissen Bereichs will ich das kontrollieren, aber sozusagen außerhalb dessen will ich nicht in den normalen Flow einklinken.
Ja, das macht absolut Sinn.
Und wäre im prinzip ja eigentlich das gleiche wie der die ursprüngliche idee bei denen bei der html5 outline wo man sozusagen überschriften levels in sections und articles dann sozusagen wieder resetten kann.
[6:46] Wäre nicht verkehrt wenn ich glaube ich auch eine gute gute erweiterung von html.
Ja, die Frage ist, macht das nicht Shadow DOM?
Also, da kann man ja auch rein fokussieren.
Hm ... Also, ich weiß es jetzt nicht. Genau, also, ich glaube, dass du, was Web Components angeht, da ein bisschen bewandter bist.
Ich nutze sie ja nicht oder eben nur irgendwie Teilaspekte davon, die ich dann irgendwie für ... zu anderen Zwecken missbrauche.
Ähm, deswegen weiß ich gar nicht, Ich weiß gar nicht, wie Web Components das regeln.
[7:24] Aber klingt, müsste ja eigentlich, also macht schon Sinn, was du sagst.
Also ich klicke jetzt gerade ja wirklich nur spontan durch die, ach guck hier, aha, ich habe in den Spezifikationen, in den HTML-Spezifikationen jetzt gefunden, dass es das Konzept des Focus Navigation Scope Owners gibt.
Und dieser Focus Navigation Scope Owner ist, wenn ich mich nicht täusche, genau, der hat eine Tab-Index-Order-Focus-Navigation-Scope.
Da drin ist dann diese Reihenfolge aufgebaut und Focus-Navigation-Scope-Owner sind Documents, Shadow-Hosts, Slots oder Elemente in Popover-Showing-State.
Also damit die Popovers, über die wir ja letzte Folge gesprochen haben, die dann über was drüber liegen, auch ihren eigenen Scope bekommen, dass man ein Popover designen kann mit Tabindex 1 bis 7 und genau weiß, dass man damit nicht das Dokument, in dem der Popover dann kommt, kaputt macht.
So lese ich das jedenfalls jetzt ganz spontan.
Das ist auf jeden Fall eine coole Erkenntnis.
Problem gelöst, würde ich vor allen Dingen sagen. Also braucht man kein neues Feature.
Können wir einfach sagen, Tabindex ist gut. Und wenn man tatsächlich diese ganzen Features benutzt, dann kann man tatsächlich ja...
[8:32] Vielleicht auch die positiven Tab-Indexe nehmen, da, wo sie gebraucht werden.
Da muss man sie halt eben in Shadowhost reinpacken, aber ich glaub, das wäre ja eventuell ein okayer Trade-off.
Ja, das ist ja, nachdem wir, ich glaub, letztes Mal haben wir ja darüber gesprochen, dass Webcomponents ja auch so ein paar Accessibility-Probleme aufwerfen.
Aber das wär jetzt ja mal sozusagen eine Lösung, die die bieten für ein bestimmtes Problem.
Ich weiß nicht, ob ich das unter dem Begriff Web Component rubrizieren würde, ganz ehrlich.
Das ist bloß Shadow DOM, das ist eine Technologie, die man ja, so wie du ja, auch einfach verwenden kann, um sein Performanceproblem in den Griff zu bekommen.
Und ich glaub, Web Component ist mehr so ein breiteres und sehr, sehr nebulöses Konzept. Da weiß ich noch ...
[9:17] Naja, du meinst, genau, ich meinte nur, dass es eben zurückzuführen auf ein Feature, das unter diesem Web Component-Umbrella dann eben bereitsteht.
Ja, darauf lasse ich mich ein, das ist okay. Aber das sind definitiv keine Web-Components, sondern einfach nur ein Focus-Navigation-Scope-Owner.
Mhm. Aber es wäre cool, wenn man den auch irgendwie anders setzen könnte.
Na ja, es gibt ja ein Proposal für deklaratives Shadow DOM, das ist, glaube ich, auch noch irgendwo in der Liste drin.
Das könntest du dann ja machen, dass du sagst, wie geht das, ein Template mit einem Tag Shadow Root Mode, und dann kannst du da angeben, Open oder Closed, wenn du ein Open- oder Closed-Shadow DOM bist.
Wenn du's deklarativ runterschreibst, ist das so, dass du dein Markup nur in den Shadow Host reinhängst, umfasst durch das Template, glaub ich, oder so was.
Wahrscheinlich kann man das nicht hinhängen. Ja, genau. Aber du musst dich dann auch um die restlichen Implikationen wieder kümmern.
Dass dein CSS irgendwie ... Dass du das dann auch wieder da drin brauchst, weil das von außen nicht reinkommt und so Schnickschnack.
Es ist fast so, als wäre auch diese ganze Shadow-Dom-Idee gar nicht mal so ausgegoren. Ja.
[10:31] Ja, genau, also, ich find's, äh, genau, es ist ein guter, äh, Steigbügelhalter, sag ich mal, um dieses, diese Idee, die wir formuliert haben, mit den quasi Tab-Index-Unterwelten irgendwie zu realisieren.
Aber irgendwie halt...
Ein bisschen zu, mit zu vielen Nebenwirkungen. Entweder das oder eben für sehr spezielle Scopes.
Also, ich meine, wenn du irgendwie jetzt sagst, ich brauch jetzt irgendwie so ein Widget da drin, und das braucht aus irgendwelchen Gründen seine eigene isolierte Tab-Reihenfolge, weil ich mein, das betrifft ja selten dein ganzes Dokument, weil das meiste von den meisten Web-Applikationen ist ja alles gleichförmig.
Aber du hast halt irgendwie so ein dein spezielles Widget drin, und da musst du halt deine Tab-Reihenfolge separat definieren, dann wäre das ja eventuell trotzdem vertretbar, diesen Aufwand dann auch zu betreiben, um dieses eine spezifische Problem zu lösen.
So 80-20, die 20 Prozent müssen halt auch irgendwie gemacht werden.
Und dann fließt halt eben 80 Prozent der Energie rein, ist ja okay.
[11:32] Ja. Ich find ja, meine liebste Brutalo-Variante, um das zu machen, ist einfach per Build-Tool in so ein Web-Component-Modul einfach CSS, so per Import-Statement reinzuhauen, dann einfach in so ein Style-Tag ins Shadow DOM reinzuhauen.
Das zuckt die Oberlippe des Performance-Pups ein bisschen, aber es ist definitiv der absolute No-Brainer, der garantiert auch funktioniert.
Ja, das ist ja nicht in Performante, oder? Also gut, es wird halt mehr geladen. Äh ... also, ja.
Mehr geladen. Du hast dann ja auch die ganzen Style-Elemente sind ja auch dann dupliziert.
Also jede einzelne CSS-Rule und jeder einzelne Style-Sheet nicht alles.
[12:08] Und das sind ja dann so bei unter anderem den firmen mit denen ich mich da so rumschlage da ist ja das css das das passiert ja mehr so das wächst jedes buch hat ja so das ist ja dann ist das teilweise gar nicht mal so wenig.
[12:21] Ja. Ich erlaube mir kein urteil darüber. Ich schweige.
Ja du du darfst das ein bisschen kontrovers sein hier so meinung personality okay komm machen wir deckel auf den tab index drauf machen wir.
So, was haben wir als Nächstes? Structured Data. Ja, wollen wir uns alles vorknöpfen?
Structured Data
[12:42] Structured Data, weiß ich nicht.
Haben wir ja schon mal eine extra Revision auch zugemacht. Ist zwar auch schon eine Weile her.
Ich glaub, mit dem Yoshi damals.
Genau, die sollten wir auf jeden Fall noch mal verlinken in den Shadow Notes. Äh, Shadow Notes.
Show Notes. Guten Morgen.
Naja, vielleicht bei dieser Folge sind's dann Shadow Notes. Ah ja, ich bleib bei meiner Auffassung zu diesem ganzen Structured Data, dass das ein weiteres Symptom davon ist, dass große Teile des Internets für Maschinen gebaut sind und Menschen da eigentlich nicht mehr viel zu melden haben.
Betrifft nicht nur Kochrezepte, aber halt auch so was.
[13:21] Ja, genau. Und mein Take ist, dass sich das ja alles irgendwie mittlerweile aus dem HTML raus in JSON-LD verlegt hat.
Das erwähne ich dir hier gar nicht. Interessant.
Ja, ich glaube, das sind jetzt hier nur die verschiedenen Microdata-Standards, die es gibt.
Und die Darreichungsform ist ja dann klassisch einfach irgendwie ein, argumentiertes Markup, HTML-Markup, oder eben neuerdings JSON-Strukturen Strukturen in Form von JSON-LD, was ich persönlich...
[14:03] Angenehmer finde auch tatsächlich. Hm.
Ich komm, ich hab wie lange ... Ja, bitte? Ich wollte zum nächsten Punkt sprengen schon.
Ach so. Ich wollte nur fragen, wie lange es wohl dauert, bis HTML das erste Attribut raushaut, wo sie einfach aufgeben und sagen, komm, da kannst du deine Daten jetzt als JSON reinschreiben.
Ja. Also, ich mein, theoretisch kannst du das ja in jedes Attribut, wenn du es korrekt escapest alles.
Ja. Hab ich auch schon gemacht. Ja, klar, natürlich, sicher, grad bei Web Components super Sache.
Aber es fühlt sich ja schon immer so ein bisschen illegal an, wenn man sozusagen seine eigene Subsyntax da ins HTML einbaut.
Okay, jetzt kann man natürlich sagen, das machen die ja bei HTML auch mit Source Set und Krams.
Aber trotzdem, ich bin mal gespannt, wann das kommt.
[14:51] Na gut, gehen wir zum Nächsten, komm. Da hab ich mehr Ahnung von. Oh, wait.
Genau, Content Security Policy.
Ich denke auch, dass wir da nicht uns lange drauf irgendwie aufhalten, aufhalten sollten. Ich glaube, das ist halt hier reingewandert, weil das so Web-Plattform-APIs sind, die irgendwie nicht so JavaScript-lastig sind, und sich eher so in HTTP-Header-Regionen abspielen.
Und die wahrscheinlich einfach eben dann bei den anderen Surveys nicht zum Tragen kommen. CSP ist, von der Idee her gut, aber eben sehr aufwendig umzusetzen.
Wir haben das bei uns im Projekt und haben halt megalange quasi das einfach nur, gemonitort, also auf Report-Mode gehabt, um im Laufe der Zeit so all die Dinge abzufangen, die dann so passieren.
Und haben das dann erst nach langer Zeit wirklich scharf gestaltet.
Und das wäre jetzt auch meine Empfehlung, weil das ist wirklich, erstaunlich was also was das für ein kniffliges konstrukt ist so eine Content-Security-Policy aufzusetzen.
[16:07] Ja, ist auch was. Das merk ich immer nur, wenn ich mit irgendwelchen I-Frames experimentiere, und dann geht's halt irgendwie nicht.
Mhm. Und dann ist es tatsächlich gar nicht so einfach, wenn man sich nicht da systematisch reingefuchst hat, sondern nur so, ich will was ganz anderes erreichen, und jetzt steht mir das im Weg, was mach ich da?
Genau, wobei, ich weiß nicht, ist es dann diese ...
Diese I-Frame- oder Embedder-Policy, also quasi dann ...
Also das, was früher X-Frames war, glaub ich, wo du darüber gesagt hast, ich darf nicht woanders eingebettet werden als iFrame.
Da hast du ja eh keine Schnitte, also wenn das jemand setzt, dann ...
Nee, nee, nee, es ist mehr so Cross-iFrame-JavaScript-Gewinsel. Okay.
Was selbstverständlich alles nicht Dinge sind, die man machen möchte, aber wenn man irgendwie so eine Sandbox haben will, um Dinge auszuprobieren, die eigentlich nicht gehen sollten, was mein täglich Brot ist, dann liegt das iFrame so nah, aber dann ist dann die Content-Security-Policy, wenn man da auf irgendeiner Online-Sandbox rumspielt, ja, meistens dagegen.
Ja. Was ja auch richtig ist. Auf jeden Fall.
Da kommen wir, glaub ich, auch noch später möglicherweise zu, je nachdem.
Da war ja noch was mit iFrames und so.
Mhm.
[17:25] Genau. Dann jetzt kommen im Prinzip zwei Web-Components-Punkte. Und der ...
Part-Attribut
[17:32] Das eine ist das Partattribut, mit dem man Teile vom Shadow DOM wieder in Slide DOM exposen kann, glaub ich, zur Bestückung und Stylung und so weiter.
Nee, nicht ganz so. Aber du hast ja, ich kann es kurz erklären, wenn du so ein eingebautes Widget hast, wie irgendwie ein Number Input oder ein Slider oder so, dann besteht das ja mit seinem internen Aufbau auch aus Shadow DOM und irgendwelchen DIVs.
Und die kannst du ja in CSS adressieren für jeden Browser einzeln über Pseudo-Elemente.
Elemente. Doppelpunkt, Doppelpunkt, keine Ahnung, Slider oder sowas. Und das ist im Prinzip so ein selbstgebauter Pseudo-Element-Konstrukteur. Du verwendest in deinem Shadow DOM das Part-Attribut und schreibst da dann halt irgendwie einen Namen rein und dann kann halt eben jemand von außen in dieses Shadow DOM rein stylen mit Doppelpunkt, Doppelpunkt, Part und dann in Klammern den Namen von dem Teil, den man da halt eben adressieren möchte. Ist jetzt nicht so ein First-Class-Pseudo-Element, aber halt sozusagen eine Funktion zum Adressieren von mit Part ausgestatteten Dinger da im Inneren.
[18:39] Okay, und genau, dann ist Slot das Ding, um quasi Teile des Shadow Doms bestücken zu können.
Und eben das ist dann auch im Light Dome sichtbar, richtig?
Das ist sozusagen ein Portal im Shadow Dome, wo du dann den Light Dome-Content reinprojizieren kannst.
Also die andere Richtung, nicht Shadow Dome ins Light Dome exposen, sondern Light Dome ins Shadow Dome holen.
Okay, die Sachen sind aber dann auch bei Query Selector All dann aus dem Light Dome ausgreifbar, richtig?
Genau, denn die sind ja tatsächlich Bestandteil des Lightroom.
Es ist wirklich so ein Portal, so eine rein Beam-Geschichte.
Das macht dann auch alles sehr viel Sinn, weil das fühlt sich halt eben wirklich an wie ein richtiges HTML-Element, wenn du halt irgendwie eine Tabelle hast oder so was und du schreibst in das TD-Element irgendwelchen Content rein.
Okay, Tabelle ist jetzt ein blödes Beispiel, weil das macht nicht wirklich irgendwie so Shadow DOM.
[19:31] Aber zum Beispiel hier, lass mal kurz überlegen, ein Dialog, ja, so ein akkordeonartiges Teil.
Genau, das ist ja ein gutes Beispiel dafür. Das macht ja irgendwie so ein Ding, wo du draufklicken kannst mit Aufklapp-zu-Klapp-Logik und kleines Icon und so Zeug.
Aber dein Lightroom ist da reingebeamt, aber für dich ist das eben eine Blackbox.
Und genau das machst du halt eben mit den Slots. Und mit dem Part machst du die ganzen Einzelteile da exposebar.
Und das ist alles so irre aufwendig, dass ich wirklich behaupten würde, das wird am Ende so gut wie niemand machen, außer halt so Sachen wie, was du in letzter Folge erzählt hast, Was war das, ein Chromecast-Widget?
Mhm. Das wirklich sagt so, wir gehen jetzt diesen etwas oldschooligen, 2.0-igen Ansatz von so Mixins oder so Embeddables, das macht man ja heutzutage eigentlich gar nicht mehr.
[20:17] Also für die ist das natürlich super, weil die wirklich sagen können, ich biete für meine Webcomponent eine JavaScript-API an und eine HTML-API, das sind dann eben diese Slots, und eine CSS-API halt eben über die Part-Selektoren.
Das könnte man alles machen, aber das wird halt wirklich behaupten, Sollten die Webcomponents jemals richtig Gas geben, wird das wirklich einfach nirgendwo stattfinden, weil die meisten Leute am Ende doch Code-Reviews sagen, aber am Ende doch eine Deadline haben und sagen werden, ich brauche jetzt hier mein Click-Widget für mein eines Projekt.
Die werden das nicht verwenden. Behaupte ich.
Ja, ist auch nicht unwahrscheinlich. Und der nächste Teil hier, das ist, glaube ich, da, das wäre ganz gut gewesen, wenn wir über das Template-Element Element letztes Mal auch gesprochen.
Und genau dessen, glaub ich, Nutzlosigkeit oder so was. Oder sagen wir mal Feature-Armut. Jo.
Und ich weiß nicht, ob wir da irgendwie, ob ich da auch erwähnt hatte, dass es ja irgendwann mal so ein Proposal von Apple gab.
Schon ewig her. Und ich glaube, das ist dieses DOM-Parts, was hier auch aufgelistet ist.
Oder es ist quasi daraus entstanden. Ähm ...
Weil da sind jetzt nicht nur Apple-Leute dabei, Auch hier der Justin Fagnani oder wie der heißt, der ja hier zum LIT-Team gehört.
Mhm.
[21:41] Die haben nicht mal ein richtiges Standardsdokument, deswegen kann ich darüber nix sagen.
Das ist weit unter meiner Wahrnehmungsschwelle.
Ja, es geht im Prinzip einfach nur ...
Ich glaube, es geht letztlich darum, ähm, so ein Template, äh, String zu verdrahten mit ...
Also Stellen zu verbinden mit eben Variablen. Und wenn die sich eben aktualisieren, wird das dann eben automatisch auch im Rendering aktualisiert.
Ja, das ist natürlich, hatte ich, glaube ich, letztes Mal auch schon erwähnt, so ein wunderbares Ding, wo man sich so denkt, das kann ich mal eben implementieren, aber die letzten paar Prozent, das richtig hinzukriegen, ist halt relativ schwer.
Also eigentlich wäre es tatsächlich ja von der klassischen Webstandardsphilosophie her schon was, was sich zu standardisieren lohnt, weil das, was die auch in ihrem Explainer hier verlinken, ist halt, alle benutzen sowas.
[22:35] Ja. Aber das wird noch schlimmer werden als Module, wenn die am Ende sagen, es wird jetzt diesen einen offiziellen Weg gehen, den wir da beschreiten.
Das wird schwierig werden, weil da werden halt ganz viele sagen, ein spezieller Use Case, und dann werden sie es doch per JavaScript nachbauen.
Und dann hast du die Volksfront von Judea im Browser eingebaut und die judeische Volksfront, die dann trotzdem das noch mal per JavaScript sich schleppt.
Schwierig. Ich überlege, ob man da nicht lowleveliger Das Knifflige ist ja der Update-Mechanismus.
Und das ist ja meistens so gelöst, dass man irgendwie so eine Art DOM-Diffing-Geschichte hat, dass die Programmierer so ein deklaratives Modell haben.
Hier sind Daten, mach das DOM drauf, und hier sind neue Daten, pass das DOM entsprechend an.
Was ich glaube, was man vielleicht eher standardisieren sollte, wäre so eine Art innerHTML 2.0, was halt irgendwie einen DOM-Diffing-Algorithmus beschreitet.
Weil ich glaube, da wäre es einfacher, einfach aufgrund des beschränkteren Scopes und der Abwesenheit von irgendeiner weiteren Sonntags, eher so eine Lösung zu bauen, dass man sozusagen das Problem outsourced und dann kann man da irgendwelche Dialekte, die irgendwie Strings passen, mit irgendwelcher Syntax davor klemmen und dann wird das Problem insgesamt kleiner für die ganzen Frameworks.
[23:47] Ich glaub, das fänd ich eigentlich eher ganz nett, weil diese ganzen Domdiffing-Geschichten, die sind wirklich, abgesehen von React mit diesem Überkomplizierten, ja wirklich, wirklich, wirklich alle gleich. Mhm. Ja.
Ja, und vielleicht gibt's dann auch Lösungen für bestimmte Probleme, die mal halt irgendwie schwer zu vermeiden sind, wie Fokus ist im Input, Input wird gedifft, Fokus ist weg.
Ja. Das hat man regelmäßig und manchmal auch nicht, weil der Input selber aktualisiert wird, sondern weil, ich weiß nicht mehr genau, ich glaube, wenn davor quasi Elemente verschwinden, und die rausgenommen werden und der Input quasi dann höher wandert sozusagen im Quelltext, dann passiert das auch.
Also ... ja, das wär, glaub ich, das stimmt.
Das ist eine sehr, sehr, sehr gute Idee.
Da sind halt erst genau die ganzen kniffligen Sachen. Wenn du dich wirklich hinsetzt und sagst, ich will jetzt Dom-Diffing bauen, du brauchst für 98 Prozent der ganzen Sachen weniger als 100 Zeilen.
Du brauchst bloß irgendwie so einen Tree-Abgleich und halt Attribute abgleichen und so.
Das ist nicht schön, weil die APIs alle für den Arsch sind, aber im Prinzip brauchst du eine große Wild-True-Schleife. Mhm.
[25:06] So. Aber wenn's halt eben an so Fokus geht, und da sitzen Event-Listener drauf, die so irgendwie mit On-Click draufgesteckt wurden, so ganz old school.
Ja, das ist natürlich dann richtig eklig, ja. Das sind die schwierigen Sachen. Und das eigentlich Schwierige ist darin, okay, man muss das irgendwie managen, man muss teilweise auch Entscheidungen treffen.
Wie verhalte ich mich jetzt? Wenn es einfach nur zwei falsche Antworten gibt, muss man sich für eine von den beiden entscheiden. Und man muss wissen, dass die ganzen Probleme existieren.
Und das ist, glaube ich, das Mithärteste, weil gerade diese ganzen Details wie, so ein On-Click-Event-Listener oder Fokus-Zeug, Das hat man gegebenenfalls nicht auf dem Schirm.
Da könnte die Plattform wunderbar sagen, so, hier läuft das jetzt wie beim HTML-Parser auch, hier gibt's nur falsche Antworten, das ist jetzt die offizielle.
Was ich übrigens auch gerne hätte, ist eine Möglichkeit, die Art eines Tags mutieren zu können.
Also, das find ich halt auch manchmal gut. Weil du momentan ja nur ...
Na ja, wenn du aus einem Diff einen Span machen möchtest. Also, dass du quasi, äh, dass du ihm sagst, nee, sei ab jetzt ein Span, bitte.
Weil du kannst das ja nur realisieren, indem du das Diff quasi wegnimmst und ein neues Span createst und wieder einhängst.
Ja.
Und ich fänd's, glaub ich, gut, wenn man das eben anders machen könnte. Ähm ...
Aber was machst du dann mit irgendwelchen JavaScript-Referenzen auf das Diff?
[26:35] Also du hast eine Variable und da ist das Diff drin und dann wird ein Mutationsschritt ausgeführt. Was passiert dann?
Ja, dann müssten die natürlich, dann werden die halt weg.
Du willst ja auch keinen On-Click-Händler wahrscheinlich und so Sachen behalten.
Also die JavaScript-Variable ist dann weg?
Ja, oder sie ist im Prinzip, sie hat keinen, sie zeigt auf nichts mehr.
Sie könnte, wenn sie, wenn es eine Weak-Web wäre, könnte sie Garbage-Collected werden.
Das ist das Ding, wenn sie eine Weakmap wäre, wenn das alles WeakRefs wären, dann wäre das ja alles kein Problem.
[27:10] Aber ich meine, wie machst du das dann? Das Problem hast du ja so auch.
Also, wenn du das Diff quasi löschst ...
Und ein Span, Creators und an der Stelle einhängst, ändert sich daran ja auch nichts letztendlich, an dem Problem, das du grade beschrieben hast.
Na ja, doch, deine JavaScript-Variable hat einen definierten Wert.
Den von dem Diff vorher. Das ist ja dann noch da, nur halt nicht mehr im DOM.
Ja, dann bitte gerne auch so. Mhm.
Nur eben ohne dieses quasi rauslöschen müssen und neu createn und wieder einhängen.
Also, das find ich irgendwie umständlich.
Aber was du ja eigentlich wirklich suchst, wenn ich dich jetzt richtig verstehe, ist ja eine Developer Experience und nicht eine technische Lösung für irgendein Problem.
Ja, das stimmt wohl. Mit dem einen Unterschied, das ist vielleicht dann auch so was wie, wenn der Fokus auf dem Element wäre.
[28:09] Das mutiert wird, eben der Fokus möglicherweise dann auch darauf bliebe. So.
Ja. Also im Prinzip aber auch develop experience, weil ich könnte vorher gucken, document active element, ist das eben dieses?
Dann merkt ihr das, Kicks raus, bauen neues, hängst ein und steckt dann den Fokus wieder drauf.
Weil ich glaube, das wäre wirklich die Lösung, die ich nehmen würde.
Ich würde halt wirklich eine Funktion bauen, die kann man dann ja gerne irgendwie transmutate oder so nennen.
Aber die müsste unter der Haube halt wirklich diesen Swap machen.
Also sprich neues Element erzeugen, von dem alten alles rüber kopieren, was du rüber kopieren willst, den Fokuszustand auch wieder herstellen und dann am Ende austauschen.
Mhm.
[28:51] Äh, das wäre am sinnvollsten, weil, als du das gerade erwähnt hast, was du gerne hättest, ist mein Gehirn sofort zu einem Experiment hingegangen, das ich letztens vollführt habe.
Wir haben ja letzte Folge über dieses Membranenproblem gesprochen.
Also, ich habe eine Web-Component, da drin ist ein Select-Element, und meine Web-Component soll sich wie ein Select-Element verhalten, nur halt mit vorkonfigurierten Options.
Aber es soll im Prinzip die ganze JavaScript-API und die Formularbenutzbarkeit von einem Select-Element exposed werden.
[29:18] Und mein krankes Hirn ging natürlich erstmal sofort zu den JavaScript-Proxys, dass ich ja im Prinzip da Magic Keys machen kann. Wenn ich also auf meiner Web-Component irgendwie einen Property-Access durchführe und der ist auf der Web-Component nicht definiert, dann delegiere ich das weiter an irgendein Delegate-Target im Shadow DOM.
Stellt sich raus, geht nicht, weil man nicht ein HTML-Element, eine Web-Component, ein Custom-Element bauen kann, was ein Proxy ist, was einfach nur am Upgrade-Mechanismus liegt, Webcomponent-Element wird gepasst, unknown element, dann erst kommt das Skript, wo drinsteht, das ist eine Webcomponent, und dann muss ja nachträglich geupgradet werden.
Und das ist ja im Prinzip genau das Gleiche, was du gerade beschrieben hast. Es ist erst Tag so und so, und dann soll es zu Tag so und so werden.
Aber was halt genau nicht geht, ist dieser Switch von dieses Ding ist jetzt etwas komplett anderes wegen diesem, also mehr oder minder dieses dangling-variablen Problem, weil du am Ende sonst bei, Konstruktionen landest oder bei Zuständen landest, wo du wirklich na ja, zwei Objekte hast, die von sich behaupten können, ich bin dieses Element.
Aber sie müssen halt fundamental unterschiedlich sein. Das eine muss ein Diff sein, das andere muss ein Span sein.
Und das führt halt zu extrem unangenehmen Problemen.
Weswegen man, wie gesagt, das bei dir besser über so einer Developer-Experience lösen sollte.
Und ich sollte meine Membranen-Idee am besten in die Tonne treten.
[30:38] Weil das wird so nicht funktionieren.
Ja, aber gut, dass du's erforscht hast.
Ich hab dann auch die einzige Stelle gefunden, wo in den HTML5-Spezifikationen wirklich ECMAScript-Sprech drinsteht.
Und so interne ECMAScript-Methoden aufgerufen werden, die wirklich durch diese Proxy-Grenze durchgehen und sagen können, ich schmeiß eine Exception, wenn ich nicht definitiv feststellen kann, dass dieses Ding auch wirklich ein X ist.
Und wenn's ein Proxy auf X ist, dann Exception.
Es ist sehr obskurer Randbereich, aber es war sehr frustrierend, rauszufinden, dass das nicht geht und nicht gehen kann.
Damn. Na ja. Aber muss ja auch erforscht werden. Irgendwer muss es tun.
DOM Parts
[31:17] Ähm, dann lass uns doch weitergehen zu Content Editable. Ja. Überhaupt nicht neu.
Gibt's ja schon seit ... Also, hat ja der IE beziehungsweise Hotmail, glaub ich, erfunden oder so.
Hotmail hat's bestellt, IE hat's implementiert.
Ähm, und ... Ja, letztlich ist das ja so was ... Also genau, man kann ein beliebiges HTML-Element editierbar machen.
Und.
[31:46] Jetzt gibt's eben die Möglichkeit, dem noch einen Wert zu geben, nämlich Plain Text Only, der, glaub ich, also zumindest würd ich sagen, auf den man schon lange gewartet hat, damit man eben nicht das Problem hat, dass da drin irgendwelche weiteren Tags erzeugt werden, wenn man irgendwie falsche Eingaben macht oder was pastet oder so was.
Also dass das quasi, dass das, was da drin ist, wirklich ohne weiteres Markup ist, reiner Text.
So möchte man das, glaube ich, meistens haben, oder?
Ja, klar, weil dir meistens ja die Rich Text Editing API fehlt.
Und wenn du dann deinen Cursor irgendwo in den fetten Text reinbewegst.
[32:29] Weißt du halt nicht genau, was passiert, wenn du jetzt ein X drückst.
Ja.
Das ist so das Ding. Nee, ist super. Wie ist denn das mit dem Support von Plain Text?
Ah, der Firefox kann es nicht. Ärgerlich.
Irgendwas ist immer, aber grundsätzlich klingt das jetzt auch nicht so super kompliziert und vielleicht ist das ja also diese State of Surveys sind ja sozusagen immer Inspiration auch für die Browser-Hersteller, worum sie sich kümmern können und das ist ja dann so, wenn Dinge einigermaßen leicht umzusetzen sind und es vielleicht auch noch eine Menge Tests in den Web-Platform-Tests für die Dinge gibt, dann landen die eben auf dieser Interop-Liste.
Und ich glaube, dass dieses möglicherweise dort landen könnte, weil's für mich jetzt nicht so aufwendig klingt, das zu machen.
[33:20] Hm. Für mich auch nicht, aber seitdem ich mal angefangen hab, so einigermaßen regelmäßig Feature-Requests und Sachen CSS Randaspekte bei Firefox zu stellen, und ich einfach nur so die nachfolgenden Diskussionen grob verfolgt habe, glaub ich nicht mehr, dass irgendwas leicht umzusetzen ist.
Was war das? Der hat irgendwas nicht geupdatet, ne? was du haben wolltest.
Nee, das war was anderes, das hab ich auch einfach aufgegeben.
Ich hatte irgendwie ein Canvas-Element in einem ...
Ich hatte einen Shadow DOM, da drin ein Slot, da drin ein Canvas-Element, das Ganze in einem I-Frame.
Und wenn ich dann auf dem Canvas-Element irgendwelche Draw-Befehle ausgelöst habe, dann sind die nicht sichtbar geworden.
Aber wenn ich die Pixeldaten ausgelesen hab, per JavaScript-API hab ich genau gesehen, dass meine Draw-Befehle durchgekommen sind.
Also die Bitmap repräsentiert die Werte, Okay.
Aber das war ein Problem, das ich ernsthaft lösen wollte. Ich wollte Pixel anzeigen.
Ich wollte nicht wie bei den Proxys einen Beweis antreten. Dann hab ich gesagt, okay, Junge, geht das einfacher?
Und siehe da, es ging einfacher.
Sehr gut. Nee, nee, es war was mit Animationen und irgendwie so Transformsätzen in Keyframes.
Bla, Randaspekte, wo ich nur sage, hey, da müsstet ihr doch eigentlich nur dit so machen, dass das genauso ist wie in Chrome.
Und dann müssen wir das und das und das und das und das. Wenn wir das machen, wird's aber viel langsamer.
[34:40] Deswegen wird das nicht passieren.
Ja, genau. Das sind ja dann doch unterschiedliche Engines, die sozusagen unterschiedliche Unterbaus haben.
Und auch Chrome hat ja jetzt quasi seinen gesamten Unterbau ausgewechselt fürs Rendering, um wieder ...
Also, um zum einen weniger Bugs zu haben, aber zum anderen auch wieder eine bessere Ausgangsbasis für neue Feature-Implementationen zu haben.
Ja, und ich find das halt echt super und echt bemerkenswert, wie unterschiedlich die halt dann doch sind.
Ja, genau, was denen dann so leichtfällt, wie zum Beispiel der Firefox unterstützt seit Ewigkeiten hier diese Elementfunktion in CSS.
Und das ist ja quasi für alle anderen Browserhersteller sozusagen die Quadratur des Kreises.
Deswegen können die das nicht bauen. Ja.
[35:24] Ja, oder halt eben auch so, dass halt so Bugs passieren irgendwie so in einem Browser, die halt im anderen Browser einfach komplett nicht reproduzierbar sind, weil nur der eine Browser diesen spezifischen Stack plus diese Drawing-API plus diesen Rundungsfehler auf dieser Hardware halt ausprägt und der andere halt einfach gar nicht.
Und das hast du halt nur, wenn du irgendwie so Chrome und Firefox nebeneinander hältst und der ganze Rest da mit Brave und dem ganzen Gesocks, das ist alles Chrome-esk, das zählt nicht.
Mhm. Ich hatte übrigens, hatten wir letztens ein Projekt, also da benutzen wir Aviv.
Und wir hatten das Problem, dass Bilder eine so eine pinke ...
Linie an der rechten Seite, glaube ich, hatten, aber eben nur auf Android-Devices.
[36:12] Unter chrome und genau das war sehr merkwürdig weil die bilder waren im grunde okay die originale aus dem was gerechnet haben waren okay und wenn wir es in anderen browsern diese datei geöffnet haben was auch okay stellte sich heraus dass das ein einfach nur ein glaub ich hier von von klang dass er so ein kompiler oder so was ein problem war unter 32 bit android nicht unter 64 bit android deswegen war es auch nicht auf jedem android gerät produzierbar.
Und dann auch nur quasi in einem bestimmten fenster von chrome versionen die von diesem fehler betroffen waren.
Das war schon echt sehr exotisch, aber irgendwie auch so ein irre, also wie, was, wie, warum und in welchen Konstellationen sowas passieren kann.
Achso und genau, was auch wichtig war, es, genau, es waren so irgendwie Multiple von 16 musste die Auflösung haben, unterhalb von 320 Pixeln.
Also wenn man größer wurde, war es dann auch weg und wenn das, was das Bild, was man gezeigt hat, eben nicht durch 16 teilbar war, gab es den Fehler auch nicht.
Nicht, aber bei uns trafen halt all diese Bedingungen aufeinander und es war halt sehr mysteriös.
[37:26] Ha, das ist natürlich gut. Aber, also, da fühlt sich ja auch manchmal grade, wenn man nicht so tief im Thema steckt, man steckt sich teilweise wie auf dem falschen Planeten.
Ich erinnere an meine Geschichte, die hab ich Anfang des Jahres verblockt, wo ich wen hatte, der zu mir sagte, auf manchen Laptops werden die PDFs komisch gerendert, wenn die Hardwarebeschleunigung an ist.
Also, Hardwarebeschleunigung an, nur PDFs, nur auf manchen Laptops.
Und dann war das halt so eine Kombination mit einem Chrome-Bug und einem Intel-Chip.
Und da ist das halt eben aufgetaucht. Da konnte ich den Leuten dann aber sagen, bau diesen Zehnzeiler ein, der die Canvas-Get-Context-Funktion so patcht, dass ich einen Effekt auslöse, der als Nebenwirkung ein Abschalten der Hardwarebeschleunigung hat.
Dann rendert das PDF irgendwie eine halbe Millisekunde langsam, aber dann sehen die Buchstaben wenigstens alle richtig aus.
[38:16] Ja. Da haben die auch gedacht, was bist du denn für ein Voodoo-Puppenbeschwörer?
Dann dachte ich, aha, Hardwarebeschleunigung auf Canvas.
Das kann man doch bestimmt einfach austricksen. Dann hatte ich die Lösung extrem schnell.
Aber damit der Stundenzettel voll wird, hab ich hinterher recherchiert, warum das so ist.
Und ab welcher Version es gepatcht ist, damit sich das lohnt.
Unlösbares Problem, seit Wochen kauen wir drauf rum.
Dann sagst du halt eben, ah ja, okay, es ist eine Option auf Get-Context, wo du sagen kannst, mach mal keine Hardwarebeschleunigung.
Ist ja schon ein billiger Trick. wissen, was da passiert ist und einfach man das rausnehmen kann.
Das macht es ja langsamer. Es ist ja nicht eine perfekte Lösung.
Ja.
Vielleicht können wir da noch querverweisen auf einen anderen Podcast, die Igalia Chats, die sowieso sehr hörenswert sind. Und die hatten, ich glaube, vorletzte Folge oder so, also haben die über Browser-Engines und eben die speziell in die Rendering-Engine gesprochen.
Und was man eben da für einen Riesenaufwand treibt, es möglich zu machen, dass das halt mit 60 Frames pro Sekunde rendert.
Die Folge First-Person-Scrollers? Jip.
Die ist richtig richtig gut.
[39:28] Okay, das machen wir. Ja, Performance ist auch ... Allein das macht's ja unmöglich.
Also, wenn man mal wirklich was geschrieben hat, was ein kompliziertes Problem oder was man für ein kompliziertes Problem löst, und dann sagt man, ich mach das jetzt so schnell wie's geht, dann ist das ja hinterher nicht mehr wiedererkennbar, was man da gebaut hat.
Und wenn dann irgendwer kommt und sagt, bau mal das noch eben schnell dran.
Oh-oh. Es ist halt schwierig.
Ja. Vor allem, wenn du nicht wie ein Chrome-Team die ganze Infrastruktur hast, die automatisch Performance messen und Regressionen messen, das hast du ja nicht, wenn du ein JavaScript-IOP bist, der nur einen guten Job machen möchte.
Ja, ist alles nicht so einfach, was wir hier so machen. Überhaupt nicht.
Ich hab letztens wieder dieses wunderbare ... Was war das? Ich erinnere mich nur an die Domain.
StillDrinking hieß es.
Und dann irgendwie Programming. Keine Ahnung, wie war das?
Programming sucks, genau. Das letztens wieder, das schicke ich halt immer irgendwelchen Normies, wenn die mich fragen, was machst du eigentlich den ganzen Tag und warum ist das so kompliziert?
[40:34] Schönes Essay, ein Klassiker. Okay, ja, schick mal rüber, kenn ich nicht.
Okay, alles klar. Weitere Sachen, die so ein bisschen sucky sind, sind glaube ich die Element
Plaintext-Attribut für contentenditable
[40:48] Ja, da haben wir, glaube ich, auch schon mal drüber gesprochen.
Richtig? Genau, würde ich jetzt auch nur in Kürze machen, ist halt so für Web Components, dass man die ganzen APIs hat, die Default Area Roles, Formular APIs, dass man irgendwie sagen kann, ich bin ein Formular Element und ich repräsentiere jetzt diesen und jenen Wert, dass man auch submittable ist und so. Das ist da halt eben drin.
Und das ist voll die Katastrophe, weil das alles irre komplex ist.
Wird nicht besser, indem man davon einfach mehr hinzufügt.
[41:21] Ja, sind die, der nächste Punkt, diese Extended Build-Ins eventuell mal gedacht gewesen, um das leichter zu machen?
Is-Attribut
[41:28] Das ist doch, glaub ich, dieses, ich nehme ein Button zum Beispiel und gebe dem ein Is-Attribut.
Und dann kann ich den upgraden mit extra Krempel.
Das ist sozusagen der Gegenentwurf. Also, weil du könntest ja entweder sagen, ein Formularelement manifestiert sich, Ich baue alles neu, das wären so die Element internals.
Du setzt deinen eigenen Formstate, du expost deine eigenen Area-Rules oder so.
Oder du sagst, ich hab einen Button, der soll ein bisschen was extra können, und ich mach da halt eben diese Is-Extents-Geschichte drin.
Die aber, glaub ich, nicht so auf Gegenliebe anderer Browserhersteller stößt, richtig?
Also, nur das Chrome-Team hat das implementiert, richtig?
Genau, und die anderen haben gesagt, das ist uns zu aufwendig Das, ja.
[42:13] Es ist halt auch schwierig, also was das ja im Wesentlichen macht, ist ja wirklich, also nehmen wir mal das Button-Element als Beispiel.
Da hast du das Button-Element, das rendert ja was und du kannst das anklicken, damit kannst du interagieren, du kannst es fokussieren und es hat eine JavaScript-API.
Und so wie die Extended Build-Ins bisher funktioniert haben, war, dass du im Wesentlichen eine Extension der Button-Klasse gemacht hast, wodurch du neue JavaScript-Methoden definieren konntest und das war's.
Da war nix mit Shadow DOM oder Styling dranflanschen oder so, sondern das war halt irgendwie alles.
Und ... das ist halt echt nicht viel wert.
[42:53] Also, wann willst du das schon mal? Wann willst du einfach so Buttons haben, die du erweitern willst, in dem Sinne, dass du sagst, du sollst eine extra Methode haben oder einen extra Event-Händler haben.
Das ist nicht so oft der Fall. Und dafür diese ganze Maschinerie zu implementieren, Für diesen relativ kleinen Gewinn kann ich verstehen, dass einem der Trainer das nicht ...
Kannst du da vielleicht irgendwie dann zumindest Styles reinscopen?
Ging auch nicht.
Nö, du extendest einfach nur eine Basisklasse. Okay, na ja, das ist dann ja wirklich nicht viel.
Aber natürlich ein brutaler Aufwand.
Weil du halt irgendwie sagen musst, ah, okay, im Rahmen eines Upgrades, wo ich ja nicht mehr diesen einen Spezialkase habe, dass ich meine HTML-Unknown-Element-Klasse swappen muss gegen was anderes, was ja schon kriminell genug ist, potenziell jedes Element gegen jedes andere swappen können.
Und dass man dann vielleicht sagt, das irgendwie so zu generalisieren, ist halt relativ viel für relativ wenig Gewinn, äh, schwierig.
Was jetzt nicht sagt, dass Extended Build-Ins nicht eine gute Idee wären, aber so wie hier definitiv nicht.
Weil das ist eine seltsame API für wenig Mehrgewinn.
Ich mein, du hast ja auch zwei verschiedene Arten, ein Custom Element in die Welt zu setzen, entweder per Tag oder per Is-Attribut.
Das kannst du auch schon jemandem verkaufen. Ja, da wäre übrigens auch die interessante Frage, zur Laufzeit ändert.
Das ist bestimmt auch ein fieser Dreckscase. Boah, ich würd sagen, dann hat's einfach keinen Effekt.
[44:22] Du kannst ja so was machen wie, wenn ein Element geupgradet ist, dann wird das Is-Attribut einmal ausgewertet und danach nie wieder angeschaut.
Mhm. Also, das kannst du ja einfach entscheiden.
[44:35] Das war jetzt wieder dein Case von wegen, ach, ich will Elementeidentitäten austauschen.
Ja, ich hab ja schon immer ein bisschen an den PETA gemimt und versucht, Standards kaputtzuschießen.
Oder Ideen. Ja. Ich will sagen, Extended Build-Ins, super, aber nicht so.
Das sollen sie mal ruhig sein lassen von mir aus.
Das vermisst am Ende keiner.
Also, boah, das hat halt so ein paar Use Cases, die ich mir so vorstellen könnte.
Also, so mit den JavaScript-APIs, du willst irgendwie ein Input bauen, das so vorkonfektionierte Validierungsregeln hat, so mit der HTML5-Validierungs-API.
So der einzige Use Case, wo ich mir wirklich sagen könnte, okay, ich will jetzt wirklich so ein Postleitzahlenfeld bauen und das soll dann dem Vorkonfektioniert werden mit den Validierungsregeln für deutsche Postleitzahlen. Das ist besser als irgendwie das entsprechende Regex-Attribut und so in HTML überall einzubauen, aber das ist alles einfach irgendwie zu wenig, um wirklich den, Aufriss wert zu sein. Andererseits brauchen wir meines Erachtens irgendeinen Mechanismus dafür, um diese Dinger extenden zu können, weil die Alternative hatten wir ja gerade mit den Internals, dass jeder und sein Hund eine eigene Implementierung vom Input-Element schreibt und das wird halt garantiert schief gehen.
[45:43] Ja, dann würde ich sagen, dann lassen wir diesen Kriegsschauplatz sich weiterentwickeln.
Und wir nehmen uns einen Tüte Popcorn und schauen einfach in zehn Jahren noch mal drauf.
Ich glaub, da können wir auch in zwei Jahren draufschauen. Da wird sich schon genug getan haben.
Crossorigin-Attribut
[46:01] Okay. Dann lassen wir die Webcomponents zumindest vorübergehend hinter uns.
Ich weiß nicht, ob die noch mal kommen.
Doch ein Teil kommt noch. Als Nächstes hätten wir hier das Cross-Origin-Attribut.
Reden. Denn ich glaube, also meiner Ansicht nach ist das ja so ein bisschen diffus für viele, wann man das benutzen sollte. Und ich glaube, ich würde mich jetzt auch zu denen zählen, die das in ihrer, sagen wir mal, im maximalen Detail gerade auch nicht kennen. Zum Beispiel habe ich es noch nie benutzt mit nicht-anonymen Credentials. Aber wo man drüber stolpert ist, wenn man Fonts preloadet, da muss man das ersetzen.
Und ansonsten meistens nicht. Und was da unten drunter eigentlich passiert, ist, dass in dem ganzen Network-Stack des Browsers so ein eigener, isolierter, Network-Stack aufgemacht wird, wo nur Cross-Origin-Ressourcen drüber geladen werden.
Werden aus Security-Gründen, glaube ich, dass sie sich irgendwie nicht gegenseitig abhorchen können.
[47:17] Und bei den Fonts ist es eben nötig, weil die Font-Foundries sich früher ja immer ein bisschen in die Hose gemacht haben wegen Piracy und so.
Deswegen wollten die ja auch keine TTFs oder sowas im Netz haben.
Und darum muss es ja dann WOF richten, was letztlich auch nichts anderes ist als ein ZIP, das ein TTF enthält und, glaube ich, ein Lizenzfile oder so.
Mhm. Ähm, genau. Und darum findet man dort das Cross-Origin-Attribut.
Und ansonsten würde man das eigentlich nur benutzen auf Ressourcen, die man von einem anderen Origin holt, und dann quasi auswertet und weiterverarbeitet, wie zum Beispiel, wenn du ein Bild von einem fremden Server ziehst und das in eine Canvas rendern willst, dann müsstest du das Cross-Origin-Attribut setzen.
Dann kannst du quasi, dann kannst du aber die Daten nicht mehr auslesen.
Also, weil die dann, dann kommen die von einem fremden Server.
Dann kannst du die verarbeiten, aber du kannst die nicht mehr auslesen.
Also kannst du ... Hier sind quasi ein Block, wo du nicht reingucken kannst, das hinschieben kannst. Genau.
[48:36] Einfach aus Security Gründen, dass du jetzt zum Beispiel nicht dann das Profilbild von, weiß ich nicht, Facebook in deine Anwendung laden kannst, das dann in eine Canvas rendern und die Canvas dann auslesen und dann siehst du, ah, das sind hier im Hintergrund so und so farbige Pixel, dieses Bild verwendet doch immer der Peter Kröner, das muss Peter Kröner sein.
So sieht's aus. Genau. Und wenn du das denn unbedingt in eine Canvas rendern musst, dann musst du das eben mit Cross-Origin laden und dann ist die Canvas aber quasi verschlossen. So sieht's aus.
Ja. Genau. Sonst benutzt du das irgendwie groß?
Ich baue doch keine ernsthaften Anwendungen. Damit hat sich das erledigt.
Das löst halt Probleme, wo ich mir den Safety-Engineer-Ansatz immer wähle.
Also wo ich nicht das Problem lösen möchte, sondern ich möchte gerne möglichst bei der Entscheidung darüber, was ich mache, vermeiden, dass ich darüber nachdenken muss.
Ich brauche keinen Geländer über meinem Pot von kochender Säure zu machen, weil ich hab gar keinen Pot kochende Säure.
Ich hab gar keine Fonts, die ich von Third-Party-Cross-Origin-Laden lade.
Das ist lustigerweise, bei Fonts ist das ja auch, wenn du das nicht Cross-Origin lädst.
[50:05] Also das ist dann in dem Fall bei denen einfach nur deren Paranoia gewesen. Mhm.
Also bei Fonts musst du das immer machen. Und ansonsten eben bei anderen Ressourcen, nur dann, wenn sie tatsächlich Cross-Origin sind.
Und du planst dann noch irgendwie, was Unorthodoxes mit denen einzustellen.
Ähm, genau.
Und was halt eben auch wichtig ist zu wissen, ist, wenn du ein Preload für ein Bild hast, dann darfst du im Preload nicht Cross-Origin setzen, wenn du es beim Bild dann nicht verwendest, und umgekehrt, weil dann lädst du das Bild einfach zweimal.
Nämlich der Browser lädt das einmal in dem quasi nicht Cross-Origin-Network-Stack und dann einmal in dem isolierten.
Dann hast du quasi zweimal das Bild übertragen und ist auf gar keinen Fall gepreloadet.
Aha, okay.
[50:54] Was ich auch schön daran finde, ist, dieses Attribut löst ein Problem, dass es nur in JavaScript gibt.
Das heißt, diese ganzen Beknackten, die da immer so im Internet rumlaufen und irgendwie sagen, ja, HTML sollte weiterhin ein Dokumentformat sein und diese ganzen User Interfaces werden einfach jetzt per, keine Ahnung, WebAssembly-Kompiliertem-Qt jetzt umgesetzt, das ist der einzig richtige Weg vorwärts und diese ganze Diff- und Button-Geschichte, das ist ja nix.
Ha! Das HTML-Bestandteil, das nur sich um Scripting dreht und das nicht das Script-Element selber ist.
Mhm. Suck it.
Genau, als nächstes haben wir das Input-Pattern-Attribut. Finden wir das diskussionswürdig?
Ich würde sagen, so nicht unbedingt.
Kennt jeder, weiß jeder, nutzt keiner, außer um irgendwie die Tastatur dazu zu bringen, dass sie macht, was man möchte.
Genau, dann Cores ist auch so ein HTTP-Header-Dings, find ich jetzt auch irgendwie nicht diskussionswürdig, weil haben wir schon drüber gesprochen, gibt's schon ganz lange.
Ich wette, auch beim Survey wird da jeder sagen, natürlich habe ich das schon auf irgendwie Sternchen gesetzt, damit die Kiste endlich funktioniert.
[52:10] Ja.
Genau. Funktioniert ja nur leider nicht, wenn man Credentials mitschicken muss, wie Cookies oder Basic Auth, dann das ist dann immer ein bisschen nervig.
Also warum das dann eben nicht möglich ist, mit Sternchen zu beantworten.
Ja. Ah ja.
Genau, dann kommen aber die HTTP-Client-Hints. Ich glaube, die fristen ja ein bisschen ein Schattendasein.
Client Hints und Resource Hints
[52:34] Weiß ich nicht, Shep, kannst du vielleicht zwischen 20 und 30 Minuten uns darüber erzählen, was die genau machen?
Ähm, genau, die gibt's eigentlich auch schon ganz lange. Und die erfahren, sagen wir mal, ein bisschen einen Revival.
Wofür die Gutsinn ist, du schickst eben von deinem Server aus HTTP-Header und sagst, ich hätte gerne von dem Browser noch Informationen zu, und klassischerweise war das deiner quasi Internetgeschwindigkeit oder der Anzahl CPU-Kerne.
Also gibt es so ein paar Sachen, die man sozusagen anfordern konnte.
Dann konntest du vielleicht bei darauf folgenden Requests, Das ging ja nur ab dem zweiten Request konntest du dann darauf reagieren.
Auch noch ein Ding, was wir abfangen konnten, das war zum Beispiel die DPI-Zahl des Bildschirms.
[53:25] Und wenn du das zum Beispiel gemacht hast, also wenn dein HTML-Dokument diese Header geschickt hat, dann hat ja dein Browser im Anschluss das HTML-Dokument gepasst.
Dann hat das, hat ja vielleicht die Bilder da drin gefunden, die auch wieder angefordert.
Und weil ja vorher diese Bitte um Information zum Beispiel zur DPI-Zahl des Bildschirms, über das HTML-Dokument kam, hat der Browser dann eben mit diesen Requests nach den Bildern die DPI-Zahl auch als Info mitgeschickt.
Und dann konnte oder dann kann der Server eben sagen, aha, okay, drei Pixel pro CSS-Pixel ist dein Bildschirm, dann kriegst du dieses Bild zurückgeliefert.
Das war so der Use-Case für sowas. Oder ich bin schwach angebunden, dann kriegst du eben einfach ein viel stärker komprimiertes Bild, so ein Art-Responsive-Webdesign, aber von der Serverseite aus.
[54:24] Und das war bisher so, dass auch das New Chrome das umgesetzt hat.
Ich glaube, kein anderer Engine hat das umgesetzt.
Und warum das jetzt noch so ein bisschen Revival erfährt ist, weil die ganzen Browsersteller dazu übergehen, gehen ihre User-Agent-Strings zu, sagen wir mal, also weniger Informationen darüber preiszugeben über den User-Agent-String.
Das heißt, Versionen des Browsers werden nur noch quasi ohne Kommastelle zurückgegeben.
Ich glaube, Betriebssystemen wird auch nicht zurückgegeben und so diverse Dinge.
[55:05] Und um das eben zu kompensieren, wenn man einen Use-Case hat, wo man das eben wissen muss, jetzt über auch neue kleintins sagen so dies und das und jenes hätte ich aber dann doch gerne gewusst und das ist insofern trotzdem also man könnte jetzt sagen ja das ist ja dann also dann kannst du es ja gleich über den user agency als verschicken also aber wenn das hinterher alles wieder abgefragt werden kann es ja quatsch Aber so ganz stimmt das nicht, weil es gibt so eine Art Budget, wie viele Details du abfragen kannst.
Und wenn du eben zu viel wissen willst über den Browser und dann quasi wieder Fingerprinting möglicherweise betreibst, dann sagt der Browser oder der Server sagt dann so, nee, der Browser sagt dann, das geht eben nicht.
Du kriegst nur eben dieses Subset von den Sachen, die du haben wolltest, Und ja, also letztlich wird dann Fingerprinting verhindert.
Und momentan ist das eben über den User-Agent-String eher möglich.
[56:15] Es ist ja quasi, das macht ja wirklich den Job vom User-Agent-String.
Also man kriegt da ja die Informationen raus, so mehr oder minder, die man da früher indirekt hergeleitet hat.
Genau, nur mit so einem gewissen Gatekeeping dann noch dazu obendrauf.
Drauf. Ja und abzüglich des ganzen obskuren Templer-Wissens, das du halt eben brauchtest, um irgendwie genau rauszulesen, aha, der behauptet von sich irgendwie ein Mozilla zu sein, das heißt folgendes.
Naja, und User-Agent-Sniffing für so Feature-Detection davon wird ja sowieso abgeraten.
Deswegen, also, wenn man sich daran gehalten hat, dann sollte man im Grunde nicht davon betroffen sein.
Es gibt schon Cases, wo Feature-Detection einen irgendwie nicht ans Ziel bringt.
Also einer, der mir jetzt so da eingefallen ist, ist die Gap-Property in CSS.
Die ja kein Aussager darüber trifft, ob sie auch in Flexbox unterstützt wird.
Also die kam ja mit Grid und später wurde die quasi retrofitted auf Flexbox.
Da haben die Browser ja auch gesagt, so, ja, kann ich, aber ...
Tja, in welchem Kontext kannst du das? Also sprich, jetzt Feature Detection wäre dann so per Add-Supports-Regel.
Genau. Oder du kannst ja auch CSS.Supports benutzen, wenn du JavaScript verwendest.
Ja, okay.
Ja gut, die Gap-Property, man müsste ja im Prinzip.
[57:41] Genau, es kommt auf den Kontext an, und das kriegst du mit Supports nicht abgefragt, das stimmt.
Genau, das wäre halt so ein Fall, wo du vielleicht dann so, okay, jetzt muss ich aber wirklich dann mal wissen, was das für ein Browser ist, und dann habe ich hier meine interne Liste.
Aber für Gap würdest du das dann auch nicht machen.
Also es gibt einfach Use Cases, da kommst du, die kriegst du nur raus durch User-Agent-Sniffing, Aber vielleicht solltest du dann einfach um diese Features erst mal noch einen Bogen machen.
Ja, beziehungsweise du kannst es ja generalisieren. Du kriegst das nur raus per das, was irgendwelche Blockchain-Hineys ein Orakel nennen würden.
Also Daten, die halt nicht deinem System innewohnen, sondern wo du halt irgendwo anders hingucken musst, und daraus was herleiten musst.
Ich mein, das sind ja unsere Problemchen, die wir vorhin mit Pixel-Rendering gesprochen haben, gehen ja auch in die gleiche Richtung.
Das kriegst du aus dem Browser nicht raus, zu rendern und dann die pixel interpretieren und dann daran das erkennt herrlich banane guckst lieber nach bin ich edge auf windows so und dann aktiviert den hack oder auch eben nicht ja das stimmt ja das wäre so ein so ein fall auch ja es ist halt eben auch okay aber besserer user agent string ist es Und das ist ja schon viel wert.
[58:54] Dann haben wir die Resource-Fins. Ich glaube, über die müssen wir auch nicht sprechen.
Also Preload, Preconnect, Prefetch, so das Zeugs.
Eine Frage hätte ich ja dazu. Du als Performance-Papst, weißt du irgendwie oder wie schätzt du es ein, die Wahrscheinlichkeit, dass das irgendwie auf eine korrekte, zielführende Art und Weise eingesetzt wird?
In den meisten projekten da draußen. weil ich meine das ist ja wahrscheinlich schon relativ diffizil zu entscheiden was muss jetzt mit welchem verfahren behandelt werden.
[59:33] Ja wahrscheinlich fifty fifty. also ich denke mal viele machen es gut. ich glaube dass dass man manchmal ein bisschen zu viel des guten einsetzt aber eher im sinne von es ist doppelt gemoppelt und schadet nicht. Also zum Beispiel, wenn jetzt dein Style-Sheet direkt unmittelbar nach deinen Resource-Hints kommt, dann musst du das nicht preloaden. Weil es geht ja darum, oder doch genau nicht preloaden, weil letztlich dienen ja die Resource-Hints dazu, dem Browser mitzuteilen, was er nicht selber finden kann. Oder vielleicht, was er erst relativ spät, so im Lebenszyklus des Renderings der Seite feststellt.
Und da kann man ihn halt unterstützen.
Und muss dann irgendwie nicht ein Preload in die Zeile vor das LinkRail-Style-Sheet setzen, das er so unmittelbar danach findet.
[1:00:33] Genau, ich glaube, das gibt's schon öfters. Aber das tut halt nicht weh.
Und ich kann mir aber vorstellen, manche Leute zu viele Dinge preloaden, die nicht pregeloaded werden müssten.
[1:00:50] Bei mir erscheint das ja auch ein relativ schwer beobachtbares problem zu sein und sehr schwer zu entscheiden zu sein wenn man jetzt wirklich nicht damit jetzt irgendwie primär befasst und jetzt irgendwie sich sagt ich verwende jetzt den ganzen tag darauf nicht rein zu fuchsen wie jetzt die ressourcen auf meiner seite am besten geladen werden sondern du bist irgendwie so ein täglichen grind drin und du klopft komponenten raus und das muss funktioniert werden und du musst tickets abarbeiten bla keks also das ist ja nicht rein ja also womit man das eigentlich ganz gut sich anschauen kann kann, ist mit Webpagetest.
Die geben einem ja so ein relativ, also lowlevelige Daten zurück, wie so das Ladeverhalten des Browsers ist.
Man kriegt dann so einen Wasserfall. In dem Wasserfall kann man auch sehen, welche Ressource vielleicht von der anderen abhängt.
Und man kann auch sehen, welche Ressource quasi irgendwie, oder welche JavaScript-Ressource wie viel CPU-Zeit verbrät und so.
Das finde ich halt sehr praktisch. Und da kann man möglicherweise auch erkennen, ob bestimmte Elemente, die vielleicht jetzt zum Beispiel für den largest content für Paint irgendwie relevant sind, oder andere Dinge, ob die zu spät kommen und ob man da vielleicht einen Hint hinzufügen könnte für den Browser, der einfach früher schon mal diese Ressource sich holt.
Mh.
[1:02:13] Und andersrum sieht man vielleicht auch, dass Ressourcen sich zwischendrängeln.
Ähm, und entweder liegt das auch an Ressources, die man gesetzt hat, die man vielleicht wieder rausnehmen sollte.
Weil Bild Nummer drei spielt gar keine Rolle bei Largest Contentful Paint.
Warum soll das irgendwie auch gepreloaded werden?
Und was es dann auch gibt, das ist hier auch, glaube ich, eine Liste drin, es gibt dann noch zusätzlich, das Fetch Priority Attribut.
Ganz neu, wo man vielleicht, wenn man jetzt sieht, okay, ich hab was nicht gepreloaded und dennoch drängelt es sich vor, dann kann man es mit Fetch Priority runter priorisieren.
Also es ist dann so ein bisschen so ein Kneten und Modellieren, dass am Ende eben das, so der Wasserfall dann die Form annimmt, die man gerne hätte.
Okay, aber das ist ja schon wirklich ein gutes Tool dafür.
Ja.
[1:03:15] Ja, genau, da habe ich noch eine Anekdote und zwar in dem Projekt, das wir aktuell benutzen. Da haben wir ein relativ umfangreiches HTML-Dokument, das also sozusagen relativ lange zum Übertragen braucht, was aber an sich kein Problem wäre, weil HTML ist ja progressiv. Das heißt also, das kann ja im Grunde einfach mal losrendern und wenn mehr Daten kommen, dann wird es eben sozusagen weiter gerendert, irgendwo weiter unten im Viewport.
Jetzt hatten wir allerdings das Problem, dass der NGINX, der das ausliefert, Das CSS.
[1:03:56] Abhängig gemacht hat vom html der hat also quasi gesagt das html ist ein exclusive http 2 stream und das css auch und das css ist aber dependent on html okay und der browser sieht eben diese diese stream informationen und sagt dann okay alles klar ich werfe quasi alle meine ressourcen darauf, erst dieses HTML-Dokument zu ziehen, weil davon, also der Server hat ja gesagt, das CSS braucht das vorher fertig.
Das heißt, ich fang nicht an, irgendwelche Sachen parallel zu machen. Mhm.
Und das hat wiederum dazu geführt, dass der First Contentful Paint, dass der einfach wahnsinnig spät war, also wahnsinnig spät in Performance, ne?
Mhm. Und der Browser, der guckt halt sozusagen, was er an Informationen vom Server bekommt.
Drinsteht, so hey, HTML, das bitte erst mal hier exklusiv ziehen und erst danach das CSS, dann macht ihr das halt auch.
Und meistens ist das eine gute Sache, dass man so eine quasi Dependency-Chain aufbaut, aber im Falle von progressiven Dateiformaten ist es halt schade, weil man ja viel Zeit liegen lässt.
Und was ich dann gemacht habe, ist, dass ich tatsächlich unser CSS geinlined habe.
[1:05:20] Damit das eben bereitsteht mit dem ersten Schwall HTML. Auch wenn es dann nicht cachebar ist und all diese Dinge.
Aber der Browser kann dann eben sofort losrendern. Weil er rendert eben dann erst sonst los, wenn das CSS da ist.
Mh...
[1:05:40] Ähm, genau, also das nur so als kleine Anekdote. Da könnt ihr auch mal drauf gucken, wenn eure First Contentful Paint irgendwie nicht so besonders prickelnd ist.
Dann könnt ihr in den Webpagetest euch diesen Wasserfall angucken.
Und da steht dann zum Beispiel eben auch drin, ähm, ist ein Stream exklusiv geflaggt?
Also darf der quasi nicht parallel zu anderen Sachen abgearbeitet werden?
Und man sieht auch, welcher Stream von welchem anderen abhängig ist.
Und da war das eben bei uns so, und das ließ sich nur auf diese Weise auflösen.
Das wär jetzt nämlich mal eine Frage gewesen, wie kommt das denn zu diesem Flag?
Also ist das dann einfach irgendwelcher Out-of-scope-Backend-Krempel, der das verursacht?
Ich glaube, das ist einfach im NGINX so konfiguriert, dass der bestimmte Ressourcen halt wichtiger erachtet als andere.
Und dann eben sagt, die haben eine hohe Priorität. Das heißt, zum einen sollen die quasi exklusiv abgearbeitet werden, damit möglichst wenig Zeit vergeht, damit irgendwie nicht parallel noch andere Daten geschickt werden.
Und der hat eben auch so eine Reihenfolge drin, dass halt glasklar ist, das HTML ist halt das Wichtigste.
[1:06:58] Dann kommt CSS und dann kommt der ganz andere Kram. Aber in dieser Konstellation ist das halt schlecht.
Weil HTML eben, also es gibt dafür, es gibt keine Methode, um das abzubilden, die Tatsache, dass das HTML zwar natürlich elementar ist, aber es im Grunde reicht, wenn da nur der erste Teil von übertragen würde.
Das heißt also, der Browser könnte eigentlich oder die Browser-Server-Kombination könnte eigentlich das nach dem ersten Drittel depriorisieren und dann den Weg für andere Ressourcen freimachen.
Und das lässt sich irgendwie nicht formulieren derzeit.
Okay, verstehe.
[1:07:41] Genau, ich weiß nicht, wie die anderen Server das flanken. Das habe ich mir jetzt nicht angeschaut.
Vielleicht haben die andere Defaults, die dann in dem Fall irgendwie einen besseren Outcome haben.
Okay, verstehe. Aber gut, dann kriegt man es halt auf die Weise in den Griff.
Es ist ja am Ende alles eine Reihe von einander getürmten Hacks und Workarounds.
So ist das nur mal mit dem Computer.
[1:08:12] Jawoll. Genau, du stellst gerade fest, dass wir schon bei einer Stunde sind. Nicht wahr?
Da haben wir letztes Mal auch den Cut gemacht. Also bei etwas über einer Stunde.
Vielleicht machen wir den dann auch jetzt. Und hängen einen Teil drei von X an.
Wobei wir ja auf Seite zwei sind.
Von vier.
Von vier, okay. Ja, dann macht euch noch auf was gefasst. In den kommenden Wochen.
Und dann machen wir hier Schluss.
Ich bedanke mich wieder. Es war mir wie immer ein Vergnügen.
Ja, ne, fand ich auch gut. Man lernt ja immer dazu, und letztlich sind das ja immer alles nur so Aufhänger, so wie unser Glücksrad, dann mal sich zu befassen mit bestimmten Themen.
Ja, ich wollt's grad sagen, es ist halt ein JavaScript-Leitglücksrad quasi.
Ja. Und das ist ja auch okay.
Genau. Wenn ihr höhere und höhere Erfahrungen, Input-Ideen zu den Themen, die wir jetzt in dieser Folge besprochen haben, habt, dann schickt sie uns gerne zu.
Auf mastodonX oder auch auf Slack.
Und genau. Ansonsten würden wir sagen, hört ihr uns weiter debattieren, entweder nächste Woche oder die Woche drauf.
So machen wir das. Genau. Alles klar. Dann danke fürs Zuhören. Bis dann. Tschüssi. Tschüss.
[1:09:40] Music.
[1:10:28] Fuck. Aber gut, dass wir eine kahle Aufnahme haben, du. Läuft ja, läuft ja, herrlich, okay.
Entschuldigung, ich wollte dich nicht so rauswerfen. Nee, du hast auch recht.
Hahaha!
[1:10:59] Genau. Sabine, wir lachen übrigens, weil wir die Gesamtaufnahme in Zencaster nicht gestartet haben.
Und mir fällt nichts Besseres ein, als mitten im Satz Shep das einfach mal so in den Chats zu schreiben.
Ja, stimmt. Nun denn.
Die Frage ist, Shep. Ja? Das landet in den Outtakes. Das landet in den Outtakes, denk ich.
Ich weiß noch nicht ob ich ob jemals jemand außerhalb deiner derer die mit dir einen gehoben haben dich nicht einen kraftausdruck haben verwenden hören müssen wir das jetzt müssen wir das jetzt blieben auf gar keinen fall wir sind ja nicht in amerika hier okay wunderbar dann ist alles super herrlich entschuldigung wie kommen wir jetzt da wieder rein, Ich weiß auch nicht. Ich weiß gar nicht, was ich zuletzt gesagt hab.
Äh, ich ...
Ich wollt's mir noch merken, aber ...
Ich setz einfach noch mal an. Ja, genau. Ähm, und der Browser, der guckt halt sozusagen, was er an Informationen vom Server bekommt und wenn er drin steht...