WEBVTT

00:00:00.315 --> 00:00:03.417
Das heißt, diese ganzen Beknackten, die da immer so im Internet rumlaufen und irgendwie sagen,

00:00:03.417 --> 00:00:07.372
ja, HTML sollte weiterhin ein Dokumentformat sein und diese ganzen User-Interfaces werden einfach jetzt per,

00:00:08.017 --> 00:00:12.617
WebAssembly-Kompiliertem-Qt jetzt umgesetzt, das ist der einzig richtige Weg vorwärts.

00:00:12.617 --> 00:00:15.617
Und diese ganze Diff- und Button-Geschichte, das ist ja nix.

00:00:17.014 --> 00:00:24.017
Ha! Das HTML-Bestandteil, das jetzt nur sich um Scripting dreht und das nicht das Script-Element selber ist. Mhm. Suck it!

00:00:26.017 --> 00:00:31.377
Das ist auf jeden Fall eine coole Erkenntnis. Problem gelöst, würde ich vor allen Dingen sagen, also...

00:00:31.850 --> 00:00:59.414
Working Draft Revision 586.

00:00:32.560 --> 00:00:58.640
Music.

00:01:02.790 --> 00:01:08.377
Kennst du das auch? Du willst mit einer neuen Technologie starten, aber das Internet ist zu

00:01:08.377 --> 00:01:14.177
voll mit wirrem Content in verschiedenster Qualität? Du suchst kompaktes Wissen,

00:01:14.177 --> 00:01:19.246
was dich direkt produktiv macht, mit echter Erfahrung von Experten und Expertinnen,

00:01:20.291 --> 00:01:26.097
die für deine akuten Fragestellungen da sind? Dann solltest du mal im TrainerInnen-Netzwerk

00:01:26.097 --> 00:01:32.697
von Workshops.de vorbeischauen. Hier findest du eine Community aus über 80 TrainerInnen,

00:01:33.155 --> 00:01:37.897
welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden,

00:01:38.394 --> 00:01:44.606
um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen. Es gibt

00:01:44.714 --> 00:01:52.636
sowohl Intensivschulungen über mehrere Tage, als auch Masterclasses, welche dich über einige Monate unterstützen.

00:01:54.517 --> 00:01:58.910
Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung oder,

00:01:59.908 --> 00:02:02.736
möchtest du dich selbst als Trainerin einbringen?

00:02:03.313 --> 00:02:10.348
Dann bist du bei workshops.de genau richtig. Schau einfach mal vorbei für alle Informationen.

00:02:10.348 --> 00:02:18.742
Workshops.de Wir freuen uns auf dich.

00:02:19.668 --> 00:02:25.548
Hallo und willkommen zu Revision 586 von Working Draft. Heute haben wir am Start den Shep. Hallöchen.

00:02:25.827 --> 00:02:30.428
Und meine Wenigkeit. Und außerdem am Start haben wir wieder eine lange Liste von HTML-Features.

00:02:30.428 --> 00:02:35.268
Wir machen einfach weiter mit Teil 2 unserer Tour durch die angedachten Features,

00:02:35.478 --> 00:02:42.670
die möglicherweise Gegenstand sind von einem State of HTML, der da möglicherweise dieses Jahr kommt oder auch nicht.

00:02:42.878 --> 00:02:43.607
Man weiß es nicht.

00:02:43.958 --> 00:02:48.504
Und ich hatte das ja so verstanden, dass wir dort irgendwie die spektakulären, die heißen,

00:02:48.567 --> 00:02:55.028
die neuen und die spannenden Features von HTML besprechen Und auf unserer Liste jetzt als Nächstes steht Tabindex.

00:02:55.028 --> 00:03:04.028
Ja, ich glaube, das soll ja so eine Mischung sein aus eben neu und aber auch neuen Attributen oder neuen Elementen,

00:03:04.028 --> 00:03:08.028
aber eben auch erforschen, was an vielleicht uralten Elementen

00:03:08.291 --> 00:03:10.028
denn überhaupt zum Einsatz kommt.

00:03:10.028 --> 00:03:18.028
Also, es gibt ja einfach so, sagen wir mal, etwas mit Liebe unterversorgte Teile von HTML schon seit jeher.

00:03:18.229 --> 00:03:19.526
Du meinst die Image Maps?

00:03:20.345 --> 00:03:25.708
Image Maps zum Beispiel, genau, die müssten eigentlich mal wieder zurückkommen. Nein, Quatsch.

00:03:25.708 --> 00:03:35.048
Ähm, ja, wobei ich sagen würde, das Tab-Index-Attribut, also, ich glaube, dass das eigentlich schon relativ häufig im Einsatz ist.

00:03:35.048 --> 00:03:44.208
Wahrscheinlich zielen die darauf ab, zu fragen, wie man es benutzt und ob einem bewusst ist, welche Werte was irgendwie bewirken.

00:03:44.966 --> 00:03:52.222
Genau, also man kann ja Tabindex mit einer Null bestücken, dann gibt's minus eins und,

00:03:52.735 --> 00:03:54.728
Dann gibt es ja noch die positiven Zahlen.

00:03:57.065 --> 00:04:02.692
Da hat sich ja so ein bisschen etabliert, dass man diese positiven Zahlen nicht verwendet,

00:04:02.915 --> 00:04:10.915
weil man damit sozusagen händisch eine Tab-Reihenfolge modelliert im Dokument und das meistens schief geht,

00:04:10.915 --> 00:04:15.915
wie alles, was man versucht per Hand irgendwie zu machen, was der Browser sonst automatisch tut.

00:04:15.915 --> 00:04:18.915
Also man nimmt im Prinzip ja dann die Rolle des Browsers ein,

00:04:18.915 --> 00:04:23.915
die Reihenfolge zu bestimmen und zwar ganz, wenn man nicht so was macht wie einfach minus eins,

00:04:23.915 --> 00:04:26.728
Also wenn man sozusagen mehr macht, als den Startpunkt zu setzen.

00:04:27.455 --> 00:04:27.925
Ja, genau.

00:04:30.755 --> 00:04:36.243
Und, tja, also im Grunde geht das eher schief, als dass es irgendwie hilft.

00:04:36.495 --> 00:04:40.255
Vielleicht könnte man auch sagen, man könnte es dynamisch anpassen,

00:04:40.295 --> 00:04:43.755
wenn man weiß, dass ein Container möglicherweise durch ...

00:04:45.095 --> 00:04:50.495
Durch irgendwie CSS und Flexbox oder so was in seiner Reihenfolge umsortiert wird.

00:04:50.495 --> 00:04:55.495
Aber auch da muss man sich schon gut überlegen, ob man das möchte.

00:04:55.495 --> 00:05:02.323
Ansonsten ist eigentlich der vorwiegende Einsatz von Tabindex Null und Minus Eins.

00:05:02.557 --> 00:05:06.495
Wobei Minus Eins quasi ja bedeutet, man kann es nur per JavaScript,

00:05:06.495 --> 00:05:09.495
also programmatisch fokussieren, wenn ich mich recht erinnere.

00:05:09.495 --> 00:05:16.495
Und Null ist, ich kann ein Element auch sozusagen ohne JavaScript per Tab-Key,

00:05:17.302 --> 00:05:21.371
fokussierbar machen für die Benutzerinnen und Benutzer.

00:05:22.155 --> 00:05:25.495
Genauso fasst das auch den nonnormative Teil der Spezifikationen zusammen,

00:05:25.495 --> 00:05:27.214
den ich jetzt hier mal aufgemacht habe.

00:05:28.132 --> 00:05:33.840
Und steht auch drüber, ne, developers should caution, blablabla, positive Werte vielleicht lieber sein lassen.

00:05:36.594 --> 00:05:44.495
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.

00:05:44.495 --> 00:05:47.695
Weil ich meine, die Idee, das halt eben so numerisch zu machen

00:05:47.755 --> 00:05:52.834
und zu sagen, ja, kannst du tatsächlich auch komplett von vorne bis hinten durchziehen, aber lass es halt lieber sein,

00:05:53.915 --> 00:05:57.290
hört sich ja für mich an, als hätte das sich irgendwer ausgedacht,

00:05:57.455 --> 00:06:00.720
so, ah, das ist die erste Lösung, wir geben halt einfach per Zahl an,

00:06:01.242 --> 00:06:03.775
in welcher Reihenfolge das passieren soll und fertig.

00:06:03.835 --> 00:06:10.575
Aus einer Zeit stammend, als irgendwie so superkomplexe Webapplikationen, die von sieben Teams auf einmal zusammengeschustert werden,

00:06:10.635 --> 00:06:12.655
halt noch nicht so auf dem Schirm waren.

00:06:12.655 --> 00:06:15.855
Man irgendwie so Tab-Groups oder irgendwie so Scoping von den Dingern, dass man tatsächlich

00:06:15.855 --> 00:06:20.175
sagen kann, innerhalb einer gewissen, eines gewissen Bereichs will ich das kontrollieren,

00:06:20.175 --> 00:06:23.455
aber sozusagen außerhalb dessen will ich nicht in den normalen Flow einklinken.

00:06:24.810 --> 00:06:25.455
Ja, das macht absolut Sinn.

00:06:26.854 --> 00:06:43.193
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.

00:06:45.840 --> 00:06:51.904
Wäre nicht verkehrt wenn ich glaube ich auch eine gute gute erweiterung von html.

00:06:52.159 --> 00:06:54.329
Ja, die Frage ist, macht das nicht Shadow DOM?

00:06:54.404 --> 00:06:56.237
Also, da kann man ja auch rein fokussieren.

00:06:57.147 --> 00:07:03.704
Hm ... Also, ich weiß es jetzt nicht. Genau, also, ich glaube, dass du, was Web Components angeht,

00:07:03.704 --> 00:07:06.204
da ein bisschen bewandter bist.

00:07:06.491 --> 00:07:11.204
Ich nutze sie ja nicht oder eben nur irgendwie Teilaspekte davon,

00:07:11.469 --> 00:07:15.204
die ich dann irgendwie für ... zu anderen Zwecken missbrauche.

00:07:15.204 --> 00:07:22.604
Ähm, deswegen weiß ich gar nicht, Ich weiß gar nicht, wie Web Components das regeln.

00:07:23.595 --> 00:07:26.980
Aber klingt, müsste ja eigentlich, also macht schon Sinn, was du sagst.

00:07:27.376 --> 00:07:30.404
Also ich klicke jetzt gerade ja wirklich nur spontan durch die,

00:07:30.404 --> 00:07:34.204
ach guck hier, aha, ich habe in den Spezifikationen, in den HTML-Spezifikationen

00:07:34.204 --> 00:07:38.494
jetzt gefunden, dass es das Konzept des Focus Navigation Scope Owners gibt.

00:07:38.935 --> 00:07:42.977
Und dieser Focus Navigation Scope Owner ist, wenn ich mich nicht täusche,

00:07:43.706 --> 00:07:47.004
genau, der hat eine Tab-Index-Order-Focus-Navigation-Scope.

00:07:47.004 --> 00:07:52.484
Da drin ist dann diese Reihenfolge aufgebaut und Focus-Navigation-Scope-Owner sind Documents,

00:07:52.484 --> 00:07:58.644
Shadow-Hosts, Slots oder Elemente in Popover-Showing-State.

00:07:59.109 --> 00:08:02.284
Also damit die Popovers, über die wir ja letzte Folge gesprochen haben,

00:08:02.791 --> 00:08:05.484
die dann über was drüber liegen, auch ihren eigenen Scope bekommen,

00:08:05.484 --> 00:08:08.804
dass man ein Popover designen kann mit Tabindex 1 bis 7 und genau weiß,

00:08:08.804 --> 00:08:12.404
dass man damit nicht das Dokument, in dem der Popover dann kommt, kaputt macht.

00:08:12.404 --> 00:08:14.564
So lese ich das jedenfalls jetzt ganz spontan.

00:08:14.917 --> 00:08:17.564
Das ist auf jeden Fall eine coole Erkenntnis.

00:08:18.014 --> 00:08:22.564
Problem gelöst, würde ich vor allen Dingen sagen. Also braucht man kein neues Feature.

00:08:22.564 --> 00:08:27.564
Können wir einfach sagen, Tabindex ist gut. Und wenn man tatsächlich diese ganzen Features benutzt,

00:08:28.439 --> 00:08:30.617
dann kann man tatsächlich ja...

00:08:32.129 --> 00:08:35.899
Vielleicht auch die positiven Tab-Indexe nehmen, da, wo sie gebraucht werden.

00:08:36.036 --> 00:08:41.639
Da muss man sie halt eben in Shadowhost reinpacken, aber ich glaub, das wäre ja eventuell ein okayer Trade-off.

00:08:41.699 --> 00:08:46.059
Ja, das ist ja, nachdem wir, ich glaub, letztes Mal haben wir ja darüber gesprochen,

00:08:46.099 --> 00:08:49.720
dass Webcomponents ja auch so ein paar Accessibility-Probleme aufwerfen.

00:08:50.422 --> 00:08:56.976
Aber das wär jetzt ja mal sozusagen eine Lösung, die die bieten für ein bestimmtes Problem.

00:08:57.417 --> 00:09:01.504
Ich weiß nicht, ob ich das unter dem Begriff Web Component rubrizieren würde, ganz ehrlich.

00:09:01.779 --> 00:09:07.119
Das ist bloß Shadow DOM, das ist eine Technologie, die man ja, so wie du ja, auch einfach verwenden kann,

00:09:07.159 --> 00:09:09.309
um sein Performanceproblem in den Griff zu bekommen.

00:09:09.921 --> 00:09:16.178
Und ich glaub, Web Component ist mehr so ein breiteres und sehr, sehr nebulöses Konzept. Da weiß ich noch ...

00:09:16.988 --> 00:09:22.839
Naja, du meinst, genau, ich meinte nur, dass es eben zurückzuführen auf ein Feature,

00:09:23.199 --> 00:09:27.779
das unter diesem Web Component-Umbrella dann eben bereitsteht.

00:09:28.277 --> 00:09:32.739
Ja, darauf lasse ich mich ein, das ist okay. Aber das sind definitiv keine Web-Components,

00:09:32.739 --> 00:09:35.190
sondern einfach nur ein Focus-Navigation-Scope-Owner.

00:09:35.884 --> 00:09:41.357
Mhm. Aber es wäre cool, wenn man den auch irgendwie anders setzen könnte.

00:09:41.744 --> 00:09:47.911
Na ja, es gibt ja ein Proposal für deklaratives Shadow DOM, das ist, glaube ich, auch noch irgendwo in der Liste drin.

00:09:48.424 --> 00:09:53.579
Das könntest du dann ja machen, dass du sagst, wie geht das, ein Template mit einem Tag Shadow Root Mode,

00:09:53.654 --> 00:09:58.379
und dann kannst du da angeben, Open oder Closed, wenn du ein Open- oder Closed-Shadow DOM bist.

00:09:58.439 --> 00:10:03.799
Wenn du's deklarativ runterschreibst, ist das so, dass du dein Markup nur in den Shadow Host reinhängst,

00:10:03.859 --> 00:10:06.499
umfasst durch das Template, glaub ich, oder so was.

00:10:07.103 --> 00:10:11.019
Wahrscheinlich kann man das nicht hinhängen. Ja, genau. Aber du musst dich dann auch

00:10:11.079 --> 00:10:14.759
um die restlichen Implikationen wieder kümmern.

00:10:14.819 --> 00:10:21.059
Dass dein CSS irgendwie ... Dass du das dann auch wieder da drin brauchst,

00:10:21.119 --> 00:10:23.533
weil das von außen nicht reinkommt und so Schnickschnack.

00:10:24.079 --> 00:10:29.159
Es ist fast so, als wäre auch diese ganze Shadow-Dom-Idee gar nicht mal so ausgegoren. Ja.

00:10:30.653 --> 00:10:37.959
Ja, genau, also, ich find's, äh, genau, es ist ein guter, äh, Steigbügelhalter, sag ich mal,

00:10:37.999 --> 00:10:44.919
um dieses, diese Idee, die wir formuliert haben, mit den quasi Tab-Index-Unterwelten irgendwie zu realisieren.

00:10:44.919 --> 00:10:48.919
Aber irgendwie halt...

00:10:48.667 --> 00:10:53.797
Ein bisschen zu, mit zu vielen Nebenwirkungen. Entweder das oder eben für sehr spezielle Scopes.

00:10:53.857 --> 00:10:58.917
Also, ich meine, wenn du irgendwie jetzt sagst, ich brauch jetzt irgendwie so ein Widget da drin,

00:10:58.977 --> 00:11:03.157
und das braucht aus irgendwelchen Gründen seine eigene isolierte Tab-Reihenfolge,

00:11:03.217 --> 00:11:08.937
weil ich mein, das betrifft ja selten dein ganzes Dokument, weil das meiste von den meisten Web-Applikationen

00:11:08.997 --> 00:11:10.357
ist ja alles gleichförmig.

00:11:10.417 --> 00:11:13.757
Aber du hast halt irgendwie so ein dein spezielles Widget drin,

00:11:13.817 --> 00:11:16.925
und da musst du halt deine Tab-Reihenfolge separat definieren,

00:11:17.037 --> 00:11:21.577
dann wäre das ja eventuell trotzdem vertretbar, diesen Aufwand dann auch zu betreiben,

00:11:21.637 --> 00:11:23.917
um dieses eine spezifische Problem zu lösen.

00:11:23.977 --> 00:11:27.215
So 80-20, die 20 Prozent müssen halt auch irgendwie gemacht werden.

00:11:27.577 --> 00:11:30.842
Und dann fließt halt eben 80 Prozent der Energie rein, ist ja okay.

00:11:31.869 --> 00:11:36.712
Ja. Ich find ja, meine liebste Brutalo-Variante, um das zu machen, ist einfach per Build-Tool

00:11:37.081 --> 00:11:40.745
in so ein Web-Component-Modul einfach CSS, so per Import-Statement reinzuhauen,

00:11:41.168 --> 00:11:44.277
dann einfach in so ein Style-Tag ins Shadow DOM reinzuhauen.

00:11:44.544 --> 00:11:49.697
Das zuckt die Oberlippe des Performance-Pups ein bisschen, aber es ist definitiv der absolute No-Brainer,

00:11:49.737 --> 00:11:50.530
der garantiert auch funktioniert.

00:11:51.517 --> 00:11:57.264
Ja, das ist ja nicht in Performante, oder? Also gut, es wird halt mehr geladen. Äh ... also, ja.

00:11:57.930 --> 00:12:02.080
Mehr geladen. Du hast dann ja auch die ganzen Style-Elemente sind ja auch dann dupliziert.

00:12:02.332 --> 00:12:06.671
Also jede einzelne CSS-Rule und jeder einzelne Style-Sheet nicht alles.

00:12:07.968 --> 00:12:18.275
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.

00:12:20.697 --> 00:12:24.613
Ja. Ich erlaube mir kein urteil darüber. Ich schweige.

00:12:24.973 --> 00:12:35.278
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.

00:12:36.649 --> 00:12:42.278
So, was haben wir als Nächstes? Structured Data. Ja, wollen wir uns alles vorknöpfen?

00:12:42.278 --> 00:12:43.923
Structured Data, weiß ich nicht.

00:12:44.278 --> 00:12:51.917
Haben wir ja schon mal eine extra Revision auch zugemacht. Ist zwar auch schon eine Weile her.

00:12:52.278 --> 00:12:53.708
Ich glaub, mit dem Yoshi damals.

00:12:54.278 --> 00:12:59.278
Genau, die sollten wir auf jeden Fall noch mal verlinken in den Shadow Notes. Äh, Shadow Notes.

00:12:59.278 --> 00:13:01.278
Show Notes. Guten Morgen.

00:13:01.351 --> 00:13:06.996
Naja, vielleicht bei dieser Folge sind's dann Shadow Notes. Ah ja, ich bleib bei meiner Auffassung zu diesem ganzen

00:13:07.383 --> 00:13:13.278
Structured Data, dass das ein weiteres Symptom davon ist, dass große Teile des Internets für Maschinen gebaut sind

00:13:13.318 --> 00:13:16.070
und Menschen da eigentlich nicht mehr viel zu melden haben.

00:13:16.318 --> 00:13:18.618
Betrifft nicht nur Kochrezepte, aber halt auch so was.

00:13:20.616 --> 00:13:24.278
Ja, genau. Und mein Take ist, dass sich das ja alles irgendwie mittlerweile

00:13:24.318 --> 00:13:30.278
aus dem HTML raus in JSON-LD verlegt hat.

00:13:30.942 --> 00:13:35.515
Das erwähne ich dir hier gar nicht. Interessant.

00:13:36.730 --> 00:13:42.278
Ja, ich glaube, das sind jetzt hier nur die verschiedenen Microdata-Standards, die es gibt.

00:13:42.278 --> 00:13:50.090
Und die Darreichungsform ist ja dann klassisch einfach irgendwie ein,

00:13:51.251 --> 00:13:58.278
argumentiertes Markup, HTML-Markup, oder eben neuerdings JSON-Strukturen

00:13:58.278 --> 00:14:01.063
Strukturen in Form von JSON-LD, was ich persönlich...

00:14:03.044 --> 00:14:06.321
Angenehmer finde auch tatsächlich. Hm.

00:14:07.761 --> 00:14:12.523
Ich komm, ich hab wie lange ... Ja, bitte? Ich wollte zum nächsten Punkt sprengen schon.

00:14:13.027 --> 00:14:19.438
Ach so. Ich wollte nur fragen, wie lange es wohl dauert, bis HTML das erste Attribut raushaut, wo sie einfach aufgeben und sagen,

00:14:19.478 --> 00:14:21.534
komm, da kannst du deine Daten jetzt als JSON reinschreiben.

00:14:22.687 --> 00:14:26.858
Ja. Also, ich mein, theoretisch kannst du das ja in jedes Attribut,

00:14:26.898 --> 00:14:28.178
wenn du es korrekt escapest alles.

00:14:29.862 --> 00:14:34.738
Ja. Hab ich auch schon gemacht. Ja, klar, natürlich, sicher, grad bei Web Components super Sache.

00:14:35.218 --> 00:14:37.958
Aber es fühlt sich ja schon immer so ein bisschen illegal an,

00:14:37.998 --> 00:14:41.238
wenn man sozusagen seine eigene Subsyntax da ins HTML einbaut.

00:14:41.312 --> 00:14:45.733
Okay, jetzt kann man natürlich sagen, das machen die ja bei HTML auch mit Source Set und Krams.

00:14:46.417 --> 00:14:48.883
Aber trotzdem, ich bin mal gespannt, wann das kommt.

00:14:51.118 --> 00:14:55.118
Na gut, gehen wir zum Nächsten, komm. Da hab ich mehr Ahnung von. Oh, wait.

00:14:55.158 --> 00:14:56.526
Genau, Content Security Policy.

00:14:57.057 --> 00:15:00.538
Ich denke auch, dass wir da nicht uns lange drauf irgendwie aufhalten,

00:15:00.538 --> 00:15:04.538
aufhalten sollten. Ich glaube, das ist halt hier reingewandert,

00:15:04.538 --> 00:15:12.538
weil das so Web-Plattform-APIs sind, die irgendwie nicht so JavaScript-lastig sind,

00:15:13.288 --> 00:15:18.438
und sich eher so in HTTP-Header-Regionen abspielen.

00:15:18.600 --> 00:15:26.063
Und die wahrscheinlich einfach eben dann bei den anderen Surveys nicht zum Tragen kommen. CSP ist,

00:15:26.538 --> 00:15:31.538
von der Idee her gut, aber eben sehr aufwendig umzusetzen.

00:15:33.166 --> 00:15:37.496
Wir haben das bei uns im Projekt und haben halt megalange quasi das einfach nur,

00:15:38.144 --> 00:15:45.538
gemonitort, also auf Report-Mode gehabt, um im Laufe der Zeit so all die Dinge abzufangen, die dann so passieren.

00:15:46.795 --> 00:15:50.360
Und haben das dann erst nach langer Zeit wirklich scharf gestaltet.

00:15:50.684 --> 00:15:54.105
Und das wäre jetzt auch meine Empfehlung, weil das ist wirklich,

00:15:55.230 --> 00:16:04.718
erstaunlich was also was das für ein kniffliges konstrukt ist so eine Content-Security-Policy aufzusetzen.

00:16:07.347 --> 00:16:11.997
Ja, ist auch was. Das merk ich immer nur, wenn ich mit irgendwelchen I-Frames experimentiere,

00:16:12.037 --> 00:16:12.992
und dann geht's halt irgendwie nicht.

00:16:14.037 --> 00:16:20.337
Mhm. Und dann ist es tatsächlich gar nicht so einfach, wenn man sich nicht da systematisch reingefuchst hat,

00:16:20.377 --> 00:16:25.537
sondern nur so, ich will was ganz anderes erreichen, und jetzt steht mir das im Weg, was mach ich da?

00:16:25.577 --> 00:16:28.197
Genau, wobei, ich weiß nicht, ist es dann diese ...

00:16:29.124 --> 00:16:33.994
Diese I-Frame- oder Embedder-Policy, also quasi dann ...

00:16:34.363 --> 00:16:41.088
Also das, was früher X-Frames war, glaub ich, wo du darüber gesagt hast, ich darf nicht woanders eingebettet werden als iFrame.

00:16:41.628 --> 00:16:45.097
Da hast du ja eh keine Schnitte, also wenn das jemand setzt, dann ...

00:16:45.778 --> 00:16:50.945
Nee, nee, nee, es ist mehr so Cross-iFrame-JavaScript-Gewinsel. Okay.

00:16:52.106 --> 00:16:55.297
Was selbstverständlich alles nicht Dinge sind, die man machen möchte,

00:16:55.297 --> 00:16:57.297
aber wenn man irgendwie so eine Sandbox haben will,

00:16:57.688 --> 00:17:00.019
um Dinge auszuprobieren, die eigentlich nicht gehen sollten,

00:17:00.370 --> 00:17:06.097
was mein täglich Brot ist, dann liegt das iFrame so nah, aber dann ist dann die Content-Security-Policy,

00:17:06.097 --> 00:17:07.608
wenn man da auf irgendeiner Online-Sandbox rumspielt,

00:17:08.860 --> 00:17:10.084
ja, meistens dagegen.

00:17:11.695 --> 00:17:14.198
Ja. Was ja auch richtig ist. Auf jeden Fall.

00:17:14.297 --> 00:17:18.411
Da kommen wir, glaub ich, auch noch später möglicherweise zu, je nachdem.

00:17:18.797 --> 00:17:21.922
Da war ja noch was mit iFrames und so.

00:17:22.345 --> 00:17:22.867
Mhm.

00:17:24.803 --> 00:17:31.338
Genau. Dann jetzt kommen im Prinzip zwei Web-Components-Punkte. Und der ...

00:17:31.797 --> 00:17:39.797
Das eine ist das Partattribut, mit dem man Teile vom Shadow DOM wieder in Slide DOM exposen kann, glaub ich,

00:17:39.797 --> 00:17:41.797
zur Bestückung und Stylung und so weiter.

00:17:42.888 --> 00:17:45.797
Nee, nicht ganz so. Aber du hast ja, ich kann es kurz erklären,

00:17:45.797 --> 00:17:50.797
wenn du so ein eingebautes Widget hast, wie irgendwie ein Number Input oder ein Slider oder so,

00:17:50.797 --> 00:17:54.797
dann besteht das ja mit seinem internen Aufbau auch aus Shadow DOM und irgendwelchen DIVs.

00:17:54.797 --> 00:17:59.632
Und die kannst du ja in CSS adressieren für jeden Browser einzeln über Pseudo-Elemente.

00:17:59.822 --> 00:18:06.277
Elemente. Doppelpunkt, Doppelpunkt, keine Ahnung, Slider oder sowas. Und das ist im Prinzip so ein

00:18:06.277 --> 00:18:14.197
selbstgebauter Pseudo-Element-Konstrukteur. Du verwendest in deinem Shadow DOM das Part-Attribut

00:18:14.197 --> 00:18:18.627
und schreibst da dann halt irgendwie einen Namen rein und dann kann halt eben jemand von außen in

00:18:18.837 --> 00:18:23.797
dieses Shadow DOM rein stylen mit Doppelpunkt, Doppelpunkt, Part und dann in Klammern den Namen

00:18:23.797 --> 00:18:29.757
von dem Teil, den man da halt eben adressieren möchte. Ist jetzt nicht so ein First-Class-Pseudo-Element,

00:18:29.757 --> 00:18:36.437
aber halt sozusagen eine Funktion zum Adressieren von mit Part ausgestatteten Dinger da im Inneren.

00:18:38.531 --> 00:18:45.321
Okay, und genau, dann ist Slot das Ding, um quasi Teile des Shadow Doms bestücken zu können.

00:18:45.381 --> 00:18:49.316
Und eben das ist dann auch im Light Dome sichtbar, richtig?

00:18:49.766 --> 00:18:54.708
Das ist sozusagen ein Portal im Shadow Dome, wo du dann den Light Dome-Content reinprojizieren kannst.

00:18:55.167 --> 00:18:58.321
Also die andere Richtung, nicht Shadow Dome ins Light Dome exposen,

00:18:58.381 --> 00:19:00.561
sondern Light Dome ins Shadow Dome holen.

00:19:00.621 --> 00:19:06.921
Okay, die Sachen sind aber dann auch bei Query Selector All dann aus dem Light Dome ausgreifbar, richtig?

00:19:07.303 --> 00:19:10.121
Genau, denn die sind ja tatsächlich Bestandteil des Lightroom.

00:19:10.181 --> 00:19:13.028
Es ist wirklich so ein Portal, so eine rein Beam-Geschichte.

00:19:13.381 --> 00:19:19.321
Das macht dann auch alles sehr viel Sinn, weil das fühlt sich halt eben wirklich an wie ein richtiges HTML-Element,

00:19:19.381 --> 00:19:25.221
wenn du halt irgendwie eine Tabelle hast oder so was und du schreibst in das TD-Element irgendwelchen Content rein.

00:19:25.281 --> 00:19:30.361
Okay, Tabelle ist jetzt ein blödes Beispiel, weil das macht nicht wirklich irgendwie so Shadow DOM.

00:19:30.996 --> 00:19:35.161
Aber zum Beispiel hier, lass mal kurz überlegen, ein Dialog, ja, so ein akkordeonartiges Teil.

00:19:35.264 --> 00:19:40.461
Genau, das ist ja ein gutes Beispiel dafür. Das macht ja irgendwie so ein Ding, wo du draufklicken kannst

00:19:40.521 --> 00:19:43.461
mit Aufklapp-zu-Klapp-Logik und kleines Icon und so Zeug.

00:19:43.521 --> 00:19:47.761
Aber dein Lightroom ist da reingebeamt, aber für dich ist das eben eine Blackbox.

00:19:47.821 --> 00:19:53.601
Und genau das machst du halt eben mit den Slots. Und mit dem Part machst du die ganzen Einzelteile da exposebar.

00:19:53.661 --> 00:19:57.361
Und das ist alles so irre aufwendig, dass ich wirklich behaupten würde,

00:19:57.421 --> 00:20:03.021
das wird am Ende so gut wie niemand machen, außer halt so Sachen wie, was du in letzter Folge erzählt hast,

00:20:03.021 --> 00:20:04.701
Was war das, ein Chromecast-Widget?

00:20:05.259 --> 00:20:09.021
Mhm. Das wirklich sagt so, wir gehen jetzt diesen etwas oldschooligen,

00:20:09.021 --> 00:20:15.972
2.0-igen Ansatz von so Mixins oder so Embeddables, das macht man ja heutzutage eigentlich gar nicht mehr.

00:20:16.683 --> 00:20:19.021
Also für die ist das natürlich super, weil die wirklich sagen können,

00:20:19.021 --> 00:20:24.677
ich biete für meine Webcomponent eine JavaScript-API an und eine HTML-API, das sind dann eben diese Slots,

00:20:25.021 --> 00:20:27.765
und eine CSS-API halt eben über die Part-Selektoren.

00:20:28.305 --> 00:20:30.853
Das könnte man alles machen, aber das wird halt wirklich behaupten,

00:20:31.021 --> 00:20:34.021
Sollten die Webcomponents jemals richtig Gas geben,

00:20:34.021 --> 00:20:39.521
wird das wirklich einfach nirgendwo stattfinden, weil die meisten Leute am Ende doch Code-Reviews sagen,

00:20:39.521 --> 00:20:45.157
aber am Ende doch eine Deadline haben und sagen werden, ich brauche jetzt hier mein Click-Widget für mein eines Projekt.

00:20:46.291 --> 00:20:49.021
Die werden das nicht verwenden. Behaupte ich.

00:20:50.306 --> 00:20:55.021
Ja, ist auch nicht unwahrscheinlich. Und der nächste Teil hier, das ist, glaube ich, da,

00:20:55.021 --> 00:21:01.748
das wäre ganz gut gewesen, wenn wir über das Template-Element Element letztes Mal auch gesprochen.

00:21:02.541 --> 00:21:09.139
Und genau dessen, glaub ich, Nutzlosigkeit oder so was. Oder sagen wir mal Feature-Armut. Jo.

00:21:09.741 --> 00:21:13.481
Und ich weiß nicht, ob wir da irgendwie, ob ich da auch erwähnt hatte,

00:21:13.541 --> 00:21:15.702
dass es ja irgendwann mal so ein Proposal von Apple gab.

00:21:16.541 --> 00:21:21.381
Schon ewig her. Und ich glaube, das ist dieses DOM-Parts, was hier auch aufgelistet ist.

00:21:21.441 --> 00:21:24.083
Oder es ist quasi daraus entstanden. Ähm ...

00:21:25.289 --> 00:21:36.560
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.

00:21:36.992 --> 00:21:37.397
Mhm.

00:21:40.818 --> 00:21:45.228
Die haben nicht mal ein richtiges Standardsdokument, deswegen kann ich darüber nix sagen.

00:21:45.288 --> 00:21:47.732
Das ist weit unter meiner Wahrnehmungsschwelle.

00:21:47.828 --> 00:21:49.487
Ja, es geht im Prinzip einfach nur ...

00:21:49.928 --> 00:21:54.968
Ich glaube, es geht letztlich darum, ähm, so ein Template, äh,

00:21:56.028 --> 00:21:58.634
String zu verdrahten mit ...

00:22:00.228 --> 00:22:06.228
Also Stellen zu verbinden mit eben Variablen. Und wenn die sich eben aktualisieren,

00:22:06.288 --> 00:22:09.193
wird das dann eben automatisch auch im Rendering aktualisiert.

00:22:10.084 --> 00:22:21.400
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.

00:22:21.770 --> 00:22:33.382
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.

00:22:35.255 --> 00:22:41.528
Ja. Aber das wird noch schlimmer werden als Module, wenn die am Ende sagen, es wird jetzt diesen einen offiziellen Weg gehen,

00:22:41.568 --> 00:22:42.142
den wir da beschreiten.

00:22:43.735 --> 00:22:47.528
Das wird schwierig werden, weil da werden halt ganz viele sagen,

00:22:47.568 --> 00:22:51.528
ein spezieller Use Case, und dann werden sie es doch per JavaScript nachbauen.

00:22:51.568 --> 00:22:56.528
Und dann hast du die Volksfront von Judea im Browser eingebaut und die judeische Volksfront,

00:22:56.734 --> 00:22:59.528
die dann trotzdem das noch mal per JavaScript sich schleppt.

00:22:59.849 --> 00:23:06.128
Schwierig. Ich überlege, ob man da nicht lowleveliger Das Knifflige ist ja der Update-Mechanismus.

00:23:07.231 --> 00:23:11.168
Und das ist ja meistens so gelöst, dass man irgendwie so eine Art DOM-Diffing-Geschichte hat,

00:23:11.248 --> 00:23:13.532
dass die Programmierer so ein deklaratives Modell haben.

00:23:13.728 --> 00:23:17.848
Hier sind Daten, mach das DOM drauf, und hier sind neue Daten, pass das DOM entsprechend an.

00:23:17.928 --> 00:23:20.728
Was ich glaube, was man vielleicht eher standardisieren sollte,

00:23:20.808 --> 00:23:25.128
wäre so eine Art innerHTML 2.0, was halt irgendwie einen DOM-Diffing-Algorithmus beschreitet.

00:23:25.208 --> 00:23:29.048
Weil ich glaube, da wäre es einfacher, einfach aufgrund des beschränkteren Scopes

00:23:29.128 --> 00:23:31.537
und der Abwesenheit von irgendeiner weiteren Sonntags,

00:23:32.149 --> 00:23:44.648
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.

00:23:47.273 --> 00:23:51.018
Ich glaub, das fänd ich eigentlich eher ganz nett, weil diese ganzen Domdiffing-Geschichten,

00:23:51.923 --> 00:23:55.383
die sind wirklich, abgesehen von React mit diesem Überkomplizierten,

00:23:55.423 --> 00:23:57.121
ja wirklich, wirklich, wirklich alle gleich. Mhm. Ja.

00:23:58.703 --> 00:24:03.723
Ja, und vielleicht gibt's dann auch Lösungen für bestimmte Probleme,

00:24:03.763 --> 00:24:12.703
die mal halt irgendwie schwer zu vermeiden sind, wie Fokus ist im Input, Input wird gedifft, Fokus ist weg.

00:24:13.425 --> 00:24:19.603
Ja. Das hat man regelmäßig und manchmal auch nicht, weil der Input selber aktualisiert wird,

00:24:19.663 --> 00:24:25.199
sondern weil, ich weiß nicht mehr genau, ich glaube, wenn davor quasi Elemente verschwinden,

00:24:25.893 --> 00:24:34.363
und die rausgenommen werden und der Input quasi dann höher wandert sozusagen im Quelltext,

00:24:34.517 --> 00:24:35.763
dann passiert das auch.

00:24:35.823 --> 00:24:40.163
Also ... ja, das wär, glaub ich, das stimmt.

00:24:40.251 --> 00:24:42.493
Das ist eine sehr, sehr, sehr gute Idee.

00:24:42.916 --> 00:24:47.300
Da sind halt erst genau die ganzen kniffligen Sachen. Wenn du dich wirklich hinsetzt und sagst,

00:24:47.583 --> 00:24:51.703
ich will jetzt Dom-Diffing bauen, du brauchst für 98 Prozent der ganzen Sachen

00:24:51.763 --> 00:24:52.963
weniger als 100 Zeilen.

00:24:53.023 --> 00:24:56.698
Du brauchst bloß irgendwie so einen Tree-Abgleich und halt Attribute abgleichen und so.

00:24:57.583 --> 00:25:04.692
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.

00:25:05.890 --> 00:25:09.763
So. Aber wenn's halt eben an so Fokus geht, und da sitzen Event-Listener drauf,

00:25:09.763 --> 00:25:12.498
die so irgendwie mit On-Click draufgesteckt wurden, so ganz old school.

00:25:13.380 --> 00:25:19.763
Ja, das ist natürlich dann richtig eklig, ja. Das sind die schwierigen Sachen. Und das eigentlich Schwierige ist darin,

00:25:19.763 --> 00:25:22.526
okay, man muss das irgendwie managen, man muss teilweise auch Entscheidungen treffen.

00:25:22.763 --> 00:25:25.763
Wie verhalte ich mich jetzt? Wenn es einfach nur zwei falsche Antworten gibt,

00:25:25.763 --> 00:25:29.638
muss man sich für eine von den beiden entscheiden. Und man muss wissen, dass die ganzen Probleme existieren.

00:25:30.070 --> 00:25:33.689
Und das ist, glaube ich, das Mithärteste, weil gerade diese ganzen Details wie,

00:25:34.157 --> 00:25:40.279
so ein On-Click-Event-Listener oder Fokus-Zeug, Das hat man gegebenenfalls nicht auf dem Schirm.

00:25:40.557 --> 00:25:45.103
Da könnte die Plattform wunderbar sagen, so, hier läuft das jetzt wie beim HTML-Parser auch,

00:25:45.143 --> 00:25:48.056
hier gibt's nur falsche Antworten, das ist jetzt die offizielle.

00:25:48.696 --> 00:25:54.547
Was ich übrigens auch gerne hätte, ist eine Möglichkeit, die Art eines Tags mutieren zu können.

00:25:55.240 --> 00:25:58.733
Also, das find ich halt auch manchmal gut. Weil du momentan ja nur ...

00:25:59.309 --> 00:26:07.363
Na ja, wenn du aus einem Diff einen Span machen möchtest. Also, dass du quasi, äh, dass du ihm sagst,

00:26:07.363 --> 00:26:09.518
nee, sei ab jetzt ein Span, bitte.

00:26:09.707 --> 00:26:15.363
Weil du kannst das ja nur realisieren, indem du das Diff quasi wegnimmst

00:26:15.363 --> 00:26:18.115
und ein neues Span createst und wieder einhängst.

00:26:18.583 --> 00:26:18.844
Ja.

00:26:20.978 --> 00:26:28.163
Und ich fänd's, glaub ich, gut, wenn man das eben anders machen könnte. Ähm ...

00:26:29.359 --> 00:26:32.951
Aber was machst du dann mit irgendwelchen JavaScript-Referenzen auf das Diff?

00:26:35.345 --> 00:26:40.522
Also du hast eine Variable und da ist das Diff drin und dann wird ein Mutationsschritt ausgeführt. Was passiert dann?

00:26:41.368 --> 00:26:43.708
Ja, dann müssten die natürlich, dann werden die halt weg.

00:26:45.302 --> 00:26:48.570
Du willst ja auch keinen On-Click-Händler wahrscheinlich und so Sachen behalten.

00:26:49.443 --> 00:26:51.342
Also die JavaScript-Variable ist dann weg?

00:26:53.195 --> 00:26:57.195
Ja, oder sie ist im Prinzip, sie hat keinen, sie zeigt auf nichts mehr.

00:26:57.195 --> 00:27:01.479
Sie könnte, wenn sie, wenn es eine Weak-Web wäre, könnte sie Garbage-Collected werden.

00:27:02.195 --> 00:27:07.879
Das ist das Ding, wenn sie eine Weakmap wäre, wenn das alles WeakRefs wären, dann wäre das ja alles kein Problem.

00:27:09.735 --> 00:27:13.775
Aber ich meine, wie machst du das dann? Das Problem hast du ja so auch.

00:27:13.835 --> 00:27:16.369
Also, wenn du das Diff quasi löschst ...

00:27:17.475 --> 00:27:24.597
Und ein Span, Creators und an der Stelle einhängst, ändert sich daran ja auch nichts letztendlich,

00:27:25.335 --> 00:27:27.117
an dem Problem, das du grade beschrieben hast.

00:27:27.459 --> 00:27:30.286
Na ja, doch, deine JavaScript-Variable hat einen definierten Wert.

00:27:31.222 --> 00:27:35.174
Den von dem Diff vorher. Das ist ja dann noch da, nur halt nicht mehr im DOM.

00:27:36.695 --> 00:27:40.846
Ja, dann bitte gerne auch so. Mhm.

00:27:41.305 --> 00:27:47.066
Nur eben ohne dieses quasi rauslöschen müssen und neu createn und wieder einhängen.

00:27:47.195 --> 00:27:50.195
Also, das find ich irgendwie umständlich.

00:27:50.928 --> 00:27:54.195
Aber was du ja eigentlich wirklich suchst, wenn ich dich jetzt richtig verstehe,

00:27:54.195 --> 00:27:58.265
ist ja eine Developer Experience und nicht eine technische Lösung für irgendein Problem.

00:27:59.409 --> 00:28:05.195
Ja, das stimmt wohl. Mit dem einen Unterschied, das ist vielleicht dann auch so was wie,

00:28:05.195 --> 00:28:07.168
wenn der Fokus auf dem Element wäre.

00:28:09.195 --> 00:28:14.415
Das mutiert wird, eben der Fokus möglicherweise dann auch darauf bliebe. So.

00:28:15.195 --> 00:28:18.979
Ja. Also im Prinzip aber auch develop experience, weil ich könnte vorher gucken,

00:28:19.195 --> 00:28:22.607
document active element, ist das eben dieses?

00:28:22.695 --> 00:28:29.386
Dann merkt ihr das, Kicks raus, bauen neues, hängst ein und steckt dann den Fokus wieder drauf.

00:28:29.818 --> 00:28:33.475
Weil ich glaube, das wäre wirklich die Lösung, die ich nehmen würde.

00:28:33.475 --> 00:28:37.227
Ich würde halt wirklich eine Funktion bauen, die kann man dann ja gerne irgendwie transmutate oder so nennen.

00:28:38.181 --> 00:28:40.975
Aber die müsste unter der Haube halt wirklich diesen Swap machen.

00:28:41.899 --> 00:28:45.475
Also sprich neues Element erzeugen, von dem alten alles rüber kopieren, was du rüber kopieren willst,

00:28:45.815 --> 00:28:49.164
den Fokuszustand auch wieder herstellen und dann am Ende austauschen.

00:28:49.488 --> 00:28:49.848
Mhm.

00:28:51.189 --> 00:28:55.040
Äh, das wäre am sinnvollsten, weil, als du das gerade erwähnt hast,

00:28:55.040 --> 00:28:59.040
was du gerne hättest, ist mein Gehirn sofort zu einem Experiment hingegangen,

00:28:59.040 --> 00:29:00.903
das ich letztens vollführt habe.

00:29:01.056 --> 00:29:03.775
Wir haben ja letzte Folge über dieses Membranenproblem gesprochen.

00:29:04.540 --> 00:29:06.610
Also, ich habe eine Web-Component, da drin ist ein Select-Element,

00:29:07.051 --> 00:29:10.004
und meine Web-Component soll sich wie ein Select-Element verhalten,

00:29:10.247 --> 00:29:11.355
nur halt mit vorkonfigurierten Options.

00:29:12.040 --> 00:29:16.855
Aber es soll im Prinzip die ganze JavaScript-API und die Formularbenutzbarkeit von einem Select-Element exposed werden.

00:29:18.070 --> 00:29:21.734
Und mein krankes Hirn ging natürlich erstmal sofort zu den JavaScript-Proxys,

00:29:22.256 --> 00:29:28.040
dass ich ja im Prinzip da Magic Keys machen kann. Wenn ich also auf meiner Web-Component irgendwie einen Property-Access durchführe

00:29:28.040 --> 00:29:32.861
und der ist auf der Web-Component nicht definiert, dann delegiere ich das weiter an irgendein Delegate-Target im Shadow DOM.

00:29:33.644 --> 00:29:39.040
Stellt sich raus, geht nicht, weil man nicht ein HTML-Element,

00:29:39.040 --> 00:29:42.340
eine Web-Component, ein Custom-Element bauen kann, was ein Proxy ist,

00:29:43.196 --> 00:29:53.380
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.

00:29:53.638 --> 00:29:57.520
Und das ist ja im Prinzip genau das Gleiche, was du gerade beschrieben hast. Es ist erst

00:29:57.950 --> 00:30:00.480
Tag so und so, und dann soll es zu Tag so und so werden.

00:30:00.880 --> 00:30:06.860
Aber was halt genau nicht geht, ist dieser Switch von dieses Ding ist jetzt etwas komplett anderes wegen diesem,

00:30:07.574 --> 00:30:10.761
also mehr oder minder dieses dangling-variablen Problem, weil du am Ende sonst bei,

00:30:11.440 --> 00:30:19.240
Konstruktionen landest oder bei Zuständen landest, wo du wirklich na ja, zwei Objekte hast, die von sich behaupten können,

00:30:19.280 --> 00:30:20.726
ich bin dieses Element.

00:30:21.140 --> 00:30:26.433
Aber sie müssen halt fundamental unterschiedlich sein. Das eine muss ein Diff sein, das andere muss ein Span sein.

00:30:26.848 --> 00:30:28.585
Und das führt halt zu extrem unangenehmen Problemen.

00:30:29.620 --> 00:30:34.360
Weswegen man, wie gesagt, das bei dir besser über so einer Developer-Experience lösen sollte.

00:30:34.400 --> 00:30:36.336
Und ich sollte meine Membranen-Idee am besten in die Tonne treten.

00:30:38.227 --> 00:30:39.649
Weil das wird so nicht funktionieren.

00:30:39.820 --> 00:30:41.809
Ja, aber gut, dass du's erforscht hast.

00:30:42.232 --> 00:30:46.995
Ich hab dann auch die einzige Stelle gefunden, wo in den HTML5-Spezifikationen wirklich ECMAScript-Sprech drinsteht.

00:30:48.093 --> 00:30:53.701
Und so interne ECMAScript-Methoden aufgerufen werden, die wirklich durch diese Proxy-Grenze durchgehen und sagen können,

00:30:54.206 --> 00:30:57.140
ich schmeiß eine Exception, wenn ich nicht definitiv feststellen kann,

00:30:57.842 --> 00:30:59.380
dass dieses Ding auch wirklich ein X ist.

00:30:59.420 --> 00:31:01.820
Und wenn's ein Proxy auf X ist, dann Exception.

00:31:02.136 --> 00:31:05.140
Es ist sehr obskurer Randbereich, aber es war sehr frustrierend,

00:31:05.180 --> 00:31:07.304
rauszufinden, dass das nicht geht und nicht gehen kann.

00:31:08.330 --> 00:31:16.081
Damn. Na ja. Aber muss ja auch erforscht werden. Irgendwer muss es tun.

00:31:16.801 --> 00:31:23.100
Ähm, dann lass uns doch weitergehen zu Content Editable. Ja. Überhaupt nicht neu.

00:31:23.328 --> 00:31:29.100
Gibt's ja schon seit ... Also, hat ja der IE beziehungsweise Hotmail, glaub ich, erfunden oder so.

00:31:29.100 --> 00:31:30.962
Hotmail hat's bestellt, IE hat's implementiert.

00:31:32.132 --> 00:31:41.521
Ähm, und ... Ja, letztlich ist das ja so was ... Also genau, man kann ein beliebiges HTML-Element editierbar machen.

00:31:42.269 --> 00:31:44.231
Und.

00:31:45.852 --> 00:31:49.501
Jetzt gibt's eben die Möglichkeit, dem noch einen Wert zu geben,

00:31:49.541 --> 00:31:56.541
nämlich Plain Text Only, der, glaub ich, also zumindest würd ich sagen, auf den man schon lange gewartet hat,

00:31:56.708 --> 00:32:03.961
damit man eben nicht das Problem hat, dass da drin irgendwelche weiteren Tags erzeugt werden,

00:32:04.001 --> 00:32:08.330
wenn man irgendwie falsche Eingaben macht oder was pastet oder so was.

00:32:08.627 --> 00:32:14.581
Also dass das quasi, dass das, was da drin ist, wirklich ohne weiteres Markup ist, reiner Text.

00:32:14.794 --> 00:32:19.520
So möchte man das, glaube ich, meistens haben, oder?

00:32:20.033 --> 00:32:23.581
Ja, klar, weil dir meistens ja die Rich Text Editing API fehlt.

00:32:23.581 --> 00:32:27.334
Und wenn du dann deinen Cursor irgendwo in den fetten Text reinbewegst.

00:32:28.603 --> 00:32:31.088
Weißt du halt nicht genau, was passiert, wenn du jetzt ein X drückst.

00:32:32.150 --> 00:32:32.474
Ja.

00:32:33.563 --> 00:32:38.581
Das ist so das Ding. Nee, ist super. Wie ist denn das mit dem Support von Plain Text?

00:32:38.581 --> 00:32:41.215
Ah, der Firefox kann es nicht. Ärgerlich.

00:32:41.936 --> 00:32:53.781
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

00:32:53.781 --> 00:33:08.393
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,

00:33:08.636 --> 00:33:12.041
dann landen die eben auf dieser Interop-Liste.

00:33:12.101 --> 00:33:15.301
Und ich glaube, dass dieses möglicherweise dort landen könnte,

00:33:15.442 --> 00:33:18.206
weil's für mich jetzt nicht so aufwendig klingt, das zu machen.

00:33:19.772 --> 00:33:22.341
Hm. Für mich auch nicht, aber seitdem ich mal angefangen hab,

00:33:22.401 --> 00:33:27.910
so einigermaßen regelmäßig Feature-Requests und Sachen CSS Randaspekte bei Firefox zu stellen,

00:33:29.252 --> 00:33:32.015
und ich einfach nur so die nachfolgenden Diskussionen grob verfolgt habe,

00:33:32.618 --> 00:33:34.599
glaub ich nicht mehr, dass irgendwas leicht umzusetzen ist.

00:33:36.165 --> 00:33:39.861
Was war das? Der hat irgendwas nicht geupdatet, ne? was du haben wolltest.

00:33:40.144 --> 00:33:43.161
Nee, das war was anderes, das hab ich auch einfach aufgegeben.

00:33:43.201 --> 00:33:45.821
Ich hatte irgendwie ein Canvas-Element in einem ...

00:33:46.041 --> 00:33:51.161
Ich hatte einen Shadow DOM, da drin ein Slot, da drin ein Canvas-Element, das Ganze in einem I-Frame.

00:33:51.352 --> 00:33:55.196
Und wenn ich dann auf dem Canvas-Element irgendwelche Draw-Befehle ausgelöst habe,

00:33:55.441 --> 00:33:57.222
dann sind die nicht sichtbar geworden.

00:33:57.441 --> 00:34:01.941
Aber wenn ich die Pixeldaten ausgelesen hab, per JavaScript-API hab ich genau gesehen,

00:34:01.981 --> 00:34:04.201
dass meine Draw-Befehle durchgekommen sind.

00:34:04.241 --> 00:34:09.321
Also die Bitmap repräsentiert die Werte, Okay.

00:34:08.834 --> 00:34:13.124
Aber das war ein Problem, das ich ernsthaft lösen wollte. Ich wollte Pixel anzeigen.

00:34:13.184 --> 00:34:19.024
Ich wollte nicht wie bei den Proxys einen Beweis antreten. Dann hab ich gesagt, okay, Junge, geht das einfacher?

00:34:19.084 --> 00:34:20.501
Und siehe da, es ging einfacher.

00:34:20.978 --> 00:34:26.524
Sehr gut. Nee, nee, es war was mit Animationen und irgendwie so Transformsätzen in Keyframes.

00:34:27.694 --> 00:34:31.025
Bla, Randaspekte, wo ich nur sage, hey, da müsstet ihr doch eigentlich nur dit so machen,

00:34:31.284 --> 00:34:33.150
dass das genauso ist wie in Chrome.

00:34:33.825 --> 00:34:38.704
Und dann müssen wir das und das und das und das und das. Wenn wir das machen, wird's aber viel langsamer.

00:34:40.036 --> 00:34:40.544
Deswegen wird das nicht passieren.

00:34:40.730 --> 00:34:46.176
Ja, genau. Das sind ja dann doch unterschiedliche Engines, die sozusagen unterschiedliche Unterbaus haben.

00:34:46.626 --> 00:34:52.744
Und auch Chrome hat ja jetzt quasi seinen gesamten Unterbau ausgewechselt fürs Rendering, um wieder ...

00:34:52.882 --> 00:34:57.984
Also, um zum einen weniger Bugs zu haben, aber zum anderen auch wieder eine bessere Ausgangsbasis

00:34:58.044 --> 00:35:00.344
für neue Feature-Implementationen zu haben.

00:35:00.687 --> 00:35:03.298
Ja, und ich find das halt echt super und echt bemerkenswert,

00:35:03.644 --> 00:35:05.720
wie unterschiedlich die halt dann doch sind.

00:35:06.044 --> 00:35:11.004
Ja, genau, was denen dann so leichtfällt, wie zum Beispiel der Firefox unterstützt seit Ewigkeiten

00:35:11.382 --> 00:35:13.696
hier diese Elementfunktion in CSS.

00:35:14.065 --> 00:35:20.404
Und das ist ja quasi für alle anderen Browserhersteller sozusagen die Quadratur des Kreises.

00:35:20.464 --> 00:35:22.932
Deswegen können die das nicht bauen. Ja.

00:35:24.165 --> 00:35:28.045
Ja, oder halt eben auch so, dass halt so Bugs passieren irgendwie so in einem Browser,

00:35:29.216 --> 00:35:32.284
die halt im anderen Browser einfach komplett nicht reproduzierbar sind,

00:35:32.344 --> 00:35:37.864
weil nur der eine Browser diesen spezifischen Stack plus diese Drawing-API plus diesen Rundungsfehler

00:35:37.924 --> 00:35:41.720
auf dieser Hardware halt ausprägt und der andere halt einfach gar nicht.

00:35:42.602 --> 00:35:46.424
Und das hast du halt nur, wenn du irgendwie so Chrome und Firefox nebeneinander hältst

00:35:46.484 --> 00:35:51.604
und der ganze Rest da mit Brave und dem ganzen Gesocks, das ist alles Chrome-esk, das zählt nicht.

00:35:51.793 --> 00:35:56.222
Mhm. Ich hatte übrigens, hatten wir letztens ein Projekt, also da benutzen wir Aviv.

00:35:56.961 --> 00:36:04.064
Und wir hatten das Problem, dass Bilder eine so eine pinke ...

00:36:04.802 --> 00:36:10.304
Linie an der rechten Seite, glaube ich, hatten, aber eben nur auf Android-Devices.

00:36:12.066 --> 00:36:25.786
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

00:36:25.993 --> 00:36:42.692
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.

00:36:42.857 --> 00:36:50.047
Und dann auch nur quasi in einem bestimmten fenster von chrome versionen die von diesem fehler betroffen waren.

00:36:50.200 --> 00:37:01.617
Das war schon echt sehr exotisch, aber irgendwie auch so ein irre, also wie, was, wie, warum und in welchen Konstellationen sowas passieren kann.

00:37:01.867 --> 00:37:10.617
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.

00:37:10.617 --> 00:37:18.617
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.

00:37:18.617 --> 00:37:24.137
Nicht, aber bei uns trafen halt all diese Bedingungen aufeinander und es war halt sehr mysteriös.

00:37:25.660 --> 00:37:30.270
Ha, das ist natürlich gut. Aber, also, da fühlt sich ja auch manchmal grade,

00:37:30.310 --> 00:37:35.270
wenn man nicht so tief im Thema steckt, man steckt sich teilweise wie auf dem falschen Planeten.

00:37:35.310 --> 00:37:38.822
Ich erinnere an meine Geschichte, die hab ich Anfang des Jahres verblockt,

00:37:39.110 --> 00:37:43.750
wo ich wen hatte, der zu mir sagte, auf manchen Laptops werden die PDFs komisch gerendert,

00:37:43.790 --> 00:37:44.673
wenn die Hardwarebeschleunigung an ist.

00:37:45.830 --> 00:37:50.750
Also, Hardwarebeschleunigung an, nur PDFs, nur auf manchen Laptops.

00:37:50.790 --> 00:37:55.008
Und dann war das halt so eine Kombination mit einem Chrome-Bug und einem Intel-Chip.

00:37:55.611 --> 00:37:59.370
Und da ist das halt eben aufgetaucht. Da konnte ich den Leuten dann aber sagen,

00:37:59.410 --> 00:38:03.910
bau diesen Zehnzeiler ein, der die Canvas-Get-Context-Funktion so patcht,

00:38:03.950 --> 00:38:08.934
dass ich einen Effekt auslöse, der als Nebenwirkung ein Abschalten der Hardwarebeschleunigung hat.

00:38:09.290 --> 00:38:12.590
Dann rendert das PDF irgendwie eine halbe Millisekunde langsam,

00:38:12.630 --> 00:38:14.372
aber dann sehen die Buchstaben wenigstens alle richtig aus.

00:38:15.750 --> 00:38:20.050
Ja. Da haben die auch gedacht, was bist du denn für ein Voodoo-Puppenbeschwörer?

00:38:20.050 --> 00:38:23.050
Dann dachte ich, aha, Hardwarebeschleunigung auf Canvas.

00:38:23.110 --> 00:38:27.750
Das kann man doch bestimmt einfach austricksen. Dann hatte ich die Lösung extrem schnell.

00:38:27.810 --> 00:38:32.450
Aber damit der Stundenzettel voll wird, hab ich hinterher recherchiert, warum das so ist.

00:38:32.510 --> 00:38:35.650
Und ab welcher Version es gepatcht ist, damit sich das lohnt.

00:38:35.710 --> 00:38:37.831
Unlösbares Problem, seit Wochen kauen wir drauf rum.

00:38:38.677 --> 00:38:42.310
Dann sagst du halt eben, ah ja, okay, es ist eine Option auf Get-Context,

00:38:42.370 --> 00:38:45.410
wo du sagen kannst, mach mal keine Hardwarebeschleunigung.

00:38:45.470 --> 00:38:49.470
Ist ja schon ein billiger Trick. wissen, was da passiert ist und einfach man das rausnehmen kann.

00:38:49.470 --> 00:38:51.590
Das macht es ja langsamer. Es ist ja nicht eine perfekte Lösung.

00:38:51.983 --> 00:38:52.090
Ja.

00:38:53.153 --> 00:38:59.990
Vielleicht können wir da noch querverweisen auf einen anderen Podcast, die Igalia Chats,

00:39:00.418 --> 00:39:04.990
die sowieso sehr hörenswert sind. Und die hatten, ich glaube, vorletzte Folge oder so,

00:39:04.990 --> 00:39:12.950
also haben die über Browser-Engines und eben die speziell in die Rendering-Engine gesprochen.

00:39:12.950 --> 00:39:20.550
Und was man eben da für einen Riesenaufwand treibt, es möglich zu machen, dass das halt mit 60 Frames pro Sekunde rendert.

00:39:20.727 --> 00:39:23.550
Die Folge First-Person-Scrollers? Jip.

00:39:23.842 --> 00:39:26.048
Die ist richtig richtig gut.

00:39:27.767 --> 00:39:34.697
Okay, das machen wir. Ja, Performance ist auch ... Allein das macht's ja unmöglich.

00:39:34.737 --> 00:39:41.177
Also, wenn man mal wirklich was geschrieben hat, was ein kompliziertes Problem oder was man für ein kompliziertes Problem löst,

00:39:41.217 --> 00:39:44.297
und dann sagt man, ich mach das jetzt so schnell wie's geht,

00:39:44.337 --> 00:39:48.217
dann ist das ja hinterher nicht mehr wiedererkennbar, was man da gebaut hat.

00:39:48.257 --> 00:39:52.017
Und wenn dann irgendwer kommt und sagt, bau mal das noch eben schnell dran.

00:39:52.057 --> 00:39:54.162
Oh-oh. Es ist halt schwierig.

00:39:55.548 --> 00:40:00.937
Ja. Vor allem, wenn du nicht wie ein Chrome-Team die ganze Infrastruktur hast, die automatisch Performance messen

00:40:00.997 --> 00:40:07.137
und Regressionen messen, das hast du ja nicht, wenn du ein JavaScript-IOP bist, der nur einen guten Job machen möchte.

00:40:09.574 --> 00:40:12.778
Ja, ist alles nicht so einfach, was wir hier so machen. Überhaupt nicht.

00:40:13.497 --> 00:40:18.377
Ich hab letztens wieder dieses wunderbare ... Was war das? Ich erinnere mich nur an die Domain.

00:40:18.437 --> 00:40:20.037
StillDrinking hieß es.

00:40:20.214 --> 00:40:23.597
Und dann irgendwie Programming. Keine Ahnung, wie war das?

00:40:24.625 --> 00:40:28.877
Programming sucks, genau. Das letztens wieder, das schicke ich halt immer irgendwelchen Normies,

00:40:28.877 --> 00:40:31.757
wenn die mich fragen, was machst du eigentlich den ganzen Tag und warum ist das so kompliziert?

00:40:34.132 --> 00:40:39.517
Schönes Essay, ein Klassiker. Okay, ja, schick mal rüber, kenn ich nicht.

00:40:40.073 --> 00:40:48.037
Okay, alles klar. Weitere Sachen, die so ein bisschen sucky sind, sind glaube ich die Element

00:40:48.037 --> 00:40:51.398
Ja, da haben wir, glaube ich, auch schon mal drüber gesprochen.

00:40:52.037 --> 00:40:59.365
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,

00:41:00.121 --> 00:41:03.659
die Default Area Roles, Formular APIs, dass man irgendwie sagen kann,

00:41:04.037 --> 00:41:07.593
ich bin ein Formular Element und ich repräsentiere jetzt diesen und jenen Wert,

00:41:08.178 --> 00:41:12.037
dass man auch submittable ist und so. Das ist da halt eben drin.

00:41:12.037 --> 00:41:16.037
Und das ist voll die Katastrophe, weil das alles irre komplex ist.

00:41:16.037 --> 00:41:19.053
Wird nicht besser, indem man davon einfach mehr hinzufügt.

00:41:20.998 --> 00:41:27.737
Ja, sind die, der nächste Punkt, diese Extended Build-Ins eventuell mal gedacht gewesen, um das leichter zu machen?

00:41:27.797 --> 00:41:33.555
Das ist doch, glaub ich, dieses, ich nehme ein Button zum Beispiel und gebe dem ein Is-Attribut.

00:41:33.907 --> 00:41:37.777
Und dann kann ich den upgraden mit extra Krempel.

00:41:38.804 --> 00:41:42.977
Das ist sozusagen der Gegenentwurf. Also, weil du könntest ja entweder sagen,

00:41:43.037 --> 00:41:47.977
ein Formularelement manifestiert sich, Ich baue alles neu, das wären so die Element internals.

00:41:48.017 --> 00:41:51.785
Du setzt deinen eigenen Formstate, du expost deine eigenen Area-Rules oder so.

00:41:52.226 --> 00:41:55.977
Oder du sagst, ich hab einen Button, der soll ein bisschen was extra können,

00:41:56.017 --> 00:41:59.017
und ich mach da halt eben diese Is-Extents-Geschichte drin.

00:41:59.057 --> 00:42:03.557
Die aber, glaub ich, nicht so auf Gegenliebe anderer Browserhersteller stößt, richtig?

00:42:03.597 --> 00:42:06.594
Also, nur das Chrome-Team hat das implementiert, richtig?

00:42:06.747 --> 00:42:11.167
Genau, und die anderen haben gesagt, das ist uns zu aufwendig Das, ja.

00:42:12.761 --> 00:42:16.966
Es ist halt auch schwierig, also was das ja im Wesentlichen macht,

00:42:16.966 --> 00:42:20.566
ist ja wirklich, also nehmen wir mal das Button-Element als Beispiel.

00:42:20.566 --> 00:42:23.366
Da hast du das Button-Element, das rendert ja was und du kannst das anklicken,

00:42:23.366 --> 00:42:26.903
damit kannst du interagieren, du kannst es fokussieren und es hat eine JavaScript-API.

00:42:27.173 --> 00:42:31.366
Und so wie die Extended Build-Ins bisher funktioniert haben, war,

00:42:31.692 --> 00:42:36.302
dass du im Wesentlichen eine Extension der Button-Klasse gemacht hast,

00:42:36.527 --> 00:42:41.757
wodurch du neue JavaScript-Methoden definieren konntest und das war's.

00:42:42.567 --> 00:42:45.326
Da war nix mit Shadow DOM oder Styling dranflanschen oder so,

00:42:45.386 --> 00:42:46.717
sondern das war halt irgendwie alles.

00:42:48.257 --> 00:42:51.766
Und ... das ist halt echt nicht viel wert.

00:42:53.433 --> 00:42:58.826
Also, wann willst du das schon mal? Wann willst du einfach so Buttons haben, die du erweitern willst,

00:42:58.886 --> 00:43:03.713
in dem Sinne, dass du sagst, du sollst eine extra Methode haben oder einen extra Event-Händler haben.

00:43:04.299 --> 00:43:08.134
Das ist nicht so oft der Fall. Und dafür diese ganze Maschinerie zu implementieren,

00:43:08.606 --> 00:43:13.406
Für diesen relativ kleinen Gewinn kann ich verstehen, dass einem der Trainer das nicht ...

00:43:13.466 --> 00:43:17.028
Kannst du da vielleicht irgendwie dann zumindest Styles reinscopen?

00:43:17.730 --> 00:43:18.206
Ging auch nicht.

00:43:18.909 --> 00:43:22.987
Nö, du extendest einfach nur eine Basisklasse. Okay, na ja, das ist dann ja wirklich nicht viel.

00:43:23.455 --> 00:43:25.706
Aber natürlich ein brutaler Aufwand.

00:43:26.183 --> 00:43:29.127
Weil du halt irgendwie sagen musst, ah, okay, im Rahmen eines Upgrades,

00:43:29.676 --> 00:43:32.306
wo ich ja nicht mehr diesen einen Spezialkase habe,

00:43:32.620 --> 00:43:38.106
dass ich meine HTML-Unknown-Element-Klasse swappen muss gegen was anderes, was ja schon kriminell genug ist,

00:43:38.106 --> 00:43:43.106
potenziell jedes Element gegen jedes andere swappen können.

00:43:42.729 --> 00:43:46.159
Und dass man dann vielleicht sagt, das irgendwie so zu generalisieren,

00:43:46.219 --> 00:43:50.079
ist halt relativ viel für relativ wenig Gewinn, äh, schwierig.

00:43:50.723 --> 00:43:56.859
Was jetzt nicht sagt, dass Extended Build-Ins nicht eine gute Idee wären, aber so wie hier definitiv nicht.

00:43:56.919 --> 00:43:59.437
Weil das ist eine seltsame API für wenig Mehrgewinn.

00:43:59.679 --> 00:44:04.459
Ich mein, du hast ja auch zwei verschiedene Arten, ein Custom Element in die Welt zu setzen,

00:44:04.519 --> 00:44:06.519
entweder per Tag oder per Is-Attribut.

00:44:07.233 --> 00:44:13.463
Das kannst du auch schon jemandem verkaufen. Ja, da wäre übrigens auch die interessante Frage, zur Laufzeit ändert.

00:44:14.259 --> 00:44:19.899
Das ist bestimmt auch ein fieser Dreckscase. Boah, ich würd sagen, dann hat's einfach keinen Effekt.

00:44:21.646 --> 00:44:25.019
Du kannst ja so was machen wie, wenn ein Element geupgradet ist,

00:44:25.079 --> 00:44:28.974
dann wird das Is-Attribut einmal ausgewertet und danach nie wieder angeschaut.

00:44:29.775 --> 00:44:31.423
Mhm. Also, das kannst du ja einfach entscheiden.

00:44:34.852 --> 00:44:39.439
Das war jetzt wieder dein Case von wegen, ach, ich will Elementeidentitäten austauschen.

00:44:39.439 --> 00:44:45.439
Ja, ich hab ja schon immer ein bisschen an den PETA gemimt und versucht, Standards kaputtzuschießen.

00:44:46.591 --> 00:44:51.119
Oder Ideen. Ja. Ich will sagen, Extended Build-Ins, super, aber nicht so.

00:44:51.389 --> 00:44:53.759
Das sollen sie mal ruhig sein lassen von mir aus.

00:44:53.819 --> 00:44:54.783
Das vermisst am Ende keiner.

00:44:55.512 --> 00:44:59.679
Also, boah, das hat halt so ein paar Use Cases, die ich mir so vorstellen könnte.

00:44:59.739 --> 00:45:03.056
Also, so mit den JavaScript-APIs, du willst irgendwie ein Input bauen,

00:45:03.714 --> 00:45:06.594
das so vorkonfektionierte Validierungsregeln hat, so mit der HTML5-Validierungs-API.

00:45:07.919 --> 00:45:11.086
So der einzige Use Case, wo ich mir wirklich sagen könnte, okay, ich will jetzt wirklich so ein

00:45:11.399 --> 00:45:16.599
Postleitzahlenfeld bauen und das soll dann dem Vorkonfektioniert werden mit den Validierungsregeln

00:45:16.830 --> 00:45:21.759
für deutsche Postleitzahlen. Das ist besser als irgendwie das entsprechende Regex-Attribut und so

00:45:21.759 --> 00:45:26.129
in HTML überall einzubauen, aber das ist alles einfach irgendwie zu wenig, um wirklich den,

00:45:26.679 --> 00:45:31.199
Aufriss wert zu sein. Andererseits brauchen wir meines Erachtens irgendeinen Mechanismus dafür,

00:45:31.756 --> 00:45:35.079
um diese Dinger extenden zu können, weil die Alternative hatten wir ja gerade mit den Internals,

00:45:35.079 --> 00:45:40.857
dass jeder und sein Hund eine eigene Implementierung vom Input-Element schreibt und das wird halt garantiert schief gehen.

00:45:43.404 --> 00:45:49.157
Ja, dann würde ich sagen, dann lassen wir diesen Kriegsschauplatz sich weiterentwickeln.

00:45:49.688 --> 00:45:54.441
Und wir nehmen uns einen Tüte Popcorn und schauen einfach in zehn Jahren noch mal drauf.

00:45:55.341 --> 00:45:59.302
Ich glaub, da können wir auch in zwei Jahren draufschauen. Da wird sich schon genug getan haben.

00:46:01.022 --> 00:46:06.136
Okay. Dann lassen wir die Webcomponents zumindest vorübergehend hinter uns.

00:46:06.414 --> 00:46:08.236
Ich weiß nicht, ob die noch mal kommen.

00:46:08.809 --> 00:46:12.576
Doch ein Teil kommt noch. Als Nächstes hätten wir hier das Cross-Origin-Attribut.

00:46:12.576 --> 00:46:23.136
Reden. Denn ich glaube, also meiner Ansicht nach ist das ja so ein bisschen diffus für viele,

00:46:23.136 --> 00:46:30.096
wann man das benutzen sollte. Und ich glaube, ich würde mich jetzt auch zu denen zählen,

00:46:30.096 --> 00:46:34.576
die das in ihrer, sagen wir mal, im maximalen Detail gerade auch nicht kennen. Zum Beispiel

00:46:34.576 --> 00:46:40.856
habe ich es noch nie benutzt mit nicht-anonymen Credentials. Aber wo man drüber stolpert ist,

00:46:40.856 --> 00:46:44.224
wenn man Fonts preloadet, da muss man das ersetzen.

00:46:45.187 --> 00:46:56.856
Und ansonsten meistens nicht. Und was da unten drunter eigentlich passiert, ist, dass

00:46:56.856 --> 00:47:04.191
in dem ganzen Network-Stack des Browsers so ein eigener, isolierter,

00:47:04.856 --> 00:47:08.856
Network-Stack aufgemacht wird, wo nur Cross-Origin-Ressourcen drüber geladen werden.

00:47:08.856 --> 00:47:16.569
Werden aus Security-Gründen, glaube ich, dass sie sich irgendwie nicht gegenseitig abhorchen können.

00:47:17.424 --> 00:47:25.679
Und bei den Fonts ist es eben nötig, weil die Font-Foundries sich früher ja immer ein bisschen

00:47:25.886 --> 00:47:29.856
in die Hose gemacht haben wegen Piracy und so.

00:47:30.180 --> 00:47:34.825
Deswegen wollten die ja auch keine TTFs oder sowas im Netz haben.

00:47:35.087 --> 00:47:41.036
Und darum muss es ja dann WOF richten, was letztlich auch nichts anderes ist als ein ZIP,

00:47:41.118 --> 00:47:45.036
das ein TTF enthält und, glaube ich, ein Lizenzfile oder so.

00:47:45.592 --> 00:47:50.831
Mhm. Ähm, genau. Und darum findet man dort das Cross-Origin-Attribut.

00:47:51.036 --> 00:48:00.036
Und ansonsten würde man das eigentlich nur benutzen auf Ressourcen, die man von einem anderen Origin holt,

00:48:00.824 --> 00:48:04.036
und dann quasi auswertet und weiterverarbeitet,

00:48:04.785 --> 00:48:10.880
wie zum Beispiel, wenn du ein Bild von einem fremden Server ziehst und das in eine Canvas rendern willst,

00:48:11.036 --> 00:48:13.841
dann müsstest du das Cross-Origin-Attribut setzen.

00:48:14.036 --> 00:48:20.008
Dann kannst du quasi, dann kannst du aber die Daten nicht mehr auslesen.

00:48:20.098 --> 00:48:23.036
Also, weil die dann, dann kommen die von einem fremden Server.

00:48:23.036 --> 00:48:26.624
Dann kannst du die verarbeiten, aber du kannst die nicht mehr auslesen.

00:48:27.036 --> 00:48:31.036
Also kannst du ... Hier sind quasi ein Block, wo du nicht reingucken kannst,

00:48:31.036 --> 00:48:32.863
das hinschieben kannst. Genau.

00:48:35.591 --> 00:49:01.085
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.

00:49:01.419 --> 00:49:04.461
So sieht's aus. Genau. Und wenn du das denn unbedingt in

00:49:04.461 --> 00:49:12.421
eine Canvas rendern musst, dann musst du das eben mit Cross-Origin laden und dann ist die

00:49:12.421 --> 00:49:15.821
Canvas aber quasi verschlossen. So sieht's aus.

00:49:16.002 --> 00:49:24.581
Ja. Genau. Sonst benutzt du das irgendwie groß?

00:49:25.293 --> 00:49:30.781
Ich baue doch keine ernsthaften Anwendungen. Damit hat sich das erledigt.

00:49:30.781 --> 00:49:38.781
Das löst halt Probleme, wo ich mir den Safety-Engineer-Ansatz immer wähle.

00:49:39.462 --> 00:49:44.781
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,

00:49:44.944 --> 00:49:47.465
vermeiden, dass ich darüber nachdenken muss.

00:49:48.392 --> 00:49:53.781
Ich brauche keinen Geländer über meinem Pot von kochender Säure zu machen, weil ich hab gar keinen Pot kochende Säure.

00:49:54.514 --> 00:49:59.781
Ich hab gar keine Fonts, die ich von Third-Party-Cross-Origin-Laden lade.

00:49:59.781 --> 00:50:04.281
Das ist lustigerweise, bei Fonts ist das ja auch, wenn du das nicht Cross-Origin lädst.

00:50:05.245 --> 00:50:09.467
Also das ist dann in dem Fall bei denen einfach nur deren Paranoia gewesen. Mhm.

00:50:09.917 --> 00:50:13.797
Also bei Fonts musst du das immer machen. Und ansonsten eben bei anderen Ressourcen,

00:50:14.301 --> 00:50:16.841
nur dann, wenn sie tatsächlich Cross-Origin sind.

00:50:16.901 --> 00:50:21.041
Und du planst dann noch irgendwie, was Unorthodoxes mit denen einzustellen.

00:50:21.881 --> 00:50:22.412
Ähm, genau.

00:50:23.341 --> 00:50:28.781
Und was halt eben auch wichtig ist zu wissen, ist, wenn du ein Preload für ein Bild hast,

00:50:29.245 --> 00:50:34.781
dann darfst du im Preload nicht Cross-Origin setzen, wenn du es beim Bild dann nicht verwendest, und umgekehrt,

00:50:34.781 --> 00:50:37.383
weil dann lädst du das Bild einfach zweimal.

00:50:38.013 --> 00:50:42.781
Nämlich der Browser lädt das einmal in dem quasi nicht Cross-Origin-Network-Stack

00:50:42.781 --> 00:50:44.684
und dann einmal in dem isolierten.

00:50:44.801 --> 00:50:50.781
Dann hast du quasi zweimal das Bild übertragen und ist auf gar keinen Fall gepreloadet.

00:50:51.246 --> 00:50:51.781
Aha, okay.

00:50:54.010 --> 00:50:57.781
Was ich auch schön daran finde, ist, dieses Attribut löst ein Problem,

00:50:57.781 --> 00:50:59.627
dass es nur in JavaScript gibt.

00:51:01.220 --> 00:51:18.325
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.

00:51:19.594 --> 00:51:24.798
Ha! Das HTML-Bestandteil, das nur sich um Scripting dreht und das nicht das Script-Element selber ist.

00:51:24.977 --> 00:51:26.870
Mhm. Suck it.

00:51:27.138 --> 00:51:36.870
Genau, als nächstes haben wir das Input-Pattern-Attribut. Finden wir das diskussionswürdig?

00:51:36.870 --> 00:51:39.786
Ich würde sagen, so nicht unbedingt.

00:51:40.237 --> 00:51:45.870
Kennt jeder, weiß jeder, nutzt keiner, außer um irgendwie die Tastatur dazu zu bringen,

00:51:45.870 --> 00:51:47.492
dass sie macht, was man möchte.

00:51:48.365 --> 00:51:55.870
Genau, dann Cores ist auch so ein HTTP-Header-Dings, find ich jetzt auch irgendwie nicht diskussionswürdig,

00:51:55.870 --> 00:51:58.870
weil haben wir schon drüber gesprochen, gibt's schon ganz lange.

00:51:59.240 --> 00:52:03.870
Ich wette, auch beim Survey wird da jeder sagen, natürlich habe ich das schon auf irgendwie Sternchen gesetzt,

00:52:03.870 --> 00:52:05.506
damit die Kiste endlich funktioniert.

00:52:09.647 --> 00:52:08.368
Ja.

00:52:12.267 --> 00:52:15.870
Genau. Funktioniert ja nur leider nicht, wenn man Credentials mitschicken muss,

00:52:15.870 --> 00:52:20.870
wie Cookies oder Basic Auth, dann das ist dann immer ein bisschen nervig.

00:52:20.870 --> 00:52:25.221
Also warum das dann eben nicht möglich ist, mit Sternchen zu beantworten.

00:52:25.860 --> 00:52:26.650
Ja. Ah ja.

00:52:27.858 --> 00:52:33.750
Genau, dann kommen aber die HTTP-Client-Hints. Ich glaube, die fristen ja ein bisschen ein Schattendasein.

00:52:33.998 --> 00:52:40.070
Weiß ich nicht, Shep, kannst du vielleicht zwischen 20 und 30 Minuten uns darüber erzählen, was die genau machen?

00:52:40.110 --> 00:52:48.510
Ähm, genau, die gibt's eigentlich auch schon ganz lange. Und die erfahren, sagen wir mal, ein bisschen einen Revival.

00:52:48.510 --> 00:52:55.510
Wofür die Gutsinn ist, du schickst eben von deinem Server aus HTTP-Header und sagst,

00:52:55.603 --> 00:53:00.510
ich hätte gerne von dem Browser noch Informationen zu, und klassischerweise war das

00:53:00.681 --> 00:53:06.510
deiner quasi Internetgeschwindigkeit oder der Anzahl CPU-Kerne.

00:53:06.775 --> 00:53:10.502
Also gibt es so ein paar Sachen, die man sozusagen anfordern konnte.

00:53:10.745 --> 00:53:18.973
Dann konntest du vielleicht bei darauf folgenden Requests, Das ging ja nur ab dem zweiten Request konntest du dann darauf reagieren.

00:53:19.189 --> 00:53:24.006
Auch noch ein Ding, was wir abfangen konnten, das war zum Beispiel die DPI-Zahl des Bildschirms.

00:53:24.510 --> 00:53:29.731
Und wenn du das zum Beispiel gemacht hast, also wenn dein HTML-Dokument diese Header geschickt hat,

00:53:30.010 --> 00:53:34.010
dann hat ja dein Browser im Anschluss das HTML-Dokument gepasst.

00:53:34.010 --> 00:53:37.338
Dann hat das, hat ja vielleicht die Bilder da drin gefunden,

00:53:37.510 --> 00:53:39.867
die auch wieder angefordert.

00:53:40.254 --> 00:53:49.630
Und weil ja vorher diese Bitte um Information zum Beispiel zur DPI-Zahl des Bildschirms, über das HTML-Dokument kam,

00:53:48.852 --> 00:53:54.703
hat der Browser dann eben mit diesen Requests nach den Bildern die DPI-Zahl auch als Info mitgeschickt.

00:53:55.145 --> 00:53:58.340
Und dann konnte oder dann kann der Server eben sagen, aha, okay,

00:53:58.466 --> 00:54:07.748
drei Pixel pro CSS-Pixel ist dein Bildschirm, dann kriegst du dieses Bild zurückgeliefert.

00:54:07.866 --> 00:54:14.466
Das war so der Use-Case für sowas. Oder ich bin schwach angebunden,

00:54:14.895 --> 00:54:18.666
dann kriegst du eben einfach ein viel stärker komprimiertes Bild,

00:54:18.919 --> 00:54:23.555
so ein Art-Responsive-Webdesign, aber von der Serverseite aus.

00:54:24.330 --> 00:54:30.166
Und das war bisher so, dass auch das New Chrome das umgesetzt hat.

00:54:30.487 --> 00:54:33.166
Ich glaube, kein anderer Engine hat das umgesetzt.

00:54:33.638 --> 00:54:38.148
Und warum das jetzt noch so ein bisschen Revival erfährt ist,

00:54:38.211 --> 00:54:42.166
weil die ganzen Browsersteller dazu übergehen,

00:54:42.166 --> 00:54:50.166
gehen ihre User-Agent-Strings zu, sagen wir mal, also weniger Informationen darüber preiszugeben

00:54:50.166 --> 00:54:52.166
über den User-Agent-String.

00:54:52.166 --> 00:54:58.166
Das heißt, Versionen des Browsers werden nur noch quasi ohne Kommastelle zurückgegeben.

00:54:58.277 --> 00:55:03.922
Ich glaube, Betriebssystemen wird auch nicht zurückgegeben und so diverse Dinge.

00:55:04.624 --> 00:55:11.166
Und um das eben zu kompensieren, wenn man einen Use-Case hat, wo man das eben wissen muss,

00:55:11.166 --> 00:55:32.526
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

00:55:32.792 --> 00:55:38.706
Aber so ganz stimmt das nicht, weil es gibt so eine Art Budget,

00:55:38.706 --> 00:55:40.866
wie viele Details du abfragen kannst.

00:55:41.137 --> 00:55:47.826
Und wenn du eben zu viel wissen willst über den Browser und dann quasi wieder Fingerprinting

00:55:47.826 --> 00:55:51.426
möglicherweise betreibst, dann sagt der Browser oder der Server sagt dann so,

00:55:51.426 --> 00:55:55.426
nee, der Browser sagt dann, das geht eben nicht.

00:55:55.550 --> 00:56:01.026
Du kriegst nur eben dieses Subset von den Sachen, die du haben wolltest,

00:56:01.284 --> 00:56:06.821
Und ja, also letztlich wird dann Fingerprinting verhindert.

00:56:07.026 --> 00:56:11.026
Und momentan ist das eben über den User-Agent-String eher möglich.

00:56:15.274 --> 00:56:19.026
Es ist ja quasi, das macht ja wirklich den Job vom User-Agent-String.

00:56:19.026 --> 00:56:25.026
Also man kriegt da ja die Informationen raus, so mehr oder minder, die man da früher indirekt hergeleitet hat.

00:56:25.977 --> 00:56:29.026
Genau, nur mit so einem gewissen Gatekeeping dann noch dazu obendrauf.

00:56:29.026 --> 00:56:33.026
Drauf. Ja und abzüglich des ganzen obskuren Templer-Wissens, das du halt eben brauchtest,

00:56:33.026 --> 00:56:37.869
um irgendwie genau rauszulesen, aha, der behauptet von sich irgendwie ein Mozilla zu sein, das heißt folgendes.

00:56:41.065 --> 00:56:45.332
Naja, und User-Agent-Sniffing für so Feature-Detection davon wird ja sowieso abgeraten.

00:56:46.467 --> 00:56:51.499
Deswegen, also, wenn man sich daran gehalten hat, dann sollte man im Grunde nicht davon betroffen sein.

00:56:51.575 --> 00:56:55.415
Es gibt schon Cases, wo Feature-Detection einen irgendwie nicht ans Ziel bringt.

00:56:56.171 --> 00:57:02.248
Also einer, der mir jetzt so da eingefallen ist, ist die Gap-Property in CSS.

00:57:03.121 --> 00:57:07.919
Die ja kein Aussager darüber trifft, ob sie auch in Flexbox unterstützt wird.

00:57:08.135 --> 00:57:13.239
Also die kam ja mit Grid und später wurde die quasi retrofitted auf Flexbox.

00:57:13.437 --> 00:57:16.624
Da haben die Browser ja auch gesagt, so, ja, kann ich, aber ...

00:57:17.569 --> 00:57:23.574
Tja, in welchem Kontext kannst du das? Also sprich, jetzt Feature Detection wäre dann so per Add-Supports-Regel.

00:57:25.365 --> 00:57:32.975
Genau. Oder du kannst ja auch CSS.Supports benutzen, wenn du JavaScript verwendest.

00:57:33.603 --> 00:57:34.728
Ja, okay.

00:57:36.186 --> 00:57:38.374
Ja gut, die Gap-Property, man müsste ja im Prinzip.

00:57:40.732 --> 00:57:43.975
Genau, es kommt auf den Kontext an, und das kriegst du mit Supports nicht abgefragt, das stimmt.

00:57:44.657 --> 00:57:47.475
Genau, das wäre halt so ein Fall, wo du vielleicht dann so, okay,

00:57:48.258 --> 00:57:50.975
jetzt muss ich aber wirklich dann mal wissen, was das für ein Browser ist,

00:57:50.975 --> 00:57:52.912
und dann habe ich hier meine interne Liste.

00:57:53.191 --> 00:57:55.721
Aber für Gap würdest du das dann auch nicht machen.

00:57:56.405 --> 00:58:02.975
Also es gibt einfach Use Cases, da kommst du, die kriegst du nur raus durch User-Agent-Sniffing,

00:58:02.975 --> 00:58:06.596
Aber vielleicht solltest du dann einfach um diese Features erst mal noch einen Bogen machen.

00:58:07.675 --> 00:58:12.015
Ja, beziehungsweise du kannst es ja generalisieren. Du kriegst das nur raus per das,

00:58:12.075 --> 00:58:14.914
was irgendwelche Blockchain-Hineys ein Orakel nennen würden.

00:58:15.445 --> 00:58:20.595
Also Daten, die halt nicht deinem System innewohnen, sondern wo du halt irgendwo anders hingucken musst,

00:58:21.701 --> 00:58:22.255
und daraus was herleiten musst.

00:58:22.315 --> 00:58:26.689
Ich mein, das sind ja unsere Problemchen, die wir vorhin mit Pixel-Rendering gesprochen haben,

00:58:27.315 --> 00:58:29.295
gehen ja auch in die gleiche Richtung.

00:58:29.355 --> 00:58:33.935
Das kriegst du aus dem Browser nicht raus, zu rendern und dann die pixel interpretieren und dann daran das erkennt

00:58:34.017 --> 00:58:39.595
herrlich banane guckst lieber nach bin ich edge auf windows so und dann

00:58:39.595 --> 00:58:43.475
aktiviert den hack oder auch eben nicht ja das stimmt ja das wäre so ein so ein

00:58:43.475 --> 00:58:49.615
fall auch ja es ist halt eben auch okay aber besserer user agent string ist es

00:58:49.615 --> 00:58:51.076
Und das ist ja schon viel wert.

00:58:54.407 --> 00:58:59.597
Dann haben wir die Resource-Fins. Ich glaube, über die müssen wir auch nicht sprechen.

00:58:59.597 --> 00:59:05.097
Also Preload, Preconnect, Prefetch, so das Zeugs.

00:59:05.840 --> 00:59:13.597
Eine Frage hätte ich ja dazu. Du als Performance-Papst, weißt du irgendwie oder wie schätzt du es ein,

00:59:13.597 --> 00:59:18.597
die Wahrscheinlichkeit, dass das irgendwie auf eine korrekte,

00:59:18.597 --> 00:59:21.597
zielführende Art und Weise eingesetzt wird?

00:59:22.881 --> 00:59:27.357
In den meisten projekten da draußen. weil ich meine das ist ja wahrscheinlich schon

00:59:27.357 --> 00:59:31.997
relativ diffizil zu entscheiden was muss jetzt mit welchem verfahren behandelt werden.

00:59:33.395 --> 00:59:43.317
Ja wahrscheinlich fifty fifty. also ich denke mal viele machen es gut. ich glaube dass dass

00:59:43.317 --> 00:59:49.957
man manchmal ein bisschen zu viel des guten einsetzt aber eher im sinne von es ist doppelt

00:59:49.957 --> 00:59:57.237
gemoppelt und schadet nicht. Also zum Beispiel, wenn jetzt dein Style-Sheet direkt unmittelbar

00:59:57.237 --> 01:00:02.917
nach deinen Resource-Hints kommt, dann musst du das nicht preloaden. Weil es geht ja darum,

01:00:03.301 --> 01:00:09.717
oder doch genau nicht preloaden, weil letztlich dienen ja die Resource-Hints dazu, dem Browser

01:00:09.717 --> 01:00:15.957
mitzuteilen, was er nicht selber finden kann. Oder vielleicht, was er erst relativ spät,

01:00:15.957 --> 01:00:19.874
so im Lebenszyklus des Renderings der Seite feststellt.

01:00:20.036 --> 01:00:21.648
Und da kann man ihn halt unterstützen.

01:00:22.980 --> 01:00:31.957
Und muss dann irgendwie nicht ein Preload in die Zeile vor das LinkRail-Style-Sheet setzen, das er so unmittelbar danach findet.

01:00:33.457 --> 01:00:38.457
Genau, ich glaube, das gibt's schon öfters. Aber das tut halt nicht weh.

01:00:39.301 --> 01:00:48.777
Und ich kann mir aber vorstellen, manche Leute zu viele Dinge preloaden, die nicht pregeloaded werden müssten.

01:00:50.419 --> 01:01:20.249
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

01:01:20.249 --> 01:01:21.873
kann, ist mit Webpagetest.

01:01:22.683 --> 01:01:27.148
Die geben einem ja so ein relativ, also lowlevelige Daten zurück,

01:01:27.249 --> 01:01:30.249
wie so das Ladeverhalten des Browsers ist.

01:01:30.249 --> 01:01:36.150
Man kriegt dann so einen Wasserfall. In dem Wasserfall kann man auch sehen, welche Ressource vielleicht

01:01:36.340 --> 01:01:38.249
von der anderen abhängt.

01:01:38.249 --> 01:01:46.249
Und man kann auch sehen, welche Ressource quasi irgendwie, oder welche JavaScript-Ressource wie viel CPU-Zeit verbrät und so.

01:01:46.249 --> 01:01:54.249
Das finde ich halt sehr praktisch. Und da kann man möglicherweise auch erkennen, ob bestimmte Elemente,

01:01:54.249 --> 01:01:59.249
die vielleicht jetzt zum Beispiel für den largest content für Paint irgendwie relevant sind,

01:01:59.611 --> 01:02:06.249
oder andere Dinge, ob die zu spät kommen und ob man da vielleicht einen Hint hinzufügen könnte für den Browser,

01:02:06.249 --> 01:02:10.249
der einfach früher schon mal diese Ressource sich holt.

01:02:11.151 --> 01:02:11.637
Mh.

01:02:13.195 --> 01:02:16.832
Und andersrum sieht man vielleicht auch, dass Ressourcen sich zwischendrängeln.

01:02:17.282 --> 01:02:25.045
Ähm, und entweder liegt das auch an Ressources, die man gesetzt hat, die man vielleicht wieder rausnehmen sollte.

01:02:25.699 --> 01:02:31.019
Weil Bild Nummer drei spielt gar keine Rolle bei Largest Contentful Paint.

01:02:31.479 --> 01:02:34.647
Warum soll das irgendwie auch gepreloaded werden?

01:02:35.196 --> 01:02:40.112
Und was es dann auch gibt, das ist hier auch, glaube ich, eine Liste drin, es gibt dann noch zusätzlich,

01:02:41.045 --> 01:02:43.045
das Fetch Priority Attribut.

01:02:43.045 --> 01:02:49.045
Ganz neu, wo man vielleicht, wenn man jetzt sieht, okay, ich hab was nicht gepreloaded

01:02:49.303 --> 01:02:55.045
und dennoch drängelt es sich vor, dann kann man es mit Fetch Priority runter priorisieren.

01:02:57.711 --> 01:03:01.045
Also es ist dann so ein bisschen so ein Kneten und Modellieren,

01:03:01.045 --> 01:03:07.045
dass am Ende eben das, so der Wasserfall dann die Form annimmt, die man gerne hätte.

01:03:07.045 --> 01:03:10.404
Okay, aber das ist ja schon wirklich ein gutes Tool dafür.

01:03:13.924 --> 01:03:10.404
Ja.

01:03:15.131 --> 01:03:18.805
Ja, genau, da habe ich noch eine Anekdote und zwar in dem Projekt,

01:03:18.805 --> 01:03:22.805
das wir aktuell benutzen. Da haben wir ein relativ umfangreiches

01:03:22.805 --> 01:03:30.805
HTML-Dokument, das also sozusagen relativ lange zum Übertragen braucht, was aber an sich kein Problem wäre, weil HTML ist ja

01:03:30.805 --> 01:03:42.975
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.

01:03:43.263 --> 01:03:55.316
Jetzt hatten wir allerdings das Problem, dass der NGINX, der das ausliefert, Das CSS.

01:03:56.424 --> 01:04:19.614
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,

01:04:20.352 --> 01:04:22.486
erst dieses HTML-Dokument zu ziehen,

01:04:22.801 --> 01:04:27.626
weil davon, also der Server hat ja gesagt, das CSS braucht das vorher fertig.

01:04:28.202 --> 01:04:32.514
Das heißt, ich fang nicht an, irgendwelche Sachen parallel zu machen. Mhm.

01:04:32.554 --> 01:04:37.096
Und das hat wiederum dazu geführt, dass der First Contentful Paint,

01:04:37.483 --> 01:04:42.722
dass der einfach wahnsinnig spät war, also wahnsinnig spät in Performance, ne?

01:04:43.317 --> 01:04:49.794
Mhm. Und der Browser, der guckt halt sozusagen, was er an Informationen vom Server bekommt.

01:04:49.794 --> 01:04:57.234
Drinsteht, so hey, HTML, das bitte erst mal hier exklusiv ziehen und erst danach das CSS,

01:04:57.234 --> 01:04:59.025
dann macht ihr das halt auch.

01:04:59.434 --> 01:05:05.597
Und meistens ist das eine gute Sache, dass man so eine quasi Dependency-Chain aufbaut,

01:05:05.674 --> 01:05:13.501
aber im Falle von progressiven Dateiformaten ist es halt schade, weil man ja viel Zeit liegen lässt.

01:05:13.794 --> 01:05:18.930
Und was ich dann gemacht habe, ist, dass ich tatsächlich unser CSS geinlined habe.

01:05:19.785 --> 01:05:27.725
Damit das eben bereitsteht mit dem ersten Schwall HTML. Auch wenn es dann nicht cachebar ist und all diese Dinge.

01:05:27.994 --> 01:05:36.994
Aber der Browser kann dann eben sofort losrendern. Weil er rendert eben dann erst sonst los, wenn das CSS da ist.

01:05:38.474 --> 01:05:38.834
Mh...

01:05:40.427 --> 01:05:47.217
Ähm, genau, also das nur so als kleine Anekdote. Da könnt ihr auch mal drauf gucken,

01:05:47.323 --> 01:05:51.212
wenn eure First Contentful Paint irgendwie nicht so besonders prickelnd ist.

01:05:52.400 --> 01:05:56.217
Dann könnt ihr in den Webpagetest euch diesen Wasserfall angucken.

01:05:56.277 --> 01:06:02.217
Und da steht dann zum Beispiel eben auch drin, ähm, ist ein Stream exklusiv geflaggt?

01:06:02.277 --> 01:06:06.867
Also darf der quasi nicht parallel zu anderen Sachen abgearbeitet werden?

01:06:07.217 --> 01:06:12.717
Und man sieht auch, welcher Stream von welchem anderen abhängig ist.

01:06:13.717 --> 01:06:18.209
Und da war das eben bei uns so, und das ließ sich nur auf diese Weise auflösen.

01:06:18.687 --> 01:06:22.477
Das wär jetzt nämlich mal eine Frage gewesen, wie kommt das denn zu diesem Flag?

01:06:22.517 --> 01:06:26.987
Also ist das dann einfach irgendwelcher Out-of-scope-Backend-Krempel, der das verursacht?

01:06:27.257 --> 01:06:36.517
Ich glaube, das ist einfach im NGINX so konfiguriert, dass der bestimmte Ressourcen halt wichtiger erachtet als andere.

01:06:36.517 --> 01:06:43.177
Und dann eben sagt, die haben eine hohe Priorität. Das heißt, zum einen sollen die quasi exklusiv abgearbeitet werden,

01:06:43.177 --> 01:06:49.177
damit möglichst wenig Zeit vergeht, damit irgendwie nicht parallel noch andere Daten geschickt werden.

01:06:49.412 --> 01:06:56.677
Und der hat eben auch so eine Reihenfolge drin, dass halt glasklar ist, das HTML ist halt das Wichtigste.

01:06:57.864 --> 01:07:03.644
Dann kommt CSS und dann kommt der ganz andere Kram. Aber in dieser Konstellation ist das halt schlecht.

01:07:04.355 --> 01:07:20.541
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.

01:07:20.793 --> 01:07:33.677
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.

01:07:34.027 --> 01:07:36.466
Und das lässt sich irgendwie nicht formulieren derzeit.

01:07:37.816 --> 01:07:38.672
Okay, verstehe.

01:07:40.625 --> 01:07:46.270
Genau, ich weiß nicht, wie die anderen Server das flanken. Das habe ich mir jetzt nicht angeschaut.

01:07:47.044 --> 01:07:52.475
Vielleicht haben die andere Defaults, die dann in dem Fall irgendwie einen besseren Outcome haben.

01:07:56.475 --> 01:08:00.475
Okay, verstehe. Aber gut, dann kriegt man es halt auf die Weise in den Griff.

01:08:00.772 --> 01:08:06.475
Es ist ja am Ende alles eine Reihe von einander getürmten Hacks und Workarounds.

01:08:06.475 --> 01:08:07.749
So ist das nur mal mit dem Computer.

01:08:12.275 --> 01:08:19.533
Jawoll. Genau, du stellst gerade fest, dass wir schon bei einer Stunde sind. Nicht wahr?

01:08:21.793 --> 01:08:25.781
Da haben wir letztes Mal auch den Cut gemacht. Also bei etwas über einer Stunde.

01:08:25.975 --> 01:08:31.641
Vielleicht machen wir den dann auch jetzt. Und hängen einen Teil drei von X an.

01:08:31.722 --> 01:08:33.496
Wobei wir ja auf Seite zwei sind.

01:08:33.964 --> 01:08:34.666
Von vier.

01:08:35.818 --> 01:08:43.254
Von vier, okay. Ja, dann macht euch noch auf was gefasst. In den kommenden Wochen.

01:08:43.875 --> 01:08:45.568
Und dann machen wir hier Schluss.

01:08:46.225 --> 01:08:49.205
Ich bedanke mich wieder. Es war mir wie immer ein Vergnügen.

01:08:50.141 --> 01:08:54.755
Ja, ne, fand ich auch gut. Man lernt ja immer dazu, und letztlich sind das ja immer alles nur so

01:08:54.755 --> 01:08:59.855
Aufhänger, so wie unser Glücksrad, dann mal sich zu befassen mit bestimmten Themen.

01:09:01.241 --> 01:09:04.247
Ja, ich wollt's grad sagen, es ist halt ein JavaScript-Leitglücksrad quasi.

01:09:05.337 --> 01:09:06.495
Ja. Und das ist ja auch okay.

01:09:07.371 --> 01:09:13.565
Genau. Wenn ihr höhere und höhere Erfahrungen, Input-Ideen zu den Themen,

01:09:13.895 --> 01:09:18.055
die wir jetzt in dieser Folge besprochen haben, habt, dann schickt sie uns gerne zu.

01:09:18.561 --> 01:09:22.975
Auf mastodonX oder auch auf Slack.

01:09:23.728 --> 01:09:29.895
Und genau. Ansonsten würden wir sagen, hört ihr uns weiter debattieren,

01:09:29.895 --> 01:09:32.895
entweder nächste Woche oder die Woche drauf.

01:09:33.631 --> 01:09:38.655
So machen wir das. Genau. Alles klar. Dann danke fürs Zuhören. Bis dann. Tschüssi. Tschüss.

01:09:39.600 --> 01:10:02.640
Music.

01:10:27.932 --> 01:10:47.728
Fuck. Aber gut, dass wir eine kahle Aufnahme haben, du. Läuft ja, läuft ja, herrlich, okay.

01:10:50.303 --> 01:10:53.103
Entschuldigung, ich wollte dich nicht so rauswerfen. Nee, du hast auch recht.

01:10:55.345 --> 01:10:56.322
Hahaha!

01:10:58.999 --> 01:11:03.392
Genau. Sabine, wir lachen übrigens, weil wir die Gesamtaufnahme in Zencaster nicht gestartet haben.

01:11:04.428 --> 01:11:09.402
Und mir fällt nichts Besseres ein, als mitten im Satz Shep das einfach mal so in den Chats zu schreiben.

01:11:09.649 --> 01:11:11.089
Ja, stimmt. Nun denn.

01:11:12.493 --> 01:11:19.065
Die Frage ist, Shep. Ja? Das landet in den Outtakes. Das landet in den Outtakes, denk ich.

01:11:20.181 --> 01:11:30.042
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

01:11:30.042 --> 01:11:38.195
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

01:11:38.627 --> 01:11:42.642
herrlich entschuldigung wie kommen wir jetzt da wieder rein,

01:11:43.317 --> 01:11:46.513
Ich weiß auch nicht. Ich weiß gar nicht, was ich zuletzt gesagt hab.

01:11:46.963 --> 01:11:48.502
Äh, ich ...

01:11:49.106 --> 01:11:50.822
Ich wollt's mir noch merken, aber ...

01:11:51.815 --> 01:11:58.862
Ich setz einfach noch mal an. Ja, genau. Ähm, und der Browser, der guckt halt sozusagen,

01:11:58.862 --> 01:12:00.593
was er an Informationen vom Server bekommt und wenn er drin steht...