WEBVTT

00:00:00.017 --> 00:00:06.677
Bei Dialog war ja noch kritisch anzumerken, dass der Modalmodus, ja deklarativ, gar nicht aktiviert werden kann.

00:00:07.617 --> 00:00:10.919
Es gibt ja diese Popover-API, jetzt auch relativ frisch.

00:00:11.162 --> 00:00:19.813
Da kannst du quasi sagen, eben wenn ich hier klicke, dann bitte mach dieses Popover auf.

00:00:20.129 --> 00:00:24.817
Und das kannst du nur mit HTML und Beziehungen zueinander ausdrücken.

00:00:26.142 --> 00:00:33.077
Je mehr ich drüber nachdenke, umso weniger gefällt mir das. Und deswegen denke ich, Leute, nehmt's JavaScript, nehmt's HTML, nehmt's CSS, dafür ist es da.

00:00:33.077 --> 00:00:34.877
Wenn ihr was Spezielles haben wollt, dann macht das.

00:00:34.946 --> 00:00:37.224
Wenn ihr was weniger Spezielles haben wollt, nehmt dann eine Library.

00:00:37.467 --> 00:00:40.420
Und ansonsten braucht ihr vielleicht auch einfach gar keine Tabs, sondern einfach nur eine Liste von Zeug.

00:00:43.543 --> 00:00:46.877
Diese Revision von Working Draft wird euch präsentiert von Midwild.

00:00:46.877 --> 00:00:48.918
Next-Level-Hosting für deine Projekte.

00:00:49.260 --> 00:00:53.311
Ihr fragt euch jetzt bestimmt, wie kann sowas Langweiliges wie Hosting Next-Level sein?

00:00:53.824 --> 00:00:57.641
Ganz einfach. Midwalds hochperformantes Cloud-Hosting ist perfekt abgestimmt

00:00:58.046 --> 00:01:00.162
auf die Anforderungen von Freelancern und Agenturen.

00:01:00.810 --> 00:01:04.177
Es gibt z.B. ein smartes Rollensystem für die Zusammenarbeit mit euren Projektpartnern.

00:01:04.177 --> 00:01:08.177
Und Midwald hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche gebaut,

00:01:08.525 --> 00:01:09.704
mit der das Arbeiten Spaß macht.

00:01:10.181 --> 00:01:14.745
Aber jetzt mal unter uns Nerds. Sachen anklicken in einem User-Interface? Muss das sein?

00:01:17.068 --> 00:01:19.336
Nein, muss es nicht. Denn bei Midwald gibt's die M-Studio CLI.

00:01:19.760 --> 00:01:24.612
Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch Automatisieren.

00:01:25.170 --> 00:01:29.590
Von Nerds für Nerds bringt euch Midwald die optimale Developer Experience, wenn's ums Hosting geht.

00:01:30.220 --> 00:01:37.224
Und deshalb jetzt auf zu midwald.de slash workingdraft. Egal, ob mit Curl oder mit so nem grafischen Browser,

00:01:37.530 --> 00:01:42.997
es schreibt sich auf jeden Fall mittwald.de slash workingdraft.

00:01:43.037 --> 00:01:47.270
Und alle Infos zu Midwald findet ihr natürlich auch noch mal in den Shownotes zu dieser Revision.

00:01:47.811 --> 00:01:57.237
Wir danken Midwald für die Unterstützung von dieser Revision von Working Draft. Revision 585.

00:01:58.000 --> 00:02:22.480
Music.

00:02:23.100 --> 00:02:26.950
Heute sind wir nur zu zweit. Der hat mir zum einen den Peter.

00:02:27.106 --> 00:02:30.950
Moin, moin. Und ich bin der Shep.

00:02:31.220 --> 00:02:38.826
Und ja, es ergibt sich, dass es dieses Jahr nicht nur ein State-of-JS und State-of-CSS

00:02:38.950 --> 00:02:42.733
Survey geben wird, sondern auch ein

00:02:42.950 --> 00:02:50.950
ganz neu, ein State-of-HTML Survey, mit dessen Erstellung die Lea Verou beauftragt wurde.

00:02:50.950 --> 00:02:56.650
Und das finden wir zum einen ziemlich cool, also ich zumindest,

00:02:57.020 --> 00:02:59.950
dass HTML auch eine entsprechende Survey mal bekommt,

00:02:59.950 --> 00:03:10.450
denn die dient ja nicht nur unserem Entertainment und einer, weiß ich nicht, nicht weiter genutzten Datenerhebung,

00:03:10.450 --> 00:03:19.450
sondern die Browserhersteller benutzen diese State-of-Surveys ja mittlerweile als Grundlage, um eben zu entscheiden,

00:03:19.450 --> 00:03:28.750
was für Features pushen wir und was für Features wandern in diese Interop-Bemühungen,

00:03:28.750 --> 00:03:36.050
wo eben alle Browser-Hersteller versuchen, bestimmte Features auf dem gleichen Stand zu bringen

00:03:36.378 --> 00:03:40.177
in ihren Browsern. Und das war halt bei HTML bisher nicht.

00:03:41.545 --> 00:03:44.690
Nee, aber wenn man sich da mal in diese GitHub-Diskussion einklingt,

00:03:44.690 --> 00:03:55.130
die jetzt hier die Quelle für unsere Revision ist, Dann laufen da tatsächlich auch so einige Leute aus den Browserherstellern rum und sagen so diese jene Frage ist für uns besonders interessant.

00:03:56.084 --> 00:04:05.005
Also das ist definitiv relevant, dass dahinterher nicht nur die Working-Draft-Revision zuzuhören, sondern auf jeden Fall da auch abzustimmen und mitzuteilen, was einen interessiert und was man schon verwendet und was nicht.

00:04:06.869 --> 00:04:10.130
Ja, ich weiß nicht wann die geplant ist, wann die fertig sein soll.

00:04:10.130 --> 00:04:17.941
Genau, aber ich denke mal, wer uns auf den verschiedenen sozialen Medien, wie auch immer sie heißen, folgt, wird es vielleicht dann auch mitbekommen.

00:04:18.130 --> 00:04:27.130
Weil wir das bestimmt auch entweder über unseren Account, also Podcast-Account oder persönlich retweeten oder reposten oder retooten werden.

00:04:27.130 --> 00:04:30.014
Reaxen sagt man, glaube ich, jetzt.

00:04:30.302 --> 00:04:31.130
Oder reaxen.

00:04:31.778 --> 00:04:36.130
Genau, und wir haben hier in diesem GitHub-Repo einfach gesagt,

00:04:36.279 --> 00:04:39.907
wir gucken da jetzt mal rein und sortieren nach Upvotes,

00:04:40.222 --> 00:04:48.130
also die verschiedenen Vorschläge, was da so abgefragt werden soll in diesem Survey. Und da sind ein paar Sachen dabei,

00:04:48.130 --> 00:04:52.130
wo wir auch gesagt haben, okay, die haben jetzt keinen Neuigkeitswert,

00:04:52.130 --> 00:04:56.130
oder da haben wir schon drüber gesprochen, die würden wir jetzt einfach überspringen,

00:04:56.130 --> 00:05:05.176
aber es sind halt eben auch einige Dinge dabei, die relativ neu sind oder wo wir noch nicht viel drüber gesprochen haben oder die wir vielleicht auch noch nicht mal kannten.

00:05:07.778 --> 00:05:15.880
Und genau, würde ich sagen, können wir direkt mal das erste uns schnappen und das wäre das Dialog-Element.

00:05:16.798 --> 00:05:25.305
Jawohl, ein aufklappbares, nee, nicht aufklappbares Widget, aber tatsächlich so, dass der typische Dialog, den man sonst per Window Alert macht,

00:05:25.350 --> 00:05:33.020
mit, ja, eben als HTML-Element, man kann Formulare reinbasteln, man kann beliebigen Content reinbasteln und.

00:05:34.254 --> 00:05:36.933
Kümmert sich dann halt um so Krempel wie, dass es einen Hintergrund gibt,

00:05:36.933 --> 00:05:39.453
dass da der Z-Index ordentlich gemanagt wird.

00:05:40.096 --> 00:05:43.733
Und dass halt eben auch so Sachen wie Fokusmanagement und so zumindest innerhalb eines Browsers

00:05:43.733 --> 00:05:47.667
da einigermaßen gleich funktionieren, dass es da von Nutzerseite her auch weniger Überraschungen gibt.

00:05:48.486 --> 00:05:53.133
Genau, also es sind ja viele Sachen, die da sozusagen drin gekapselt sind.

00:05:53.133 --> 00:06:04.465
Ich glaube, du kannst das, dieses Dialog-Element wahlweise als Modal oder eben auch nicht als Modal öffnen.

00:06:04.744 --> 00:06:09.408
Da ist ja der Unterschied sozusagen, dass wenn du ein Modal hast oder Modal,

00:06:10.110 --> 00:06:18.553
dass dann dein Fokus in diesem Element gecaptured wird und du nicht mehr quasi rauskommst, wenn du es nicht schließt.

00:06:18.553 --> 00:06:24.576
Und in der anderen Variante, der Non-Modal-Version, ist das eben nicht so.

00:06:25.576 --> 00:06:34.362
Und das hat natürlich zur Auswirkung darauf, wie das so allgemein funktioniert, ob es jetzt wirklich über allem drüber liegt und halt tatsächlich auch mit seinem Background so ist, oder ob das einfach ein HTML-Element ist, das da irgendwo im Flow drin ist.

00:06:35.388 --> 00:06:38.773
Ich glaube, das liegt schon immer über allem drüber, soweit ich weiß.

00:06:39.142 --> 00:06:42.761
Es ist nur quasi, ob das so ein Fokus-Trapping macht oder eben nicht.

00:06:43.049 --> 00:06:45.078
Also, das ist, glaub ich, der Unterschied.

00:06:45.138 --> 00:06:49.567
Und was ja da auch neu eingeführt wurde, was also in der Browser-Plattform ...

00:06:50.422 --> 00:06:55.578
Ich glaube, es gibt noch irgendein anderes Element, das es auch nutzt, das mir grade nicht einfällt.

00:06:55.751 --> 00:06:58.380
Aber es gibt jetzt ja so was wie so eine Top-Layer.

00:06:59.307 --> 00:07:06.770
Und die kann man sich so ein bisschen vorstellen wie das, in Frameworks wie React, früher unter dem Namen Portal, lief.

00:07:06.959 --> 00:07:12.820
Also dass du quasi so eine Stelle im DOM hast, die garantiert immer über allem anderen liegt.

00:07:12.998 --> 00:07:18.078
Genau, also weil das Problem ist, also es ist ja ein Trugschluss zu glauben,

00:07:18.118 --> 00:07:23.578
dass man mit hohen Z-Indexen sich immer quasi über alles andere drüberlegen kann.

00:07:23.618 --> 00:07:24.315
Ja.

00:07:24.658 --> 00:07:27.378
Weil die ja sozusagen immer wieder ...

00:07:28.555 --> 00:07:33.147
Weil die Z-Indexe im Prinzip ja immer eingesperrt werden durch Stacking-Kontexts.

00:07:33.201 --> 00:07:40.069
Und von denen haben wir halt allerlei auf der Seite. Und da, also man gerät schnell in einen Stacking-Kontext hinein.

00:07:40.736 --> 00:07:47.898
Und dann kann man auch mit Z-Index eine Milliarde eben auch nicht mehr aus diesem Stacking-Kontext herauskommen.

00:07:47.898 --> 00:07:51.098
Und wenn der eben nicht zufälligerweise auf der obersten Schicht liegt,

00:07:52.015 --> 00:07:57.840
dann liegt eben auch ein Element darin nicht auf der obersten Ebene.

00:07:58.560 --> 00:08:01.936
Und genau, da gibt es eben diese, ich glaube, die heißt auch Toplayer.

00:08:02.017 --> 00:08:05.938
Und darin öffnet sich eben dieses Dialog-Element.

00:08:05.938 --> 00:08:13.938
Und das hat wiederum dann, glaube ich, den Nebeneffekt, dass wenn du Custom-Properties auf dein Root-Element definierst,

00:08:14.161 --> 00:08:16.502
sie da nicht hinein vererbt werden.

00:08:16.938 --> 00:08:22.938
Zumindest nicht in den Backdrop, der dann hinter dem Model da liegt.

00:08:22.938 --> 00:08:27.781
Der ist tatsächlich nicht, äh, ja, custom, äh, property-style,

00:08:27.938 --> 00:08:29.006
Property-Style war, das stimmt.

00:08:30.986 --> 00:08:40.583
Ja, ansonsten, tja, also aus, ich denk mal so aus Accessibility-Gesichtspunkten ist es ein super Feature,

00:08:40.772 --> 00:08:47.091
weil bisher so ein Dialog-Element irgendwie vernünftig zu bauen, war schon ziemlich schwierig.

00:08:48.109 --> 00:08:55.336
Auch eben dieses Focus-Trapping, dass man eben per Tab oder so nur innerhalb des,

00:08:55.336 --> 00:08:58.893
sich des Dialog-Elements bewegen kann, aber nicht rauskommt.

00:08:59.811 --> 00:09:01.136
Das war schon nicht so ganz einfach.

00:09:01.954 --> 00:09:06.041
Ich würde das anders charakterisieren. Ich würde sagen, das ist auf jeden Fall sehr einfach, das zu bauen,

00:09:06.905 --> 00:09:09.136
aber sehr anspruchsvoll, das richtig zu bauen.

00:09:09.687 --> 00:09:14.136
Aber je nachdem, was dein Use Case ist, merkst du möglicherweise nicht, wenn du es nicht richtig gebaut hast.

00:09:14.136 --> 00:09:16.136
Und dann hast du halt so eine halbgare Lösung da,

00:09:16.136 --> 00:09:21.136
die zwar irgendwie im aktuellen Beispiel ganz oben liegt und wo das mit dem Fokus auch kein Problem ist

00:09:21.136 --> 00:09:25.136
und wo du dann denkst, wunderbar, ich brauche mir keine Dependency irgendwie installieren

00:09:25.261 --> 00:09:27.136
mit dem Ding in fertig aus implementiert.

00:09:27.136 --> 00:09:31.776
Selber hinbekommen und dann bist du in deiner eigenen Implementierung irgendwann gefangen,

00:09:31.776 --> 00:09:35.176
bevor du merkst, dass du da eine ganze Menge Dinge berücksichtigen musst, an die du zuerst

00:09:35.451 --> 00:09:38.856
nicht gedacht hast, weil sie halt eben nicht offensichtliche Sachen sind, wie das Fokus

00:09:38.856 --> 00:09:44.976
Management, die Accessibility und so weiter. Ja, wobei ich finde, also ich persönlich finde,

00:09:44.976 --> 00:09:50.896
wenn man das so bauen wollte, also ich meine, worauf du Bezug nimmst, ist sozusagen,

00:09:50.896 --> 00:09:54.896
also dass es augenscheinlich einfach ist, so was zu bauen.

00:09:55.157 --> 00:09:55.643
Scheinbar.

00:09:56.526 --> 00:10:01.896
Ja, okay. Genau. Weil das kommt ja auch später vor, aber vielleicht ist das ein guter Moment,

00:10:01.896 --> 00:10:05.896
auch das inert-Attribut zu erwähnen. Das ist ja auch relativ neu.

00:10:05.896 --> 00:10:10.893
Ich glaube, die kamen so im Gleichschritt, die zwei Features in die Browser.

00:10:11.010 --> 00:10:18.896
Wenn du das inert-Attribut auf irgendwas setzt, dann schaltest du quasi jegliche Interaktivität,

00:10:19.653 --> 00:10:24.496
mit diesen also mit dem Element und seinen ganzen Kind Elementen aus.

00:10:25.567 --> 00:10:28.876
Das heißt also kannst du nicht mehr rein tabben und nicht mehr nix mehr fokussieren

00:10:28.876 --> 00:10:32.076
und so, auch mit der Maus nicht.

00:10:31.365 --> 00:10:39.170
Aber was ich halt bei dem Inert-Attribut doof finde, weil man könnte ja sagen, ah, cool, ich könnte mir so was ähnliches wie einen Dialog

00:10:39.170 --> 00:10:43.170
auch mit dem Inert-Attribut bauen, indem ich einfach zum Beispiel auf den Body

00:10:43.170 --> 00:10:47.170
einen Inert setze und auf dieses Element, was dann eben

00:10:47.299 --> 00:10:51.170
Fokus trappen soll, da mache ich dann Inert wieder False,

00:10:51.413 --> 00:10:55.170
sodass das eben alles, was da drin ist, durchaus fokussierbar ist.

00:10:55.170 --> 00:11:03.962
So ein bisschen wie bei der CSS-Visibility, da kannst du ja quasi auch auch hidden setzen und darin irgendein Element wieder auf visible und das funktioniert.

00:11:04.170 --> 00:11:12.670
Aber leider ist inert nicht so konzipiert. Also es ist kein, du kannst es nicht auf irgendwie false setzen,

00:11:12.670 --> 00:11:16.952
um dann innerhalb einer inert area das wieder aufzuheben.

00:11:17.375 --> 00:11:24.073
Und das finde ich schon ein bisschen schwierig. Also du kannst, du musst quasi dann dein

00:11:24.280 --> 00:11:27.980
nicht inertes overlay parallel zu,

00:11:28.808 --> 00:11:33.318
vielleicht einem E-Nerden Rapper um deinen restlichen Content packen.

00:11:34.371 --> 00:11:41.170
Sonst klappt das einfach nicht. Hm. Ja, also wenn man sich jetzt wirklich anschaut,

00:11:41.170 --> 00:11:45.147
wie das inert-Attribut spezifiziert ist, da steht ja buchstäblich drin,

00:11:45.210 --> 00:11:49.170
wenn inert, dann ignoriert der Browser das betroffene Element.

00:11:51.512 --> 00:11:57.170
Also wenn das sozusagen wirklich die, ja, die Konzeption ist, dann ist es halt relativ schwierig zu sagen,

00:11:57.170 --> 00:12:01.490
schwierig zu sagen, du ignorierst dieses Element, um halt eben dann Kind Elemente

00:12:01.490 --> 00:12:03.490
daraus wieder rauszunehmen, muss man es ja nicht ignorieren.

00:12:04.295 --> 00:12:08.930
Ja, aber bei Visibility funktioniert das ja auch und rein vom Bauen her, finde ich,

00:12:08.930 --> 00:12:14.850
würde sich das eben anbieten, wenn es nicht so wäre, weil wir einfach eine Baumstruktur haben

00:12:14.850 --> 00:12:23.570
und in der Regel ist ja dann bei solchen Overlays immer der Wunsch, hey, alles andere soll nicht

00:12:23.686 --> 00:12:27.584
nicht mehr interagierbar sein, außer das, was im Overlay drin ist.

00:12:27.791 --> 00:12:30.275
Und das kannst du eben mit dem Inert-Attribut ...

00:12:31.644 --> 00:12:38.570
Dann nicht ausdrücken. Mhm. Das ist halt irgendwie ein bisschen ungünstig und schade.

00:12:38.981 --> 00:12:40.439
Hätte man vernünftiger konzipieren können.

00:12:42.348 --> 00:12:46.070
Ja. Aber hey, noch mal ganz kurz, der schwenkt zurück zum Dialog-Element.

00:12:46.130 --> 00:12:49.790
Wo du grad schon bei der Kritik an HTML-Elementen und Attributen bist,

00:12:49.850 --> 00:12:51.620
bei Dialog wär ja noch kritisch anzumerken,

00:12:52.150 --> 00:12:57.453
dass der Modalmodus ja deklarativ gar nicht aktiviert werden kann.

00:12:58.047 --> 00:13:05.177
Also da kann man eine Methode drauf aufrufen, entweder Show für Zeig an oder Show Modal für Zeig halt eben in dem vorhin besprochenen Modalmodus an.

00:13:05.276 --> 00:13:07.059
Aber da gibt es kein Attribut für.

00:13:08.301 --> 00:13:13.801
Kannst du denn Dialog überhaupt öffnen ohne JavaScript? Es hat ein Open Attribut.

00:13:14.054 --> 00:13:15.494
Das kannst du einfach per HTML setzen.

00:13:16.817 --> 00:13:22.167
Ach so, okay. Ja, okay. Ja, klar. Das ist hier quasi unser nächster Punkt.

00:13:22.167 --> 00:13:25.667
Es gibt ja diese Popover-API, jetzt auch relativ frisch.

00:13:26.054 --> 00:13:33.167
Bei der haben sie es noch besser gelöst, weil da kannst du quasi sogar sagen,

00:13:33.167 --> 00:13:39.539
eben wenn ich hier klicke, dann bitte mach dieses Popover auf.

00:13:39.845 --> 00:13:45.667
Und das kannst du nur mit HTML und Beziehungen zueinander ausdrücken.

00:13:45.667 --> 00:13:51.667
Also dann eben ähnlich wie, wie du eine Beziehung zwischen Label und Input ausdrücken kannst.

00:13:51.667 --> 00:13:57.667
Genau, das fände ich halt richtig cool, weil das Open Attribut musst du ja dann auch von Anfang an setzen.

00:13:57.667 --> 00:13:59.667
Dann ist halt dieses Dialog-Element offen.

00:13:59.667 --> 00:14:11.290
Aber so einen Weg, das quasi per Knopfdruck dann öffnen zu lassen, nur deklarativ per HTML, das geht ja auch nicht.

00:14:12.487 --> 00:14:18.327
Nö, man kann beides haben. Also ich meine, es ist ja okay, wenn du irgendwie, also schau dir ja irgendwie die Classlist an.

00:14:18.402 --> 00:14:23.443
Also hast du ein Attribut, kannst du es damit setzen oder du kannst es halt eben auch über die Classlist JavaScript API toggle.

00:14:23.578 --> 00:14:30.456
Und bei so Sachen, wo es letztlich einfach ein Zustands-Switch ist zwischen ist jetzt da oder ist nicht da oder ist jetzt in diesem Modus oder in jenem Modus,

00:14:30.555 --> 00:14:38.540
wenn du mich fragst, die all diese Varianten geben, weil es halt eben all diese Use Cases gibt von halt irgendwie,

00:14:38.828 --> 00:14:45.627
Ich mach das mit so einem jQuery-artigen Ansatz auf, oder ich mach halt irgendwie React, da ist alles deklarativ,

00:14:45.627 --> 00:14:48.334
oder ich render das vom Server schon so raus, oder, oder.

00:14:48.627 --> 00:14:55.127
Naja, das stimmt, aber du kannst halt nicht ... Also, wenn du jetzt sagst, ich möchte nur deklarativ irgendwie ausdrücken,

00:14:55.127 --> 00:14:58.867
dass, wenn man auf diesen Knopf drückt, dass dann ein Dialog aufgeht.

00:14:59.497 --> 00:15:06.573
Ja. Also, wenn du das ... Das kannst du ja nicht. Also, entweder er muss von Anfang an per Open Attribut eben offen sein,

00:15:07.347 --> 00:15:10.627
Und wenn er das nicht ist?

00:15:10.165 --> 00:15:15.836
Dann kannst du ihn auch nicht nur mit Dingen, die du ins HTML schreibst, öffnen lassen.

00:15:16.520 --> 00:15:17.979
Nee, da brauchen wir das HTML-X für.

00:15:19.779 --> 00:15:26.045
Genau, und das geht halt mit der Popover, oder mit dem Popover-API heißt es.

00:15:26.855 --> 00:15:30.267
Aber letztlich sind das HTML-Attribute neue.

00:15:30.843 --> 00:15:31.167
Ja.

00:15:32.310 --> 00:15:36.055
Und das finde ich eigentlich ganz gut. Ja, es ist, also ich meine,

00:15:36.424 --> 00:15:40.898
es sind die HTML-Attribute, Und es ist halt tatsächlich auch eine Extension,

00:15:40.989 --> 00:15:45.004
was so die JavaScript-Sachen angeht. Also, das ist im Prinzip, wie ich das Dialog-Element ganz gern hätte.

00:15:46.453 --> 00:15:50.657
Also, man kann sagen, Hide-Popover, Show-Popover, Toggle-Popover und so weiter.

00:15:51.008 --> 00:15:54.815
Und halt eben, dass man das Target setzt, ist halt eben per Attribut, das macht ja auch irgendwie Sinn.

00:15:54.815 --> 00:15:56.571
Ist ja irgendwie ein Key gleich irgendein Value.

00:15:56.724 --> 00:16:03.737
Und da ist ja Attribut auf dem Element tatsächlich ja das einigermaßen idiomatische Mittel, um sowas auszudrücken.

00:16:03.809 --> 00:16:07.495
Also, ich finde, das passt schon. Das ist halt ein bisschen besser und vollständiger von der API her

00:16:07.495 --> 00:16:08.508
als das Dialog-Element.

00:16:09.985 --> 00:16:12.379
Ja, genau, find ich auch. Aber das kann man ja noch nachrüsten.

00:16:13.136 --> 00:16:16.995
Was ist der Unterschied zwischen Dialog und Popover?

00:16:17.035 --> 00:16:19.995
Also, in beiden Fällen wird ein ...

00:16:21.495 --> 00:16:26.684
Ja, im Prinzip ein Overlay geöffnet. Ich glaub, das Popover-Overlay-Dingsbums

00:16:27.035 --> 00:16:28.845
ist auch in dieser Toplayer.

00:16:29.268 --> 00:16:35.995
Ich weiß nicht, ob ich an das eben gedacht habe. Genau, aber das Dialog-Element ist tatsächlich eher so,

00:16:35.995 --> 00:16:40.575
sagen wir mal, ohne Bezug zu einem spezifischen Element.

00:16:41.628 --> 00:16:46.147
Und bei dem Popover, das verankert sich ja ...

00:16:47.362 --> 00:16:52.195
An einem anderen Element. Genau, Popover würde ich beschreiben

00:16:52.195 --> 00:16:57.795
als ein etwas von den Funktionalitäten her eingeschränkteres Dialog

00:16:58.084 --> 00:17:00.839
mit einem bestimmten Target-Element, auf dem das drauf ist.

00:17:02.828 --> 00:17:06.995
Also du hast jetzt, glaube ich, ein Popover, der Popover kann jetzt nicht dein Form-Target sein,

00:17:07.230 --> 00:17:09.985
wie das ja beim Dialog-Element der Fall ist. Ja.

00:17:10.995 --> 00:17:22.669
Genau, und das Popover, die Popover-API bringt im Schlepptau auch mit dieses Anchored-Positioning in CSS,

00:17:22.995 --> 00:17:26.819
dass man eben auch ohne Popover nutzen kann, um,

00:17:27.629 --> 00:17:30.995
also ähnlich wie man bei Position Absolut Dinge positionieren kann,

00:17:30.995 --> 00:17:34.995
oder Position Fix kann man eben auch hier Anchored Positioning verwenden,

00:17:34.995 --> 00:17:38.387
um ein Element am anderen zu verankern.

00:17:39.017 --> 00:17:46.768
Also ich meine, das geht mit Position Absolut ja im Grunde auch einigermaßen. Der Unterschied ist aber,

00:17:46.995 --> 00:17:50.995
dass bei diesem Anchored Positioning der Browser auch schaut,

00:17:51.791 --> 00:17:53.995
wo ist denn gerade mein Viewport zu Ende?

00:17:54.582 --> 00:17:58.995
Und wenn das eben rausragen würde, dann würde er es eben auf die andere Seite packen,

00:17:58.995 --> 00:18:02.144
wo es nicht rausragt. Genau.

00:18:04.287 --> 00:18:07.032
Was man sich halt sonst echt mühsam, mühsam erarbeiten müsste.

00:18:07.177 --> 00:18:11.597
Also, geht halt schon mit Absolute Positioning, aber halt mit erheblichem Mehraufwand,

00:18:12.164 --> 00:18:14.081
über die absolute Positionierung hinaus.

00:18:14.504 --> 00:18:17.169
Genau, und so der Klassiker ist ja eigentlich hier Popper.js.

00:18:17.502 --> 00:18:19.266
Das benutzt man für so was.

00:18:19.699 --> 00:18:21.137
Und das ist auch so ...

00:18:22.363 --> 00:18:28.637
Ich bin ja ein großer Fan von Hand-Rolled-Sachen, aber so das ist einfach ...

00:18:29.437 --> 00:18:34.697
So nervig und eklig. Das macht, da nehme ich dann auch Popper.js dafür.

00:18:35.110 --> 00:18:39.497
Naja, und warum würdest du es nicht machen? Weil ich meine, der Use Case ist so klar abgegrenzt.

00:18:39.936 --> 00:18:43.737
Wenn jetzt irgendwie Popper.js irgendwie vor die Hunde geht,

00:18:43.737 --> 00:18:48.137
auf welche Weise auch immer, da findest du entweder sofort einen guten Ersatz

00:18:48.137 --> 00:18:50.261
oder einen sehr guten Ersatz wird sich relativ bald ergeben.

00:18:50.801 --> 00:18:53.817
Das ist ja auch nicht deine ganze Applikation da drin irgendwie eingebaut,

00:18:53.817 --> 00:18:56.617
wie irgendwie, wenn du jetzt eine Angular App schreibst und Angular geht vor die Hunde,

00:18:56.617 --> 00:19:00.177
dann hast du ein ernsthaftes Problem, das so ohne weiteres nicht reparabel ist,

00:19:00.177 --> 00:19:02.864
aber da tauschst du halt die Libraries aus und verbringst irgendwie drei Zeilen Code,

00:19:03.937 --> 00:19:07.937
damit das irgendwie noch anzupassen und zu justieren, dann läuft die Kiste, würde ich auch sagen.

00:19:07.937 --> 00:19:09.445
Das ist ein völlig okayer Use Case.

00:19:10.849 --> 00:19:18.222
Genau, oder eben in Zukunft, wenn denn die ganzen Browser sich einigen, die Popover-API,

00:19:18.753 --> 00:19:25.337
zu implementieren, oder zumindest das Anchored Positioning, dann, naja, die Popover-API

00:19:25.337 --> 00:19:27.243
wäre schon schöner in ihrer Gesamtheit.

00:19:27.337 --> 00:19:34.977
Dann bräuchte man eben Popper.js nicht Und, ähm, genau, das wär jetzt zum Beispiel ein schöner Outcome

00:19:34.977 --> 00:19:40.477
des State-of-HTML, wenn das jetzt da drin landet und die Leute sagen, ich hab da total Bock drauf

00:19:40.477 --> 00:19:43.977
auf die Popover-API, dann würden vielleicht die Browsersteller sagen,

00:19:43.977 --> 00:19:55.024
okay, dann lass uns das in unsere Interop 2024 oder so mit reinnehmen und dann ist es nächstes Jahr hoffentlich in allen Browsern.

00:19:55.618 --> 00:19:59.177
Das sieht ja schon mal so schlecht gar nicht aus. Also, die Chrome-Crew hat das schon.

00:19:59.624 --> 00:20:03.977
Bei Firefox ist es drin, aber hinter einem Flag und bei Safari ist es in Pre-Releases schon drin.

00:20:06.447 --> 00:20:10.137
Also, ich will jetzt nicht sagen, dass man nicht dafür stimmen sollte beim Survey,

00:20:10.381 --> 00:20:14.306
aber es wird wahrscheinlich auch so relativ bald weit verbreitet sein.

00:20:17.538 --> 00:20:24.937
Ja, genau. Und die Popover-API, die kommt aus einer recht interessanten Community.

00:20:24.937 --> 00:20:32.617
Es gibt ja diese Open UI Community Group, die sich hingesetzt hat und gesagt hat,

00:20:32.617 --> 00:20:41.907
Was sind denn eigentlich die immer wiederkehrenden, aber harten Herausforderungen beim Gestalten von UI?

00:20:42.970 --> 00:20:45.733
Der Klassiker ist, ich möchte einen Select stylen.

00:20:46.940 --> 00:20:53.617
Aber das sind eben noch ein paar andere Dinge. Und Popovers bauen ist eins davon.

00:20:53.617 --> 00:20:58.617
Und ich glaube, auch im Verlauf dieser Aufnahme werden wir immer wieder auf Dinge kommen,

00:20:58.617 --> 00:21:02.865
die eben aus dieser Open-UI-Gruppe gekommen ist.

00:21:03.801 --> 00:21:11.651
Ja, wollen wir da mal zu dem Select-Problem kommen mit dem Select, ehemals Select-Menü, jetzt Select-List?

00:21:12.398 --> 00:21:19.843
Also, genau, Select-Menü ist, glaube ich, gerade vorgestern oder vorgestern wurde das irgendwie

00:21:19.957 --> 00:21:23.957
per Beschluss auf Select-List geändert.

00:21:23.957 --> 00:21:27.957
Ich weiß, ich hab's nur mitbekommen, ich weiß nicht, warum das so ist.

00:21:28.467 --> 00:21:32.357
Weil mit Menü einfach noch was anderes gemeint ist.

00:21:32.905 --> 00:21:35.957
Es gab ja, glaub ich, auch dieses, äh, gab's nicht auch mal Menü?

00:21:36.983 --> 00:21:40.440
Ähm ... Als Element, aber nur in Firefox unterstützt oder so.

00:21:40.728 --> 00:21:42.457
Irgendwie so was Obskures gab's da mal, ja.

00:21:44.158 --> 00:21:50.957
Genau. Ja, ich glaub, Select Menü oder Select List, da sind die meisten wahrscheinlich schon drüber gestolpert,

00:21:50.957 --> 00:22:00.457
ist letztlich eine neue Konzeption von Dropdowns, die eben zum Ziel haben, dass sie gestaltbar sind, aber dass man eben

00:22:00.457 --> 00:22:05.457
auch so Dinge bauen kann, wie vielleicht searchable

00:22:05.565 --> 00:22:14.343
Selects und also so die ganzen Use Cases abbilden kann, für die man bisher irgendwelche Libraries benutzt hat.

00:22:14.631 --> 00:22:18.457
Also eine, die mir einfällt, die man früher viel benutzt hat, ist Select 2,

00:22:19.681 --> 00:22:21.625
die noch jQuery gestützt war.

00:22:22.625 --> 00:22:45.256
Also du kannst im Prinzip auch dann in dieses Dropdown kannst du beliebiges HTML stecken, ob das immer Sinn macht, ob man es tun sollte, ist die Frage, aber es geht und es wird eben auch darauf geachtet, dass Accessibility Dinge weiterhin funktionieren und eben in dieses Teil eingebacken sind.

00:22:46.283 --> 00:22:50.457
Ja, eine richtige Spezifikation dafür sehe ich jetzt noch nicht.

00:22:51.945 --> 00:22:58.058
Also dieses, was wir da von OpenUI jetzt haben, ist ja wirklich mehr so eine Art High-Level-Explainer.

00:22:58.148 --> 00:23:01.433
Das taugt, glaube ich, hinterher wirklich sehr gut für Copy-Paste nach MDN.

00:23:01.712 --> 00:23:08.175
Mit so Beispielen und Zeug. Aber ich bin da ja mal wirklich sehr gespannt, wie das am Ende tatsächlich hinhaut,

00:23:08.175 --> 00:23:14.595
weil das ist, glaube ich, schon eine relativ extrem knifflige Angelegenheit, das zu machen.

00:23:15.522 --> 00:23:20.104
Weil du hast halt so Sachen wie interaktive Elemente in interaktiven Elementen drin.

00:23:20.428 --> 00:23:23.975
Also dein Select, was searchable ist, oder dein Dropdown-Item,

00:23:24.137 --> 00:23:26.469
wo dann halt irgendwie noch Unterseitelemente anzuklicken sind.

00:23:26.757 --> 00:23:30.815
Das ist ja inherent schon mal ziemlich hakelig, das muss irgendwie gestaltbar sein,

00:23:30.815 --> 00:23:34.490
aber da sollen die Leute sich auch nicht irgendwie in Schwierigkeiten bauen können.

00:23:35.390 --> 00:23:38.375
Und das Problem ist halt eben, das hatten wir mal vor ewig langen Zeiten

00:23:38.375 --> 00:23:40.836
bei so Diskussionen über sortierbare Tabellen, glaube ich,

00:23:41.412 --> 00:23:46.049
wo ich halt so ein bisschen skeptisch bin, ob das so wirklich ohne weiteres möglich sein wird,

00:23:46.544 --> 00:23:52.755
eine Lösung zu finden in HTML, die tatsächlich alle Use Cases von allen Nutzern von HTML

00:23:53.187 --> 00:23:58.697
irgendwie abdeckt, oder wirklich so diese 80%-Schwelle, die vielleicht so ein Dialog oder so ein Popover erreicht,

00:23:59.039 --> 00:23:59.921
da wirklich abdeckt.

00:24:00.875 --> 00:24:02.815
Und ich bin mir nicht sicher, ob man das wirklich so gut hinkriegt,

00:24:02.815 --> 00:24:07.051
dass man das am Ende im Standard hat, und 80% von allen nutzen das,

00:24:07.825 --> 00:24:11.084
versus wir haben irgendwie so eine Katastrophe wie irgendwie ein Input-Type Date,

00:24:11.372 --> 00:24:15.900
was irgendwie ja auf dem Papier sehr gut aussieht, aber in der Realität halt so viele

00:24:16.251 --> 00:24:21.635
Spezialitäten und Sonderanpassungen jeweils immer braucht, dass es vielleicht besser gewesen wäre,

00:24:21.695 --> 00:24:26.244
das einfach sein zu lassen und zu sagen, das ist out of scope, nehmt halt weiter eure Diffs,

00:24:27.414 --> 00:24:27.855
das geht ja bisher auch.

00:24:27.915 --> 00:24:31.015
Naja, vielleicht muss man die Frage stellen ...

00:24:32.365 --> 00:24:38.015
Also, vielleicht muss man weniger die Frage stellen, ob das, was man damit baut, dann ...

00:24:39.027 --> 00:24:42.195
Perfekt ist. Sondern einfach nur, ist es ...

00:24:43.474 --> 00:24:51.594
Es ist ein fortschritt gegenüber dem wie es halt heutzutage oft gelöst wird und da glaube ich dass es schon der fall ist.

00:24:52.287 --> 00:24:57.415
Moment, würde ich nicht sagen, dass das stimmt, weil nur Fortschritt reicht nicht, weil du wirst es ja nie wieder los.

00:24:59.885 --> 00:25:02.699
Also, das muss halt tatsächlich, wenn du jetzt ein neues Element einführst,

00:25:02.892 --> 00:25:06.007
ja schon irgendwie sitzen, weil sonst, wie gesagt, Input-Type Date.

00:25:07.924 --> 00:25:15.225
Mhm. Also, wo halt eben irgendwie alle, die sozusagen das Versprechen von diesem Widget brauchen könnten,

00:25:16.071 --> 00:25:18.286
alle, die sozusagen die eigentliche Zielgruppe sind,

00:25:18.781 --> 00:25:23.199
dann doch so spezielle Anforderungen haben, dass sie sagen, da kriegen wir eh nicht so hin, wie wir es haben wollen,

00:25:23.199 --> 00:25:26.699
dazu ist die ganze API zu eingeschränkt, weil halt eben so Dinge wie halt irgendwie

00:25:26.699 --> 00:25:30.319
das Management von verschachtelten interaktiven Elementen und so weiter,

00:25:30.664 --> 00:25:35.453
der Gestalt halt dann einschränkend ist, um sozusagen den generellen Case irgendwie abzudecken,

00:25:35.559 --> 00:25:41.116
dass um unseren speziellen Case umzusetzen, wir eh wieder bei den Diffs oder bei irgendwie Select-To und ähnlichen Dingen landen.

00:25:42.313 --> 00:25:46.607
Also du meinst, dass es dann nicht so gut ist und dass die Leute es dann auch nicht verwenden?

00:25:48.228 --> 00:25:53.379
Schwierig, ne? Ich würde halt wirklich sagen, Datepicker klingt jetzt für mich einfacher umzusetzen,

00:25:53.566 --> 00:25:57.086
als jetzt dieses Select-List-Element mit seinen ganzen Komplikationen.

00:25:58.157 --> 00:26:03.699
Und da hat es schon nicht geklappt. Und ich glaube, bei HTML tendiere ich echt so ein bisschen so zum Minimalisten,

00:26:03.699 --> 00:26:07.195
weil das ist halt wirklich so der Layer, an dem kommt halt wirklich keiner vorbei.

00:26:07.663 --> 00:26:12.899
Egal, wie viel React man baut, am Ende ist es HTML. Da kommt man nicht dran vorbei, und das muss halt wirklich irgendwie,

00:26:13.497 --> 00:26:15.659
wenn man da was einbaut und man es nicht wieder loswerden kann,

00:26:15.659 --> 00:26:19.019
der Gestalt sein, dass es wirklich unmittelbar nützlich ist.

00:26:19.019 --> 00:26:21.356
Und das kann ja gerne irgendwelche Trade-offs haben und Nachteile.

00:26:21.446 --> 00:26:25.379
Inert-Attribut ist irgendwie jetzt nicht für jeden Use-Case das Richtige,

00:26:25.704 --> 00:26:29.379
aber ich glaube, so alles in allem ist es schon auf eine Art und Weise so nützlich,

00:26:29.379 --> 00:26:30.601
dass viele das verwenden werden.

00:26:31.546 --> 00:26:34.379
Und bei Selectlist, wie gesagt, sehe ich halt so ein bisschen das Problem einer

00:26:34.733 --> 00:26:37.803
überschaubaren Zielgruppe mit sehr speziellen Anfertigungen,

00:26:38.379 --> 00:26:44.379
die vielleicht dann doch eher besser damit bedient sind, die Dinge von Hand nachzubauen oder irgendeine Library zu verwenden.

00:26:44.379 --> 00:26:47.179
Nicht für jeden Use Case muss es ein HTML Element geben, würde ich damit sagen.

00:26:49.137 --> 00:26:55.249
Ja, nee, also, würd's auch nicht geben. Ich glaub, damals hattest du ja auch als Beispiel, ähm,

00:26:56.141 --> 00:26:58.507
glaub ich, Tabs und ...

00:26:58.567 --> 00:27:04.727
Tabs waren ganz genau, darüber haben wir geredet. Genau, und da ging's aber ja auch vor allem darum, wie ...

00:27:05.035 --> 00:27:10.751
Also, dass, wenn's solche Elemente gibt, müssen auch so ...

00:27:11.129 --> 00:27:15.450
Also, müssen auch Smartphones eine Idee haben, wie sie so was abbilden können.

00:27:15.847 --> 00:27:20.312
Und vielleicht ist das bei den Tabs ... Smartphones, alle Geräte, die jemals kommen werden.

00:27:21.005 --> 00:27:24.947
Ja, genau. Aber Smartphones sind ja schon so ein erster konkreter Fall,

00:27:24.947 --> 00:27:28.630
wo man kennt das ja, wenn man so Tab-Container baut.

00:27:29.179 --> 00:27:35.947
Und wie funktioniert das denn da, wenn irgendwie die Tabs mehr sind als Platz ist? Bricht das dann um?

00:27:35.947 --> 00:27:39.947
Oder stellt ein Smartphone das vielleicht irgendwie direkt anders dar?

00:27:39.947 --> 00:27:44.231
So ähnlich wie native Selects ja dann auch irgendwie anders funktionieren? Genau.

00:27:45.896 --> 00:27:49.587
Naja, und vor allen Dingen, du hast halt letztlich so unterschiedliche Dinge, die dich in dieses

00:27:49.587 --> 00:27:54.147
Problem reinführen können. Also, du hast auf dem Smartphone in der Horizontalen zu wenig Platz,

00:27:54.147 --> 00:27:59.107
was machst du? Naja, das dürfte halt darauf ankommen, auch wodurch der wenige Platz zustande

00:27:59.107 --> 00:28:03.947
kommt. Also hast du jetzt viele Tabs oder hast du zwei Tabs, in denen extrem viel drinsteht?

00:28:05.593 --> 00:28:09.787
Weißt du, dass es irgendwie höchstens drei Tabs werden können aufgrund deines Use Cases oder musst

00:28:09.787 --> 00:28:14.307
du damit rechnen, dass es 300 werden? Daran entscheidet sich halt eben, ob du dann umbrichst

00:28:14.307 --> 00:28:17.607
oder die Dinge auf so ein Icon minimierst, wie bei einem angepinnten Tab im Browser,

00:28:17.755 --> 00:28:20.607
wo du auch du daraus dann irgendwelche um 90 Grad gedrehten Tabs machst,

00:28:20.607 --> 00:28:22.364
die du an die linke Seite klatscht oder oder oder.

00:28:22.922 --> 00:28:25.542
Und das können alles je nach Use Case vernünftige Lösungen sein,

00:28:25.974 --> 00:28:31.168
aber weil das alles vernünftige Lösungen sein können, müsste ja ein theoretisches HTML-Element, das das alles berücksichtigen muss,

00:28:31.574 --> 00:28:32.699
das alles implementieren.

00:28:33.563 --> 00:28:35.652
Und dann fängt's halt, glaube ich, an, richtig hakelig zu werden.

00:28:36.381 --> 00:28:41.307
Weil du hast ja letztlich auch irgendwelche Schriften, die du von links nach rechts, von rechts nach links oder von oben nach unten liest.

00:28:41.307 --> 00:28:47.107
Und wie machst du das dann mit den Tabs? dann musst du halt so ähnlich wie bei Flexbox und Grid-Layout eine eigene Sprache entwickeln für

00:28:47.310 --> 00:28:48.525
da läuft's lang, da läuft's lang.

00:28:49.488 --> 00:28:53.807
Ich meine, du könntest die natürlich auch adaptieren, aber dann musst du irgendwie HTML und CSS im Gleichschritt da entwickeln lassen.

00:28:54.511 --> 00:28:56.807
Und je mehr ich drüber nachdenke, umso weniger gefällt mir das.

00:28:56.987 --> 00:29:01.407
Und deswegen denke ich, Leute, nehmt's JavaScript, nehmt's HTML, nehmt's CSS, dafür ist es da.

00:29:01.407 --> 00:29:03.207
Wenn ihr was Spezielles haben wollt, dann macht das.

00:29:03.316 --> 00:29:05.707
Wenn ihr was weniger Spezielles haben wollt, nehmt dann eine Library.

00:29:05.707 --> 00:29:08.843
Und ansonsten braucht ihr vielleicht auch einfach gar keine Tabs, sondern einfach nur eine Liste von Zeug.

00:29:10.526 --> 00:29:16.776
Ja, da sagst du wahres. Wenn wir jetzt eh schon in dieser Open-UI-Gruppe sind,

00:29:16.836 --> 00:29:20.976
dann lass uns doch noch schnell Breadcrumb erwähnen.

00:29:21.036 --> 00:29:23.265
Oh ja! Ganz wichtig.

00:29:23.823 --> 00:29:31.476
Genau, das kommt auch von denen. Ich glaube, da der Antrieb ist, dass sie das auf den Tisch gebracht haben,

00:29:31.536 --> 00:29:36.476
ist letztlich eigentlich nur, dass die, wenn man die per Hand zusammenbaut,

00:29:36.536 --> 00:29:38.659
die Leute das nicht korrekt auszeichnen.

00:29:39.955 --> 00:29:48.176
Mit entsprechenden Accessibility-Attributen, also mit keinem angemessenen Role,

00:29:48.176 --> 00:29:56.276
keinem Area-Current draufsetzen auf das aktuell aktive Element.

00:29:56.276 --> 00:30:02.884
Ich glaube, dass das wahrscheinlich daherrührt, oder? Und dass man das einfach kapselt in einem Red-Crump-Element.

00:30:04.477 --> 00:30:09.131
Nee, also, ja, das mag die Intention sein, Aber warum nehmen die Leute nicht das nav-Element?

00:30:11.220 --> 00:30:16.918
Also, das ist ja das, was im Grunde dann hier im Vorschlag, glaub ich, unten drunter schlummert.

00:30:18.197 --> 00:30:23.958
Weiß ich nicht. Also, ich nehm das nav-Element und setz dann noch ein ARIA-Label drauf. Ja.

00:30:24.948 --> 00:30:33.536
Bei dem, ähm, aktuellen Element, da nehm ich dann in der Regel, verlink ich das nicht mehr in der Breadcrumb,

00:30:33.536 --> 00:30:37.254
sondern setzt eben nur ein aria-current-page drauf.

00:30:38.296 --> 00:30:44.159
Genau. Und damit machst du ja sozusagen wirklich alles, was für eine vernünftige Breadcrumb-Navigation getan werden muss.

00:30:46.302 --> 00:30:51.151
Möglicherweise ist die sogar einigermaßen benutzbar, wenn das ARIA-Current da nicht drauf ist,

00:30:51.352 --> 00:30:56.195
weil es ist halt die Breadcrumb-Navigation, das ist ja ein Pattern, das erkennt man dann ja wieder,

00:30:56.969 --> 00:30:57.239
und weiß das zu benutzen.

00:30:57.879 --> 00:31:02.491
Deswegen scheint mir das mehr so eine Art zu sein, die Leute benutzen das Nuff-Element nicht,

00:31:02.551 --> 00:31:07.891
also geben wir ihnen das Nuff-Element mit einem anderen Namen und hoffen, dass es diesmal funktioniert.

00:31:07.951 --> 00:31:11.391
Irgendwo hat auch der Einstein mal was über Wahnsinn gesagt, oder?

00:31:11.451 --> 00:31:16.396
Wenn man immer wieder das Gleiche probiert Ist das vielleicht nicht so clever?

00:31:17.881 --> 00:31:22.851
Vielleicht, ja. Also, ich zweifle da echt hart dran. Vor allen Dingen, Breadcrumb-Navigation

00:31:22.891 --> 00:31:28.639
ist ja auch so ein arg spezifisches Navigationspattern, das ja auch nur in einer Welt der breiten Bildschirme Sinn ergibt,

00:31:29.311 --> 00:31:32.391
und wo ich halt immer sofort an Web 2.0-Farbverläufe denke.

00:31:32.431 --> 00:31:35.151
Ich hab so ein Ding schon länger nicht mehr benutzt.

00:31:35.191 --> 00:31:38.731
Das scheint mir also wirklich so eine Art Media-Type-TV zu sein.

00:31:39.127 --> 00:31:45.051
Was echt ... Ja, wie meinst du, das ist der Grund, warum die eingebaut werden, zumindest aus meiner Erfahrung,

00:31:45.111 --> 00:31:47.004
dass Zeo das gerne hätte.

00:31:48.768 --> 00:31:54.211
Aha. Ähm, genau. Also, das war bisher eigentlich immer der Grund,

00:31:54.271 --> 00:31:56.330
warum ich Breadcrumbs eingebaut habe.

00:31:58.351 --> 00:32:02.151
Ich find halt, bei irgendwie komplizierten, tief verschachtelten Sachen

00:32:02.211 --> 00:32:05.191
ist das ja zur Navigation sicherlich auch nicht schlecht.

00:32:05.251 --> 00:32:10.851
Du liest irgendwie so die ECMA-Skript-Spezifikationen und du hast dann diesen Table of Contents an der Seite

00:32:10.851 --> 00:32:13.443
weil das Label of Contents halt dann 70 Unterpunkte hat,

00:32:14.047 --> 00:32:19.851
ist das nicht unbedingt zur Orientierung hilfreich, weil du halt irgendwie beim genug Scrollen nur 10 Punkte nach oben,

00:32:19.851 --> 00:32:20.816
10 Punkte nach unten siehst.

00:32:20.870 --> 00:32:25.851
Aber wenn du jetzt irgendwie sowas hättest wie, ich bin hier, Unterkapitel hier, Unterkapitel da, Unterkapitel dort,

00:32:25.851 --> 00:32:27.703
das würde ja auch außerhalb von SEO noch Sinn machen.

00:32:27.851 --> 00:32:30.851
Das gebe ich ja. Aber das sind halt super spezielle Use Cases,

00:32:30.851 --> 00:32:32.851
die lassen sich halt mit Bordmitteln auch super umsetzen.

00:32:33.411 --> 00:32:36.851
Und SEO ist ja auch so eine schöne Sache. Es herrscht nicht Konsens darüber,

00:32:36.851 --> 00:32:42.851
dass diese ganze Submaschinen-Geschichte eh für den Arsch ist alles demnächst von von AI erledigt wird, dann muss man da ja auch eh nichts für optimieren.

00:32:45.015 --> 00:32:59.994
Vielleicht genau aber noch noch herrscht dieser konsens nicht und ich meine das auch nur ich meine das tatsächlich nur halbtrollig also es reicht ja schon seo will das heißt ja im prinzip irgendwer der was zu sagen hat will das. Im wesentlichen.

00:33:01.687 --> 00:33:09.355
Joa, vielleicht, ja. Und das ist ja auch tatsächlich keine Naturkonstante.

00:33:09.960 --> 00:33:14.335
Dass es irgendjemanden gibt, der was zu sagen hat, der genau das will.

00:33:15.280 --> 00:33:19.095
Also, das in ein HTML-Element zu gießen, halte ich halt wirklich für ziemlich knifflig.

00:33:19.155 --> 00:33:23.148
Nimmst NUV-Element, packt noch ein ARIA-Current drauf, so wie der Chef das gesagt hat, und dann ist super.

00:33:24.755 --> 00:33:29.875
Gegen das Ding würde ich tatsächlich aktiv gegenvotieren, weil das sorgt halt nur für Verwirrung.

00:33:29.875 --> 00:33:34.115
Diese ganze Diskussion. Ja, was zählt denn als Navigation? Ja, guck in die Spezifikationen,

00:33:34.115 --> 00:33:38.395
Major Blocks of Navigation. Ist das jetzt noch eine Breadcrumb-Navigation oder ist es eine andere?

00:33:38.395 --> 00:33:41.675
Weil ich benutze halt irgendwie nicht da so diese Feilchenstruktur, da man liest es halt in die

00:33:41.675 --> 00:33:44.691
in die andere Richtung, bla Keks, das macht es ja alles wirklich nicht besser.

00:33:46.203 --> 00:33:47.013
Ja. Ich bin spartvoll.

00:33:48.408 --> 00:33:53.981
Ich tendiere übrigens dazu, in Navs gar keine Listen mehr einzubauen.

00:33:56.132 --> 00:34:00.120
Ich mach das, wenn ich so ein strukturierendes Element noch brauche. Also halt ...

00:34:00.904 --> 00:34:05.099
Kannst halt links reinpacken und irgendwie mit Grid und Flexbox kannst du die ja bequem stylen.

00:34:05.699 --> 00:34:12.119
Okay, wenn du quasi so einen Steigbügel brauchst, so eine Rollbarleiter für deinen Anfasser, für deinen CSS,

00:34:12.372 --> 00:34:15.775
dann entscheidest du dich für eine Liste und ansonsten nicht.

00:34:16.675 --> 00:34:21.059
Genau, weil sonst müsste ich ja ein DIV nehmen. Und dann ist da halt schon irgendwie ein bisschen nicer,

00:34:21.059 --> 00:34:23.940
auch so unter dem Szenario, irgendwie CSS ist kaputt oder sowas alles, ne?

00:34:24.259 --> 00:34:27.757
Ja. Aber brauchst du halt heutzutage nicht mehr, weil schön ist neues CSS.

00:34:28.289 --> 00:34:29.990
Mhm. Ja.

00:34:32.259 --> 00:34:38.059
So, dann könnten wir jetzt, wenn du magst, mal kurz auf Lazy Loading zu sprechen kommen. Sehr gerne.

00:34:38.389 --> 00:34:41.059
Das ist ja an sich auch nichts Neues mehr.

00:34:41.657 --> 00:34:51.859
Also, äh, man kann per Loading gleich Lazy auf Bildern und iFrames und sonst aber nix, ähm, sagen,

00:34:51.859 --> 00:34:58.359
dass etwas eben erst geladen werden soll, wenn es nah genug am Viewport dran ist.

00:34:58.671 --> 00:35:00.859
Mhm. Ähm, ist ganz cool.

00:35:01.516 --> 00:35:06.359
Hab ich immer mal wieder Probleme mit iOS übrigens tatsächlich, dass der abschmiert.

00:35:07.430 --> 00:35:12.599
Er stürzt ab. Er stürzt einfach ab. Das ist ja bei iOS so, wenn die einen Fehler haben,

00:35:12.659 --> 00:35:14.137
dann stürzen die einfach hart ab.

00:35:15.859 --> 00:35:24.059
Sodass ich im aktuellen Projekt tatsächlich immer noch alles in No-Scripts kapsle

00:35:24.099 --> 00:35:26.099
und dann per Intersection Observer

00:35:26.159 --> 00:35:31.599
die Bilder dann aus dem No-Script herausziehe, wenn sie nah genug dran sind.

00:35:31.818 --> 00:35:32.859
Also nur wegen iOS.

00:35:34.626 --> 00:35:38.359
Genau, aber vielleicht ist es auch, das ist halt so eine E-Commerce-Seite,

00:35:38.359 --> 00:35:42.919
ganz viel Bilder auf so einer Übersichtsseite zu sehen sind.

00:35:42.919 --> 00:35:45.639
Und vielleicht ist es dann auch erst ab einer gewissen Menge Bilder,

00:35:45.639 --> 00:35:47.094
dass iOS dann abkackt.

00:35:48.639 --> 00:35:54.999
Okay, das ist eine Erklärung, aber keine Entschuldigung, weil du solltest einem Webbrowser Webseiten vorsetzen sollen und dann

00:35:54.999 --> 00:35:57.150
soll der das irgendwie verarbeiten, wenn er die Bilder nicht anzeigen kann.

00:35:57.759 --> 00:36:00.519
Dann zeigt er die Bilder nicht an, aber abstürzen ist ziemlich inakzeptabel.

00:36:02.020 --> 00:36:05.319
Ja, also es liegt definitiv daran, weil wenn man es eben wegnimmt, stürzt er nicht ab.

00:36:05.319 --> 00:36:09.042
Und es gibt ja auch diese Log-Files, die er noch irgendwie schreibt,

00:36:09.319 --> 00:36:13.319
diese Debug-Logs, die man sich rausholen kann. Und da sieht man dann auch,

00:36:13.319 --> 00:36:17.319
dass er eben mit dem Laden von Bildern beschäftigt war.

00:36:17.954 --> 00:36:18.791
Genau, aber ...

00:36:20.087 --> 00:36:28.738
Das ist jetzt sozusagen als kleine Anekdote am Rand. Was jetzt neu hinzukommt,

00:36:28.847 --> 00:36:37.192
wo ich Lazy Loading sozusagen nur als Aufhänger sehe, ist, ähm, äh, beim...

00:36:38.074 --> 00:36:44.238
Du kannst ja, bei den responsiven Bildern kannst du ja mit Source-Set und Sizes arbeiten, ne? Das ist sozusagen der...

00:36:44.238 --> 00:36:48.238
Beim Picture-Element. Nee, beim Image-Element kannst du das ja auch.

00:36:48.238 --> 00:36:50.238
Du brauchst dafür kein Picture-Element.

00:36:50.238 --> 00:36:54.238
Das ist sozusagen der einfachste Ansatz. Und Picture bräuchtest du dann erst,

00:36:54.238 --> 00:37:00.238
wenn du jetzt zusätzlich noch verschiedene Dateiformate bereitstellen willst.

00:37:00.238 --> 00:37:04.829
Dann geht das nicht ohne. Und da habe ich übrigens gerade erst letztens gelernt,

00:37:05.238 --> 00:37:13.238
dass Microsofts Edge immer noch kein AWIF kann. Obwohl der Chrome das seit Version 85 schon unterstützt.

00:37:13.912 --> 00:37:16.238
Und der Edge ja auf Chromium aufbaut.

00:37:17.342 --> 00:37:20.238
Aber anscheinend hat das irgendwie was mit Patent-Trollen zu tun,

00:37:20.238 --> 00:37:22.689
dass wir es immer noch nicht aktiviert haben.

00:37:23.914 --> 00:37:27.238
Okay, möchte ich jetzt gerne mal den Patent-Troll kennenlernen,

00:37:27.238 --> 00:37:34.032
vor dem Microsoft Angst hat, aber Google nicht. Das hört sich nach einer sehr starken Spezialisierung an.

00:37:34.500 --> 00:37:40.238
Ja, ja, keine Ahnung. Also das ist, gelesen habe ich das bei Alex Russell.

00:37:40.238 --> 00:37:44.238
Der hat das eben irgendwann mal als Grund genannt.

00:37:44.238 --> 00:37:57.718
Genannt. Also hätte ich auch nicht gedacht, muss man wissen. Jedenfalls bei dem Sizes-Attribut

00:37:57.718 --> 00:38:05.718
ist es ja so, da gibst du in so einer Art Media-Query-versehenen Schreibweise ja an,

00:38:05.718 --> 00:38:11.896
an, wie groß wird ein Bild dargestellt im Fenster.

00:38:12.337 --> 00:38:22.663
Und dann kann der Browser darauf basierend sich angucken, ah, okay, hier ist mein Source-Set-Datei-Strauß.

00:38:22.758 --> 00:38:30.958
Und wenn das irgendwie 30 Prozent der Viewport-Breite sind, und ich bin auf dem mobilen Gerät, dann brauche ich jetzt mal ein Bild,

00:38:30.958 --> 00:38:32.958
das ungefähr 100 Pixel Breite hat.

00:38:32.958 --> 00:38:41.178
Und was daran halt doof ist, ist, dass wenn du so eine zentrale Image-Komponente hast,

00:38:41.178 --> 00:38:47.658
die du immer wieder überall einsetzt, dann musst du auf einmal die im HTML konfigurieren

00:38:47.658 --> 00:38:48.658
mit Layout-Informationen.

00:38:48.658 --> 00:38:55.858
Dafür ist ja eigentlich CSS da und im Zweifelsfall ist das vielleicht auch gar nicht so einfach

00:38:55.858 --> 00:39:00.578
für jemanden, der so eine Komponente einbindet, das schon irgendwie zu wissen.

00:39:00.578 --> 00:39:04.378
Das heißt, es geht eigentlich immer nur im Gleichschritt mit dem CSS, was du dazu schreibst.

00:39:05.892 --> 00:39:12.877
Und da gibt's jetzt den Vorschlag, zumindest bei lazy-loadenden Bildern

00:39:12.976 --> 00:39:16.865
ein Sizes gleich Auto möglich zu machen,

00:39:16.991 --> 00:39:24.141
weil lazy-loading ja auch darauf fußt, dass erst das CSS ausgewertet wird.

00:39:24.994 --> 00:39:32.097
Weil erst dann weiß ja der Browser, wo ein Bild im Layout ist und ob das eben nah am Viewport ist oder nicht.

00:39:32.277 --> 00:39:37.958
Und wenn er bei dem Lazy Loading sowieso auf das CSS wartet,

00:39:38.876 --> 00:39:43.641
also was auch wirklich so ist, dann kann er ja auch aus dem CSS heraus ablesen,

00:39:44.061 --> 00:39:48.994
wie breit das Bild ist. Und dann muss das die Person, die eben das HTML zusammenschraubt,

00:39:49.967 --> 00:39:51.875
nicht schon vorab definieren.

00:39:52.334 --> 00:40:02.641
Und ich denke, das ist auf jeden Fall eine sinnvolle Sache. Und genau, nur bei den eben nicht-lazy ladenden Bildern,

00:40:02.641 --> 00:40:04.641
was jetzt im Prinzip die wären,

00:40:04.847 --> 00:40:08.641
die unmittelbar zu Beginn im Viewport sind,

00:40:09.078 --> 00:40:14.525
da müsste man dann eben weiterhin dieses Sizes-Attribut korrekt setzen.

00:40:15.668 --> 00:40:25.141
Und vielleicht noch so ein Nebenaspekt des Ganzen ist, wenn ihr all eure Bilder lazy ladet,

00:40:25.355 --> 00:40:30.126
Und dann schaltet ihr damit eurem Largest Contentful Paint,

00:40:30.756 --> 00:40:40.141
weil eben der Browser das wichtige erste Bild eben nicht rendern kann, bis er denn nicht das CSS

00:40:40.141 --> 00:40:44.141
auch tatsächlich ausgewertet hat.

00:40:44.988 --> 00:40:48.141
Du guckst so nachdenklich?

00:40:47.410 --> 00:40:58.260
Ja, ich bin noch am überlegen. Das heißt, wenn ich jetzt sozusagen das Loading gleich lazy gesetzt habe und das Ding ist beim ersten laden der Seite direkt im Viewport,

00:40:59.185 --> 00:41:00.076
dann passiert was nochmal?

00:41:01.219 --> 00:41:10.897
Dann weiß der Browser das ja erst, wenn das CSS ausgewertet ist und das Layout berechnet ist.

00:41:11.329 --> 00:41:18.960
Ja, und dann kann der, äh, der Ressourcenscanner aka Pre-Parser,

00:41:18.960 --> 00:41:26.894
der schon vorab durch das Dokument geht und versucht, eben alle Bilder und Skripte und Style-Sheets, ähm,

00:41:27.938 --> 00:41:33.394
schon mal in die Queue zu werfen, der würde das dann eben einfach noch nicht laden.

00:41:34.051 --> 00:41:48.139
Das heißt, du verlierst Zeit, und zwar so viel Zeit, wie zwischen Pre-Parser geht über die Seite, CSS-Dateien wurden alle geladen und wurden auch ausgewertet.

00:41:49.643 --> 00:41:56.421
Okay, gut. Verstanden. Dann ergibt das jetzt Sinn. Das musste das nur kurz noch enttütteln, weil ganz so trivial ist es ja nicht.

00:41:57.259 --> 00:42:03.893
Nee. Also ich denke auch, dass dieses Auto kommen wird.

00:42:05.100 --> 00:42:11.520
Es macht ja total Sinn, beziehungsweise das Verhalten, das nicht sozusagen der jetzige Normalfall ist,

00:42:11.520 --> 00:42:13.634
ist ja schon ein bisschen schwach.

00:42:14.444 --> 00:42:20.320
Ja. Ja, wo dieses Sizes-Attribut auch ein bisschen querschießt,

00:42:20.320 --> 00:42:24.300
ist, wenn du anfängst, mit Container-Queries zu arbeiten.

00:42:24.797 --> 00:42:32.140
Ja. Da würde so ein Sizes-gleich-auto auch helfen. Bei Container-Queries, du kannst ja ein Sizes-Attribut

00:42:32.140 --> 00:42:43.640
sozusagen nicht ausdrücken in Container Currys und da bin ich mal gespannt, ob da noch Lösungen kommen und wenn ja, welche.

00:42:46.940 --> 00:42:53.840
Ja, es ist ein bisschen unglücklich, dass diese Syntax, sowohl Sourcet als auch Scythe, so eine Ad-Hoc-DSL ist für halt

00:42:53.840 --> 00:43:03.000
den spezifischen Use Case dieser spezifischen Attribute auf diesem Element. Das ist schon ein bisschen unglücklich, weil das halt die

00:43:03.000 --> 00:43:05.874
Interaktion mit den ganzen anderen Sachen, die da so sind und kommen,

00:43:06.873 --> 00:43:10.660
verkompliziert. Gerade so Sizes ist ja wirklich, sieht ja aus wie Media Query,

00:43:10.660 --> 00:43:17.442
ist es ja also quasi auch so ein bisschen vielleicht, aber schon so ein bisschen ein bisschen falscher freundgefahr.

00:43:19.413 --> 00:43:24.626
Tja. Hätt's mal alles Jason machen müssen, das hätt's geholfen.

00:43:26.300 --> 00:43:27.227
Ja. Jason hätte geholfen.

00:43:27.623 --> 00:43:30.723
Aber dann hätten wir die Leute, die dauernd rumpöbeln von wegen,

00:43:30.783 --> 00:43:36.185
da müssen aber Kommentare drin erlaubt sein, auch in den Diskussionen um HTML, wär vielleicht auch nicht gut.

00:43:36.623 --> 00:43:40.403
Ich guck grad durch die Liste durch, was wir uns als Nächstes schnappen.

00:43:40.463 --> 00:43:44.063
Hier sind Sachen drin wie InlineSVG, die find ich jetzt nicht so ...

00:43:45.403 --> 00:43:50.603
Oder ist ja nicht so spannend, Picture-Element. Weiß ich nicht, ob man da jetzt irgendwie noch drüber reden muss.

00:43:52.236 --> 00:43:58.103
Ich hätte so zwei Sachen, da hätte ich tatsächlich im Sinne der Survey tatsächlich so die Fragen an dich,

00:43:58.103 --> 00:44:01.598
was mich interessieren würde. Du als so praktischer Mann aus dem Schützengraben.

00:44:03.038 --> 00:44:10.603
Wie sieht denn so deine Benutzung vom Template-Element aus? Eigentlich eher mau.

00:44:11.023 --> 00:44:14.840
Ich meine, gerade benutze ich das für irgendwas? Nö, ich glaube nicht.

00:44:15.227 --> 00:44:18.693
Okay. Finde ich nämlich interessant. Ich benutze das nämlich auch für nix.

00:44:19.684 --> 00:44:24.103
Weil es scheint mir halt von der Konzeption her außerordentlich seltsam,

00:44:24.284 --> 00:44:30.103
ein Template zu definieren in HTML.

00:44:30.103 --> 00:44:34.103
Und vermutlich, um Templating durchzuführen, brauche ich ja wahrscheinlich JavaScript,

00:44:34.103 --> 00:44:37.823
also eine andere, ganz andere Sprache. Und das dann irgendwie cross-referenzieren,

00:44:38.624 --> 00:44:42.103
sozusagen per GetElementById und Consorten, ist ja schon mühsam.

00:44:42.103 --> 00:44:48.103
Wahrscheinlich wäre es einfacher, sich dann, keine Ahnung, mit einem entsprechenden Tag-Template-Literal da was

00:44:48.103 --> 00:44:52.020
ins JavaScript direkt reinzubauen oder JSX zu verwenden oder, oder, oder.

00:44:53.694 --> 00:44:55.764
Das ist nämlich halt eben auch mein Eindruck, dass das relativ.

00:44:57.916 --> 00:45:01.031
Sagen wir mal, overstated ist, was das so zu leisten vermag.

00:45:01.103 --> 00:45:06.954
Und deswegen bei vielen außerhalb jetzt da, wo das irgendwie in so ein Framework-Kompilierprozess eingebaut ist,

00:45:07.135 --> 00:45:11.103
irgendwie nicht so richtig viel Verwendung findet, ist so mein Eindruck.

00:45:11.608 --> 00:45:14.103
Plus, es fehlt ja das Wichtigste an so einer Templating-Sprache,

00:45:14.103 --> 00:45:16.263
nämlich irgendwie die Möglichkeit, das Zeug rein zu interpolieren.

00:45:18.306 --> 00:45:21.832
Ja, da hatte ja Apple irgendwann mal einen Vorschlag gemacht vor Ewigkeiten.

00:45:21.832 --> 00:45:24.832
Das hatten wir dann auch mal hier bei uns erwähnt.

00:45:25.067 --> 00:45:27.426
Ich weiß noch nicht mehr genau, wie das hieß.

00:45:28.092 --> 00:45:32.832
Ja, aber da müsste es eigentlich vorangehen an der Stelle.

00:45:33.511 --> 00:45:39.832
Oder jemand müsste halt hingehen und müsste sagen, wir bauen so eine Art ab dafür.

00:45:39.832 --> 00:45:42.832
Es gibt ja genug Templatesprachen da draußen, die irgendwie in der Lage sind,

00:45:42.832 --> 00:45:45.832
da Mustache, JS und ähnliches irgendwie in so Content reinzufriemeln.

00:45:45.832 --> 00:45:49.445
Das passiert halt nun meistens entweder serverseitig oder irgendwie auf String-Ebene.

00:45:49.832 --> 00:45:56.800
Aber allein schon so einen Adapter zu haben, dass man irgendwie sagen kann, das Ding verwendet als Input-String tatsächlich irgendwie ein Template-Element.

00:45:57.790 --> 00:46:03.435
Und holt sich dann davon irgendwie das innerHTML oder was auch immer und macht dann seinen ganzen Substitutionskram darauf.

00:46:04.245 --> 00:46:10.832
Das würde ja, glaube ich, schon was helfen. Das würde ja zumindest mal dieses, ich will irgendwie standardkonform sein, irgendwie zu haben.

00:46:10.832 --> 00:46:15.696
Man kann ja auch das Template-Element als so eine Art einfach nur String-Wrapper verwenden.

00:46:15.930 --> 00:46:21.832
Also man muss ja nicht wirklich ein Template-Element als HTML in seinen Content reinschreiben, man könnte ja wirklich irgendwie sagen,

00:46:21.832 --> 00:46:27.832
ich bin eine Funktion, ich mache dieses Templating-Interpolationsgebimsel und als Input verwende ich ein Template-Element,

00:46:28.353 --> 00:46:30.832
und kann es das ja auch mit Document-Create-Element oder so erzeugen.

00:46:31.810 --> 00:46:38.832
Ja. Aber da fehlt es halt wirklich, die Nützlichkeitshürde wird nicht genommen, dass diese entsprechenden Libraries nachziehen

00:46:38.832 --> 00:46:45.352
würden, um das zu machen. Und bei der Apple-Geschichte bin ich jetzt auch so

00:46:45.352 --> 00:46:48.872
in meinem aktuellen HTML-Minimalismus-Trip so ein bisschen auf der Frage,

00:46:48.872 --> 00:46:52.912
okay, kriegt man das wirklich hin, die Templatesprache da zu definieren, die in

00:46:52.912 --> 00:46:56.872
HTML dann drin ist und die dann auch den Test der Zeit besteht. Und wenn ich mir

00:46:56.872 --> 00:47:00.152
so angucke, wie viele Templatesprachen es da draußen gibt, bin ich da eher ein

00:47:00.152 --> 00:47:03.696
bisschen skeptisch, dass so der nächste Schuss dann definitiv ein Erfolg wird.

00:47:05.883 --> 00:47:16.092
Ja, wahrscheinlich nicht, aber es steht halt Web Components auch einfach im Weg, dass das nicht geht. Tut's das?

00:47:17.199 --> 00:47:28.380
Naja, ich würde schon sagen. Also, wäre doch schön, wenn die Plattformen da was anbieten würde und man nicht LIT oder was weiß ich was benutzen müsste.

00:47:30.550 --> 00:47:36.053
Ja, naja, wie gesagt, das stößt halt auch wieder an meinen, kriegt man das dann wirklich korrekt,

00:47:36.455 --> 00:47:44.373
so also richtig hin, gibt es da die One-Size-Fits-80-Prozent-Lösung? Da habe ich halt so ein bisschen,

00:47:46.196 --> 00:47:50.693
ist halt schwierig, weil das, weil da wird halt echt so ein großes Rad gedreht und da muss halt

00:47:50.693 --> 00:47:55.013
wirklich, muss man halt irgendwie auch wirklich sagen, dem Scope-Creep halt auch zu widerstehen

00:47:55.013 --> 00:48:00.896
Und zu sagen, so brauchst du jetzt nicht Selection und Article vielleicht.

00:48:02.022 --> 00:48:05.013
Hätte auch eins gereicht, weil wir kennen doch unsere Nerds,

00:48:05.181 --> 00:48:10.013
die werden entweder das gar nicht wissen, oder sie werden es falsch verwenden,

00:48:10.013 --> 00:48:13.013
oder wenn sie, sagen wir mal so, die Geistesgegenwart haben, es richtig zu verwenden,

00:48:13.013 --> 00:48:17.685
werden sie elendige Diskussionen darüber auslösen, wann man jetzt was verwenden sollte.

00:48:18.013 --> 00:48:24.013
Also entweder, wenn es klar ist und einen einigermaßen verdaubaren Scope hat,

00:48:24.013 --> 00:48:31.373
eine html element ja und ansonsten das template halt so ein bisschen so ein rohrkrepierer mein

00:48:31.693 --> 00:48:32.521
Einer meiner meine andruck.

00:48:34.466 --> 00:48:42.316
Da hast du recht und einen weiteren Survey Eintrag wollte ich auch noch mal hier vor die Nase werfen. Wie gesagt, du jetzt hier als

00:48:42.604 --> 00:48:46.316
mein Kontakt in die Realität. Das jetzt unser Service Eintrag Custom,

00:48:47.141 --> 00:48:53.451
Elements. Da wird ja nachher sicherlich wie bei State of JS sowas drin sein, wie irgendwie verwende ich ständig verwende ich manchmal habe ich noch nie von gehört.

00:48:54.838 --> 00:49:07.306
Wie ist es bei dir? Nee, also benutze ich auch tatsächlich nicht das Das Einzige, das ich jetzt letztens mal verbaut habe,

00:49:07.594 --> 00:49:17.226
ist das Google Chromecast Launcher Element.

00:49:17.803 --> 00:49:22.205
Wo im Prinzip die Library in Form eines Elements daherkommt.

00:49:22.664 --> 00:49:28.218
Ja, also du lädst deren Framework

00:49:28.344 --> 00:49:34.056
Und dann baust du eben an die Stelle, wo du eben diesen Cast-Knopf haben möchtest,

00:49:34.056 --> 00:49:42.956
dann baust du eben das, ich glaube, das heißt Google-Cast-Launcher-Element ein.

00:49:42.956 --> 00:49:49.725
Und dann kannst du damit Videos an einen Chromecast schicken oder Audio.

00:49:50.148 --> 00:49:53.740
Okay, und früher wäre das ein Diff mit einer ID gewesen?

00:49:54.456 --> 00:50:00.416
Früher wäre das ein Diff mit einer ID gewesen, genau. Es wäre dann semantisch ähnlich schön, wie das jetzt das Ding ist,

00:50:00.416 --> 00:50:06.656
weil es ist ein Knopf, aber hat keinen Roll-Button und es ist auch nicht tastaturfokussierbar.

00:50:07.630 --> 00:50:09.216
Das hat Google leider alles vergessen.

00:50:10.997 --> 00:50:18.896
Und das muss man dann selber noch nachrüsten. Okay. Okay, gut, aber das ist ja sozusagen ein Fail

00:50:18.896 --> 00:50:28.110
auf der Ebene der Implementierung und nicht so sehr, also, ein Failing von Custom Elements an sich.

00:50:30.334 --> 00:50:36.136
Joa, wahrscheinlich. Aber was würdest du denn vermuten, was der Grund ist, warum du noch nicht die Dinger verwendest?

00:50:36.136 --> 00:50:40.136
Weil ich habe letztens Diskussionen gesehen, irgendwie so, da kam ein Artikel, machte die Runde

00:50:40.136 --> 00:50:44.136
von wegen, ja, irgendwie, so und so viel Prozent der Webseiten benutzen Custom Elements.

00:50:44.136 --> 00:50:47.276
Ja, ich habe so ein Ding noch nie benutzt, bla Keks, und dann hat man sich darüber gezankt.

00:50:48.374 --> 00:50:58.136
Wie ist es bei dir? Warum nicht? Genau, ich benutze es deswegen nicht, weil ich dieses Konzept von meiner ganzen Seite

00:50:58.136 --> 00:51:03.136
ist eben so lange tot, bis ein Riesenhaufen JavaScript das alles initialisiert,

00:51:03.136 --> 00:51:04.687
finde ich halt irgendwie doof.

00:51:05.587 --> 00:51:14.136
Davon bin ich kein Anhänger. Ich möchte gerne im Prinzip so viel wie möglich Fertiges ausliefern über das HTML.

00:51:14.136 --> 00:51:16.587
HTML. Und ähm.

00:51:19.162 --> 00:51:41.830
Das ist eigentlich der Grund. Ich könnte jetzt meine ganzen Komponenten, ich baue ja auch Komponenten, also vermutlich könnte ich die auch alle anstatt eben den Klassennamen so zu namespacen für das Projekt und dann den Komponentennamen dann folgend lassen, könnte ich das Ganze auch in Web Components oder in Custom Elements ausdrücken.

00:51:42.073 --> 00:51:47.212
Genau, ich könnte natürlich auch, man muss ja auch das, was da drin ist,

00:51:47.212 --> 00:51:52.659
nicht unbedingt aus HTML rauslassen, also das würde ja auch gehen.

00:51:53.416 --> 00:52:04.512
Aber ja, ich hätte halt Events wie vielleicht irgendwie sowas wie onMounted und onUnmounted und sowas, das regle ich aber im Grunde alles über

00:52:04.512 --> 00:52:12.312
Also ich nutze schon Teile der Web-Components-Dinge,

00:52:12.312 --> 00:52:17.200
aber eben weiß nicht, warum ich das jetzt quasi machen sollte.

00:52:17.749 --> 00:52:23.912
Also ich denke, das hat ja, wenn du das jetzt so beschreibst,

00:52:23.912 --> 00:52:27.712
es soll ja möglichst ohne großartige JavaScript-Initialisierung,

00:52:27.712 --> 00:52:32.512
die nicht strikt nötig ist, daherkommen, hat ja wahrscheinlich auch dann was mit der Art von Projekt zu tun,

00:52:32.512 --> 00:52:38.012
der du arbeitest, weil du ja von einer Welt ausgehst, in der überhaupt jetzt so ein Server,

00:52:38.012 --> 00:52:40.750
der fertiges Markup ausliefert, eine nennenswerte Rolle spielt.

00:52:43.198 --> 00:52:50.612
Genau. Also, ich glaube, ich würde... Wahrscheinlich würde ich Web Components benutzen

00:52:50.612 --> 00:52:55.812
in einem Kontext, wo ich eine Komponentenbibliothek bauen müsste,

00:52:55.812 --> 00:52:59.592
die von relativ vielen Konsumenten genutzt wird.

00:53:00.158 --> 00:53:13.545
Also verschiedenen, da würde ich glaube ich, also da würde ich dann den Weg einschlagen oder zumindest den erforschen, vielleicht ist es ja auch trotz alledem dann nicht der richtige Weg, das weiß man nicht.

00:53:15.093 --> 00:53:21.943
Aber wenn ich eben eine Komponentenbibliothek habe, die möglichst wiederverwendbar sein soll,

00:53:21.943 --> 00:53:23.943
dann finde ich eben diese Ansätze,

00:53:24.302 --> 00:53:30.892
hey, dann schreibe ich eben ein HTML und CSS und JavaScript dafür und dann muss jedes Mal irgendwer hingehen und das portieren,

00:53:31.378 --> 00:53:38.616
nach React, nach Angular, nach was weiß ich was, oder vielleicht auch serverseitig in eine serverseitige Sprache.

00:53:38.958 --> 00:53:43.943
Das finde ich dann irgendwie nicht so attraktiv.

00:53:44.567 --> 00:53:50.943
Bedenke, was du dafür tun müsstest. Stell dir vor, du würdest tatsächlich das Selectlist-Element jetzt als UI-Komponente,

00:53:51.282 --> 00:53:55.612
die man sich dann npm install add-shap-selectlist installieren könnte.

00:53:55.943 --> 00:53:57.943
Stell dir vor, du wolltest das bauen.

00:53:59.042 --> 00:54:01.943
Du müsstest ja auf diesem Ding, und wir reden jetzt ja von einem Element,

00:54:01.943 --> 00:54:05.767
ja im Prinzip eine komplette Formularelement-API nachbauen.

00:54:07.964 --> 00:54:11.672
Du kannst ja nicht einfach eine API exposen, du müsstest sie ja nachbauen.

00:54:12.708 --> 00:54:15.943
Du musst da mit den Internals hingehen, deinen internen State managen.

00:54:15.943 --> 00:54:19.943
Vom Fokus-Management reden wir noch nicht mal, das kriegt man, glaube ich, noch am ehesten hin,

00:54:19.943 --> 00:54:23.943
aber du musst halt die komplette API exposen von einem Select- oder einem Select-ähnlichem Objekt

00:54:23.943 --> 00:54:25.943
und das dann da irgendwie durchleiten.

00:54:25.943 --> 00:54:29.943
Das ist immer so bei Komponenten-Library, wo ich mir so denke, ja, okay,

00:54:29.943 --> 00:54:31.943
wenn du die mit React baust, dann funktioniert die nur in React,

00:54:31.943 --> 00:54:33.943
aber dafür bist du halt auch in endlicher Zeit fertig.

00:54:36.852 --> 00:54:39.943
Ja, also das wäre halt so ein Fall, wo ich jetzt nicht ausschließen möchte,

00:54:39.943 --> 00:54:44.180
ausschließen möchte, dass ich dann irgendwie sage, so nee, dafür nicht.

00:54:44.297 --> 00:54:50.623
Oder vielleicht wäre die Lösung in dem Fall dann, dass die Inputs nicht einzeln wären,

00:54:50.623 --> 00:54:57.296
sondern ich ein Custom-Formular-Gerät hätte,

00:54:57.476 --> 00:55:03.943
dass ich dann konfiguriere, dass es unter anderem so einen stylbaren Select hat oder sowas.

00:55:04.453 --> 00:55:13.383
Also was bei mir nämlich letztens mal so aufgefallen ist, was den Web-Components wirklich fehlt und was für viele Use-Cases echt nützlich wäre, ist nämlich was,

00:55:14.337 --> 00:55:17.063
also beim Select-List-Element könnte ich es halt noch irgendwie so nachvollziehen, dass man sich die

00:55:17.063 --> 00:55:20.983
Aufgabe macht, weil dann kriegt man wirklich ein neues nützliches Widget hin und das leistet dann

00:55:20.983 --> 00:55:23.703
etwas, was vorher nicht ging und das funktioniert überall und das ist irgendwie ziemlich gut, aber

00:55:23.703 --> 00:55:28.743
viele Komponenten in echten Projekten sind ja auch so Dinge wie, ich brauche ein Select und das ist

00:55:28.743 --> 00:55:32.463
irgendwie ein bisschen vorkonfiguriert, da gibt es halt nur die drei Options drin und das hat immer

00:55:32.463 --> 00:55:37.743
diese CSS-Klasse, damit diejenigen, die es nachher irgendwo rein droppen, nicht eben den Inhalt

00:55:37.743 --> 00:55:41.863
managen müssen und die Klasse managen müssen und sowas alles. Und das ist so ein

00:55:41.863 --> 00:55:43.910
Use Case, den können die Web Components gar nicht.

00:55:46.259 --> 00:55:51.729
Ja. Weil die Möglichkeit, der einzige Weg, internes DOM auszudrücken, ist Shadow DOM.

00:55:51.958 --> 00:55:53.569
Das ist per Definition isoliert.

00:55:53.803 --> 00:55:57.569
Und es gibt halt nicht ein Feature, für das ich jetzt votieren würde,

00:55:57.800 --> 00:56:04.529
dass man irgendwie eine Art Membranmechanismus braucht, um zu sagen, dieses Custom-Element-Ding da

00:56:04.569 --> 00:56:07.307
expost die API von diesem Ding im Shadow DOM.

00:56:07.811 --> 00:56:13.109
Mhm. Dass gewisse Sachen wie Attive Endless-Nodes vielleicht einfach durchgetunnelt werden.

00:56:13.109 --> 00:56:20.432
Und mit offenem Shadow DOM, es gibt ja Close und Open, wäre das eine Möglichkeit, auch wenn man dann vielleicht

00:56:20.509 --> 00:56:24.123
den Schutz vor Style-Leaking verliert?

00:56:24.870 --> 00:56:28.768
Nee, der Schutz vor Style-Leaking ist dann ja gegeben. Open heißt ja bloß, dass auf dem Element

00:56:28.894 --> 00:56:32.018
die Property Shadow-Root von außen accessible ist.

00:56:33.188 --> 00:56:38.809
Ah, okay. Das würde halt eben nicht helfen, weil dann könnte zwar jemand von außen

00:56:39.184 --> 00:56:44.449
im Prinzip durch die Shadow-Root-Elementgrenze durchgreifen und sagen, im Shadow-Root mache ich einen Query-Selector

00:56:44.576 --> 00:56:46.799
auf das Select-Element und hänge da ein Event-Listener drauf.

00:56:47.214 --> 00:56:52.609
Aber dann muss ja sozusagen die Benutzerseite, die diesen Schritt macht, aware sein,

00:56:52.609 --> 00:56:55.154
dass das Ding Shadow-DOM als Implementierungsdetail hat.

00:56:56.261 --> 00:57:00.600
Und das wollen wir ja nicht. Wir wollen ja sagen, hey, verwende hier Project-Select.

00:57:01.041 --> 00:57:03.009
Das hat alles vorkonfiguriert, du musst darüber nicht nachdenken,

00:57:03.009 --> 00:57:03.958
das ist ein Select-Element.

00:57:04.516 --> 00:57:05.524
Aber es kann keins sein.

00:57:06.307 --> 00:57:15.029
Und wenn es keins ist und man es aussehen lassen möchte, wie eins, gibt's dafür keinen Mechanismus, keine Membran oder sowas?

00:57:15.292 --> 00:57:22.229
Ja, ich glaube, Formularelemente sind ja ein großes Dauerthema,

00:57:22.229 --> 00:57:27.598
so was mit Webcomponents echt schwierig ist und generell auch so Beziehungen ausdrücken,

00:57:27.729 --> 00:57:32.169
wie zum Beispiel Label to Input oder gibt ja auch andere Dinge,

00:57:32.169 --> 00:57:35.969
die man sozusagen per Beziehung ausdrücken kann.

00:57:35.969 --> 00:57:41.129
Und wenn eben diese Beziehung über die Grenzen gehen müsste,

00:57:41.129 --> 00:57:47.475
über die Custom-Element-Grenze, dann klappt das ja schon wieder nicht mehr.

00:57:47.718 --> 00:57:48.582
Ach doch, schon.

00:57:48.852 --> 00:57:51.129
Kannst auch in die Klasse einen Static-Block reinbauen.

00:57:51.841 --> 00:57:57.422
Dann kannst du da ja sozusagen anders initialisieren, der Klasse irgendwelche Nebenwirkungen hängen.

00:57:58.953 --> 00:58:03.094
Also, du willst irgendwie jetzt die Kommunikation haben zwischen einem Label und irgendwie einem Ding mit einer ID,

00:58:03.346 --> 00:58:07.629
also so per Vorattribut oder sowas. Genau. Da kannst du ja theoretisch einfach so

00:58:07.629 --> 00:58:10.629
im Prinzip eine JavaScript-Umgehungsstraße aufmachen.

00:58:11.403 --> 00:58:18.731
Also, die Klasse wird initialisiert entweder von dem Target oder von dem, das das anzielt.

00:58:19.424 --> 00:58:22.509
Und das macht dann einfach so einen JavaScript-Nebenstraße auf,

00:58:22.509 --> 00:58:24.708
in dem das halt irgendwie einen globalen Event-Bus initialisiert.

00:58:25.509 --> 00:58:27.319
Und dann pingpongen die darüber ihre Kommunikation und keiner kriegt das mit.

00:58:28.786 --> 00:58:33.449
Genau, aber so aus Accessibility-Gründen, also das würde das ja nicht lösen, oder?

00:58:34.197 --> 00:58:39.508
Das kannst du doch mit irgendwelchen Internals, wo du Area-Fork konfigurierst, möglicherweise hinkriegen.

00:58:40.183 --> 00:58:40.552
Mh.

00:58:42.938 --> 00:58:48.888
Du könntest ein ARIA-Label dann draufsetzen, das den gleichen Inhalt trägt wie eben das,

00:58:48.928 --> 00:58:53.497
was das Label, das eben außerhalb liegt, selber auch hat.

00:58:54.020 --> 00:58:59.628
Genau. Dein Custom-For-Attribut ist sozusagen eine Fassade für einerseits die ARIA-Mechanik, die unten drunter liegt,

00:58:59.817 --> 00:59:04.268
und deine JavaScript-Umgehungsstraße, um die tatsächliche Interaktion mit dem Fokussieren

00:59:04.308 --> 00:59:06.508
und Gedöns möglich zu machen, andererseits.

00:59:06.548 --> 00:59:09.071
Da geht halt eben schon alles nicht trivial.

00:59:09.656 --> 00:59:10.008
Nee.

00:59:10.728 --> 00:59:18.168
Deswegen also wahrscheinlich, also mein Weg wäre wahrscheinlich einfach nur ein Custom-Form-Element zu haben und

00:59:18.168 --> 00:59:26.168
das eben zu konfigurieren mit den Inputs, die es haben soll, sodass das alles dann zusammen

00:59:26.168 --> 00:59:27.418
in dem einen Ding lebt.

00:59:28.669 --> 00:59:36.168
Okay, das heißt so, dass der Baustein, mit dem dann deine Mitarbeiter arbeiten, ist nicht das Select-Element, also irgendwie, das ist ja meistens,

00:59:36.168 --> 00:59:40.168
kommt das ja in Form von so einer Row da, dass man irgendwie sagen kann, es gibt ein Label, dann diesen Input-Typ,

00:59:40.168 --> 00:59:43.528
und das packe ich in so ein Ding rein, dann wird es formatiert und alles ist gut.

00:59:43.528 --> 00:59:46.854
Sondern dein Abstraktionslevel wäre das Formelement?

00:59:49.564 --> 00:59:58.044
Wahrscheinlich. Oh, ein Hot Take. Bin ich aber mal gespannt, ob da nicht dann irgendwie so die Vielzahl der Änderungen am Formular dann...

00:59:59.349 --> 01:00:02.653
Ja, also, aber vielleicht, also ich meine...

01:00:04.088 --> 01:00:08.144
Ich glaube, unter unseren Hörerinnen und Hörern sind bestimmt einige, die...

01:00:08.468 --> 01:00:14.748
Die mit Web Components arbeiten oder gearbeitet haben oder sich die Zähne ausgebissen haben

01:00:14.748 --> 01:00:16.885
oder Lösungen für diese Dinge gefunden haben,

01:00:17.120 --> 01:00:21.044
erzählt uns doch mal, wie ihr das in der Praxis dann macht.

01:00:21.513 --> 01:00:27.850
Oder ob Web Components für euch eigentlich auch eher ähm, ja, nix sind.

01:00:28.102 --> 01:00:30.290
Spannender fände ich, was fehlt.

01:00:31.604 --> 01:00:37.548
Oder was wollt ihr erwarten und woran scheitert ihr? Weil das sind ja genau die Dinge, die in dem Survey da am Ende rauskommen sollten.

01:00:37.548 --> 01:00:39.548
Das und das und das fehlt, weil...

01:00:41.309 --> 01:00:44.679
Man ist halt immer Kind seiner Zeit, Kind von dem Gedankengebäude,

01:00:44.739 --> 01:00:49.439
in dem man da unterwegs ist, und unter der Prämisse wurden auch Web Components entwickelt,

01:00:49.499 --> 01:00:52.479
dass man so Sachen wie Style Scoping überhaupt haben will.

01:00:52.539 --> 01:00:57.479
Das ist ja sowieso auch schon mal eine Annahme, wo ich jetzt irgendwie sagen möchte, ist das so?

01:00:57.539 --> 01:01:02.039
Weil ich meine, irgendwie muss man ja auch das CSS in seine Komponente dann reinkriegen.

01:01:02.099 --> 01:01:08.359
Und vielleicht will man ja irgendwie so gewisse Basics, die jetzt über Dinge, die mit CSS-Variablen konfigurierbar sind,

01:01:08.419 --> 01:01:10.519
hinausgehen, irgendwo einheitlich haben.

01:01:10.519 --> 01:01:14.519
Da Link-Tags reinbauen, die hast du alle reinrümpeln, aber dann ist ja mein Shadow DOM total aufgeblasen.

01:01:14.519 --> 01:01:17.624
Weiß Gott, was das für die Performance macht. Keine Ahnung, Shape, das musst du mir sagen.

01:01:18.650 --> 01:01:22.519
Oder man baut sich halt irgendwie ein Build-Tool, dass dann halt das CSS da einfach reininlined,

01:01:22.519 --> 01:01:26.519
was sehr, sehr bequem ist, aber garantiert auch nicht gut ist,

01:01:26.519 --> 01:01:30.519
weil dann ist ja jede Komponente ausgestattet mit irgendwie einem erheblichen Batzen CSS.

01:01:30.695 --> 01:01:33.459
Kann man das irgendwie filtern? Ja, okay, ist aufwendig.

01:01:34.674 --> 01:01:38.519
Also mich interessiert mehr so, wo scheitert es überall noch und wie kriegt man das irgendwie hin?

01:01:38.519 --> 01:01:41.019
Und diese Membran-Idee, die ich da jetzt gerade vorhin ausgebreitet habe,

01:01:41.019 --> 01:01:45.873
ist nur die jüngste, auf die ich gekommen bin, was man da eigentlich haben müsste, um halt einfach so dieses,

01:01:46.881 --> 01:01:50.319
diese Leichtigkeit von, ich baue mal eben eine React-Komponente raus,

01:01:50.319 --> 01:01:52.625
worüber man ja da gar nicht nachdenkt, weil es halt so einfach ist,

01:01:52.859 --> 01:01:55.073
weil es nur ein Vorkonfigurieren von HTML ist.

01:01:55.686 --> 01:02:01.819
Das muss man ja auch irgendwie mit irgendwas abbilden. Und mit einer Klasse, wo ich irgendwie 1000 Properties definieren muss,

01:02:01.819 --> 01:02:02.833
macht man das definitiv nicht.

01:02:05.003 --> 01:02:11.819
Ja, das, da gebe ich dir recht. Und wenn wir jetzt nicht mal ein Select-Element,

01:02:11.819 --> 01:02:15.819
wir zwei hier, Shep und ich, hinkriegen in der Kürze der Zeit,

01:02:15.819 --> 01:02:19.819
dann würde ich halt auch an so Sachen wie so Select-List ein großes Fragezeichen hängen,

01:02:20.586 --> 01:02:27.819
an das Tab-Interface ein großes Fragezeichen hängen, weil das alles so irre kompliziert ist, dann auch noch so hinzukriegen,

01:02:27.819 --> 01:02:29.264
dass es wirklich für alle nützlich ist.

01:02:30.704 --> 01:02:34.404
Ich kriege ja nicht mal ein Select-Element hin, das für mich nützlich ist per Web-Component.

01:02:35.971 --> 01:02:44.539
Ja, wir gucken mal, wie sich das weiterentwickelt. Ich weiß gar nicht, das Select-Menü, Select-List,

01:02:44.539 --> 01:02:48.817
haben wir da gesagt, es ist nur, du hast gesagt, Chrome wäre das nur, oder? Richtig?

01:02:49.039 --> 01:02:52.211
Ich hatte, glaube ich, bei MDN gesehen, dass das in Chrome ist.

01:02:53.156 --> 01:02:57.539
Moment, Select-List. Ja, ich finde, das ist ja immer so ein Indikator,

01:02:57.539 --> 01:02:59.039
wie kompliziert Dinge sind.

01:02:59.039 --> 01:03:15.139
Also du hast ja gesagt, die Popover API, die gäbe es ja auch in Safari, im Technology Preview und in Firefox hinter Flags, das ist ja dann so ein bisschen so ein Indikator dafür, dass es keine großen Probleme irgendwie konzeptioneller Natur gibt.

01:03:18.218 --> 01:03:23.228
Ja, einerseits das, andererseits kann ich mir einfach vorstellen,

01:03:23.935 --> 01:03:27.468
dass hier gerade bei Popover, wo du ja auch gesagt hast, da gibt es ja die sozusagen CSS-Features,

01:03:27.468 --> 01:03:30.407
die das Backend darstellen, die gibt es ja konzeptionell auch schon,

01:03:31.037 --> 01:03:36.853
dass sozusagen das Umwandeln des Ganzen in ein HTML-User-Interface jetzt nicht so der große Sprung ist.

01:03:37.537 --> 01:03:39.708
Dass man irgendwie sagt, ja, okay, wir machen hier irgendwie Constraints drauf

01:03:39.708 --> 01:03:42.708
und mit dem CSS-Mechanismus, den wir schon ausspezifiziert haben,

01:03:42.812 --> 01:03:47.228
wo wir schon über die ganzen Interaktionen und Probleme und Stacking-Kontexte und so weiter nachgedacht haben,

01:03:47.228 --> 01:03:50.761
Das nehmen wir einfach und adaptieren das und bauen dann ein bisschen HTML-UI drumherum.

01:03:51.625 --> 01:03:56.955
Das ist, glaube ich, eine andere Geschichte, als zu sagen, wir definieren jetzt das Select-Element neu und zwar so, dass es für alle funktioniert.

01:03:58.629 --> 01:04:06.428
Das halte ich für die wesentlich größere Geschichte und ich suche jetzt ja noch irgendwie, weil ich meine, wenn Sie das bei Chrome implementieren,

01:04:06.428 --> 01:04:12.376
haben Sie ja normalerweise auch irgendwen, der das in so eine Art Spezifikationstext gießt.

01:04:14.572 --> 01:04:18.047
Aber den finde ich hier gerade nirgendwo.

01:04:20.532 --> 01:04:25.897
Äh, customizable Select Element, Blau Keks, ja, ich finde halt das Spezifikationsdokument nicht.

01:04:26.518 --> 01:04:30.308
Weil? Irgendwie so der Explainer da von Open UI, der liest sich gut.

01:04:30.308 --> 01:04:31.788
Das ist ein super MDN-Artikel.

01:04:32.667 --> 01:04:37.708
Wie funktioniert das wirklich? Ja, was kann ich da an interaktiven Elemente in diese interaktiven

01:04:37.708 --> 01:04:43.908
Elemente reinbauen, damit es schwierig wird? Kann ich in das Kann ich in das Option-Äquivalent da einen Link reinbauen?

01:04:43.908 --> 01:04:46.908
Kann ich in das Option-Element da ein Formular-Äquivalent reinbauen?

01:04:46.908 --> 01:04:47.818
Und was machst du, wenn ich Select-Lists in Select-Lists habe?

01:04:50.905 --> 01:04:55.908
Das hätte ich halt gerne mal irgendwo ausspezifiziert, bevor ich da jetzt irgendwie sage, das ist irgendwie easy.

01:04:55.908 --> 01:04:58.629
Spontan hört sich das für mich sehr, sehr kompliziert an.

01:04:59.224 --> 01:05:04.715
Also angeblich ist es ja ein Editor's Draft zumindest. Puh.

01:05:04.908 --> 01:05:11.314
Aber wie das jetzt, wo der sein soll, wo der sein soll, oder ob das wirklich nur dieser Explainer ist.

01:05:14.014 --> 01:05:17.291
Äh, genau, auf GitHub haben sie was.

01:05:19.908 --> 01:05:20.667
Damm-di-damm.

01:05:24.908 --> 01:05:32.908
Naja. Nicht, dass das so wichtig ... Naja, find ich schon, weil im Moment find ich halt bloß so Dinge so,

01:05:32.908 --> 01:05:34.908
das wollen wir erreichen. Ja, super.

01:05:35.359 --> 01:05:36.484
Aber ich würde auch gern zum Mars fliegen.

01:05:36.988 --> 01:05:38.680
Wie machen wir das jetzt konkret?

01:05:39.302 --> 01:05:42.468
Und solange ich da nicht irgendwie die Spezifikation oder die Rakete sehe,

01:05:42.508 --> 01:05:44.442
bin ich da erst mal so im Zweiflercamp.

01:05:46.044 --> 01:05:51.228
Ja, zu Recht. Hast du denn hier auf der ersten Seite noch was,

01:05:51.268 --> 01:05:52.668
was dir ins Auge sticht?

01:05:52.708 --> 01:05:56.588
Hier, ich seh noch Input und dann die Showpicker-Methode drauf.

01:05:56.628 --> 01:05:57.855
Hab ich noch nie verwendet.

01:05:58.108 --> 01:06:04.628
Macht Sinn, ist wahrscheinlich auch sinnvoll, wenn man eben einen Input customizet

01:06:04.628 --> 01:06:10.828
und vielleicht irgendwie den eigentlichen Button, der ein Color Picker oder so öffnet, versteckt,

01:06:11.251 --> 01:06:16.168
um ihn dann eben alternativ öffnen zu können, sowas oder Datepicker.

01:06:18.200 --> 01:06:23.836
Ja, solche Geschichten habe ich jetzt auch noch nicht verwendet. Was haben wir da?

01:06:24.250 --> 01:06:28.436
Cutting-Edge-Chip, but not in all browsers. Also gibt es auch noch nicht überall. Anscheinend.

01:06:31.350 --> 01:06:37.168
Genau, dann gibt es hier noch das Portal-Element. Das gibt es ja auch schon relativ lange.

01:06:37.457 --> 01:06:39.392
Seit 2020 oder so.

01:06:40.445 --> 01:06:47.450
Ich glaube, das wurde mal schnell zusammengetackert für irgendein Google I.O. oder so was.

01:06:47.450 --> 01:06:48.890
Und man was zu erzählen hat.

01:06:48.950 --> 01:06:52.690
Manchmal merkt man das ja, dass die ganz schnell noch Dinge erfinden,

01:06:52.750 --> 01:06:56.550
um die dann so ein bisschen so ein Show-off machen zu können.

01:06:57.216 --> 01:07:01.834
Ich glaub, Portal war auch so was. Ich würd vor allen Dingen noch mal, Chef, du hast ja gerade gesagt,

01:07:02.447 --> 01:07:03.690
das gibt's schon sehr lange.

01:07:03.750 --> 01:07:07.150
Noch mal mit dir jetzt den ganz großen philosophischen Wurf wagen.

01:07:07.210 --> 01:07:08.650
Das Konzept oder die Idee.

01:07:08.710 --> 01:07:13.277
Aha, was wir unter Existenz verstehen. Also, weil das ist wieder so ein, man müsste mal zu Mars fliegen.

01:07:15.032 --> 01:07:18.290
Okay, wie machen wir das? Habt ihr eine Rakete, einen Getreibstoff, irgendwas?

01:07:18.350 --> 01:07:20.100
Ach, habt ihr nicht. Okay, schwierig.

01:07:21.622 --> 01:07:25.753
Genau, ein Portal ist ja eigentlich so vielleicht so der ...

01:07:26.750 --> 01:07:33.590
Das, was man damals versucht hat, was aber auch heutzutage die View-Transition-API übernimmt.

01:07:33.650 --> 01:07:38.850
Das heißt, man kann in einem Iframe die nächste Seite laden.

01:07:39.014 --> 01:07:42.354
Oder in einem Portal in dem Fall. Das ist im Prinzip wie ein Iframe.

01:07:42.590 --> 01:07:46.306
Dann kann man dieses Portal sozusagen zur Hauptseite promoten.

01:07:47.323 --> 01:07:47.683
Genau.

01:07:48.799 --> 01:07:52.590
Und das kann man eben animieren. Die View-Transitions,

01:07:52.590 --> 01:07:55.461
da den überwiegenden Teil von ganz gut abfrühstücken.

01:07:56.244 --> 01:08:01.222
Genau, aber ich glaube, damit dürfte das Thema auch durch sein mit den Portals.

01:08:02.663 --> 01:08:06.590
Ja, ich hoffe, weil das hört sich auch alles sehr nach einer Aufgabe an,

01:08:06.590 --> 01:08:12.106
die in CSS oder JavaScript oder irgendwas anderem als HTML EML echt besser aufgehoben ist, als...

01:08:13.727 --> 01:08:20.487
HTML, weil das ist ja nicht irgendwie Markup, also bin jetzt ja nicht wirklich der Purist, der da noch von ernsthaft von Dokumenten und Zeug spricht, aber trotzdem.

01:08:20.577 --> 01:08:24.440
Das ist ja schon arg interaktionsrelated.

01:08:24.845 --> 01:08:30.165
Ja, das bringt mich aber auf ein anderes Attribut, das hier irgendwo auch vorkommt.

01:08:30.577 --> 01:08:36.259
Wahrscheinlich nicht so hoch gewotet und zwar das Render Attribut,

01:08:37.106 --> 01:08:42.552
dass man auf, ich glaube, theoretisch auf beliebige Elemente setzen kann

01:08:42.786 --> 01:08:50.077
Und, ähm, genau, der Ursprung dieses Attributs kommt von den View-Transitions.

01:08:50.077 --> 01:08:53.823
Und, äh, genau, also, man kann das dann auf Blocking setzen.

01:08:55.077 --> 01:09:00.077
Das heißt also, dass der Browser eben erst anfängt zu rendern,

01:09:00.077 --> 01:09:04.077
wenn er dieses Element geladen hat.

01:09:04.473 --> 01:09:08.077
Das könnte also vielleicht ein Bild sein oder irgendwas anderes.

01:09:08.077 --> 01:09:17.077
Oder, ja, bei Skripten ist es ja, wenn die nicht async oder deferred sind, sind die ja auch Render-Blocking.

01:09:17.077 --> 01:09:25.077
Wobei es könnte ein Skript sein, das weiter unten ist, oder es könnte ein Skript sein, das man trotzdem asynchron oder deferred laden möchte,

01:09:25.077 --> 01:09:33.077
das aber Blocking sein soll, weil nämlich, also wichtig ist das für die View-Transitions, dass eben die Dinge da sind,

01:09:33.077 --> 01:09:36.862
zwischen denen dann auch gemorpht werden soll später.

01:09:37.077 --> 01:09:40.149
Und das kann man eben sicherstellen, zum Beispiel bei einem Bild,

01:09:41.077 --> 01:09:48.077
man da sagt, äh, Render Blocking, und dann würde eine View Transition auch erst, äh,

01:09:48.077 --> 01:09:55.813
anfangen zu transitionieren, wenn eben diese ganzen Render Blocking markierten Sachen dann auch da sind. Mh.

01:09:58.657 --> 01:10:12.507
Also eigentlich eher was, was man nicht haben möchte, und vielleicht so einer der großen Nachteile von View Transitions,

01:10:12.507 --> 01:10:14.420
obwohl die an sich ja schon ziemlich cool sind,

01:10:14.726 --> 01:10:19.255
aber das wäre dann wiederum was, wo das so ein bisschen,

01:10:19.966 --> 01:10:24.507
gegen die Natur von Rendering läuft.

01:10:25.457 --> 01:10:28.507
Ja, beziehungsweise, das ist ja, was du gerade ja erklärt hast,

01:10:28.950 --> 01:10:32.507
ist ja mehr oder minder einfach nur ein standardisierter Workaround eigentlich.

01:10:32.686 --> 01:10:35.035
Mhm.

01:10:37.051 --> 01:10:42.210
Genau. Ansonsten, View Transitions, hast du mit denen schon rumhantiert bestimmt, oder?

01:10:42.570 --> 01:10:50.507
Habe ich tatsächlich noch nicht ernsthaft mit rumhantiert, weil das in zu wenig, das bisher zu wenig Verbreitung hatte,

01:10:50.507 --> 01:10:55.567
um bisher von mir in meine Pipeline von forsche und setze das um in irgendwas

01:10:55.867 --> 01:10:59.407
produktmäßiges, das ist da noch nicht reingefallen, aber das steht tatsächlich

01:10:59.407 --> 01:11:04.727
für die nächsten zwei Monate auf meinem Zettel, dass ich mir die mal genauer anschaue.

01:11:04.727 --> 01:11:08.687
Ja, da bin ich mal gespannt, was du zu denen sagst. Also an sich sind die ja cool

01:11:08.687 --> 01:11:15.887
und man kann ja auch so Sachen damit machen, die bisher traditionell immer schwierig zu machen waren. Du kannst ja theoretisch auch eine View-Transition

01:11:15.887 --> 01:11:20.587
innerhalb der Seite selbst durchführen.

01:11:20.587 --> 01:11:25.787
Also du musst dafür ja nicht eine neue Seite laden, und man kann damit auch sowas machen,

01:11:25.787 --> 01:11:30.587
wie ich mach den ersten Snapshot der Seite,

01:11:30.587 --> 01:11:36.314
wenn die Liste zehn Elemente hat, und jemand drückt auf den Löschen-Knopf von einem dieser Elemente.

01:11:37.511 --> 01:11:44.361
Und dann, wenn im Anschluss wird das Element eben gelöscht, und dann aktiviert sich die Transition,

01:11:44.361 --> 01:11:47.054
und dann hast du eben das,

01:11:47.361 --> 01:11:55.601
also, dann rutscht die Liste eben weich zusammen, und das Element wird nicht einfach so quasi weggenommen,

01:11:55.601 --> 01:12:00.593
und sofort ist die Liste eben kürzer.

01:12:00.710 --> 01:12:03.096
So, das sieht ja immer ein bisschen doof aus.

01:12:03.257 --> 01:12:06.084
Das könnte dann weich eben zusammenfahren.

01:12:06.291 --> 01:12:12.863
Ja, und könnte halt diverse, sonst relativ aufwendige JavaScript-CSS-Transformations-Fummeleien,

01:12:13.101 --> 01:12:15.446
die man da anstelle dessen macht, ersetzen.

01:12:16.101 --> 01:12:22.101
Ja, oder auch so, wenn du vielleicht Suchergebnisse in Kachelform hast,

01:12:22.101 --> 01:12:25.101
und jemand ändert die Order,

01:12:25.790 --> 01:12:30.101
wonach das sortiert werden soll, dann könntest du quasi auch mit einer View-Transition dafür sorgen,

01:12:30.101 --> 01:12:34.221
eben die ganzen Kacheln dann weich an ihre neue Position fliegen.

01:12:34.379 --> 01:12:39.050
So Sachen sind halt auch möglich. Genau, der Browser weiß halt, es wird eine View-Transition

01:12:39.194 --> 01:12:44.875
und muss nicht irgendwie aus meinem Konvolut aus CSS und JavaScript erraten, welchen Optimierungspfad er jetzt beschreiten soll,

01:12:45.325 --> 01:12:46.172
sondern er weiß, was kommt.

01:12:47.061 --> 01:12:53.861
Ja. Und der, die einst, aber der Use-Case, der mich die hat wieder abschalten lassen,

01:12:53.861 --> 01:12:56.861
ist eigentlich, also in dem aktuellen Projekt,

01:12:57.064 --> 01:13:03.861
Zum einen führt das tatsächlich schon zu so leichten Verzögerungen in der Interaktion, weil dieses Screenshot-Machen

01:13:03.861 --> 01:13:06.688
dann doch ein bisschen Zeitaufwendig ist.

01:13:06.868 --> 01:13:13.861
Und das andere ist, dass es dann ein bisschen haarig wird, wenn du verschiedene Elemente hast,

01:13:14.034 --> 01:13:23.861
die vielleicht gleichzeitig sich ändern und die gleichzeitig weiche Animationen gebrauchen könnten,

01:13:23.861 --> 01:13:31.981
könnten, aber die nicht miteinander abgestimmt sind. Und du quasi nebeneinander zwei View-Transitions

01:13:31.981 --> 01:13:38.701
startest, die aber immer global für das ganze Dokument nur funktionieren. Also du kannst quasi

01:13:38.701 --> 01:13:41.701
quasi nicht sagen, die View-Transition...

01:13:43.119 --> 01:13:51.970
Soll oder das morphing soll sich quasi beschränken auf dieses quadrat in dem meine diese eine komponente a ist und dann könnte die komponente b ein ebensolches,

01:13:52.970 --> 01:13:58.970
morphing für ihr ihren quadranten starten sondern das geht halt immer nur für die gesamte seite,

01:13:59.970 --> 01:14:10.470
und da ist halt dann blöd in der regel ist ja immer eine die die irgendwie zuerst triggert und die nächste die dann triggert bringt halt alles irgendwie durcheinander.

01:14:10.530 --> 01:14:16.870
Und das hab ich halt hier so öfters mal, vor allem, wenn du eben wirklich so komponentenbasiert arbeitest

01:14:16.930 --> 01:14:19.710
und kein zentrales Orchestrierungstool hast.

01:14:20.272 --> 01:14:24.872
Mhm. Und selbst dann funktioniert's halt nicht, weil du könntest ja auch so was machen wie,

01:14:25.410 --> 01:14:31.110
hey, ich debounce das und warte ab, ob noch irgendwelche Kommandos von irgendeiner anderen Stelle kommen,

01:14:31.170 --> 01:14:33.470
und erst dann start ich die View Transition.

01:14:33.530 --> 01:14:37.350
Ja, oder ich mach irgendwie drei Klicks und es laufen drei Requests los,

01:14:37.350 --> 01:14:39.339
wiederkommen und dann soll das drei Transitions geben?

01:14:40.932 --> 01:14:44.930
Genau. Aber das funktioniert halt nicht. Weil selbst wenn du das debounced,

01:14:44.970 --> 01:14:52.190
dann kannst du die ersten zwei Requests zusammenfassen, aber du weißt nicht, dass dann ja noch ein dritter kommt,

01:14:52.230 --> 01:14:53.571
der aber zu langsam war,

01:14:54.138 --> 01:15:01.650
um quasi noch eben in diesem Debounce-Zeitraum, den du dir ausgewählt hast, rechtzeitig zu kommen.

01:15:01.690 --> 01:15:03.231
Und dann macht der das halt alles kaputt.

01:15:05.310 --> 01:15:05.778
Mhm. Ja.

01:15:07.372 --> 01:15:14.384
Gut, ähm, ich überleg jetzt grad, also wie gesagt, ich hab das jetzt selber noch nicht angefasst.

01:15:15.141 --> 01:15:21.022
Und tatsächlich war mein mentales Modell noch gar nicht bei dem angekommen, was du jetzt gesagt hast mit diesen ganzen

01:15:21.022 --> 01:15:23.622
Einzelkomponenten, dass man das machen könnte schon.

01:15:23.622 --> 01:15:30.534
In meinem Gehirn war View Transition bisher tatsächlich primär Transition von View as in, ich hab hier eine Multi-Page-Applikation,

01:15:31.039 --> 01:15:32.416
und klicke jetzt auf den nächsten Link.

01:15:32.749 --> 01:15:42.057
Ich glaube, da ist das immer noch am besten aufgehoben. Und das mache ich eben nicht.

01:15:42.841 --> 01:15:47.522
Und diese Multi-Page-Application-Transitions gibt es ja noch nicht, die kommen ja noch.

01:15:47.522 --> 01:15:51.122
Das heißt, da kann ich sie nicht nutzen in meinen Multi-Page-Projekten.

01:15:51.564 --> 01:15:57.122
Aber ich fand es eigentlich schon cool, auch irgendwie nur innerhalb der Seite für interaktive Elemente.

01:15:57.122 --> 01:16:00.122
Und da funktioniert es eigentlich gut, eben bis zu dem Moment, wo

01:16:00.467 --> 01:16:05.662
mehrere gleichzeitig vor sich hin arbeiten, dann fällt das Kartenhaus in sich zusammen

01:16:05.722 --> 01:16:10.325
und dann müsste man die in iFrames irgendwie sperren oder was weiß ich was machen.

01:16:10.721 --> 01:16:11.612
Ja.

01:16:12.035 --> 01:16:15.922
Siehst du denn grundsätzlich eine Möglichkeit, die API so weiterzuentwickeln,

01:16:15.982 --> 01:16:19.262
dass das irgendwann mal diesen Use-Case vernünftig abdeckt?

01:16:20.362 --> 01:16:22.822
Weil, wie gesagt, ich hab damit jetzt noch nicht viel gearbeitet,

01:16:22.882 --> 01:16:27.862
aber für mich klingt das jetzt mehr so nach, das ist aber ein ziemlich fundamentales Problem.

01:16:27.922 --> 01:16:28.536
Mhm.

01:16:29.607 --> 01:16:35.802
Also, vermag ich nichts zu beantworten. Also, irgendwie gefühlt, denke ich, könnte das schon gehen.

01:16:36.215 --> 01:16:41.422
Aber wahrscheinlich, also so, wie ich diese Entdeckung ja auch erst gemacht habe,

01:16:41.571 --> 01:16:46.722
nachdem ich die View-Transitions eingebaut habe, wird man dann wahrscheinlich wieder auf neue Probleme stoßen.

01:16:47.468 --> 01:16:56.471
Denke ich. So wie das halt häufig so ist. Joa. Joa, wird sich zeigen, wird sich zeigen.

01:16:56.542 --> 01:16:58.542
Aber das heißt...

01:16:59.909 --> 01:17:05.779
Mhm, okay. Ja, nee. Gibt Sinn. Ich werd das ausprobieren müssen und damit mal spielen müssen.

01:17:05.839 --> 01:17:09.119
Mittlerweile ist es ja weit genug in der Realität angekommen,

01:17:09.179 --> 01:17:14.871
dass man zumindest sagen kann, das geht erst mal nicht weg und bleibt da und, ähm, ja, wird sich zeigen.

01:17:15.276 --> 01:17:17.770
Immer noch nicht in Firefox, auch noch nicht ansatzweise, mh.

01:17:19.228 --> 01:17:24.299
Ja, ach, das machen die Leute von Igalia dann irgendwann. Äh, meinst du?

01:17:25.431 --> 01:17:33.101
Die kommen doch immer an und implementieren Dinge in, äh, in Engines, wo das Personal einfach nicht mehr die Kapazität hat.

01:17:34.928 --> 01:17:40.303
Was die implementieren sollten, wäre irgendwie so ein Cool im Mozilla-Hauptquartier. Mhm.

01:17:40.582 --> 01:17:46.622
Dass man da mal die ganzen Hosts rausschmeißt und da irgendwie Leute installiert, die einen vernünftigen Browser bauen.

01:17:47.018 --> 01:17:47.594
Ach, ist ja nix.

01:17:48.234 --> 01:17:52.839
Doch, super. Also, ich bin ja seitdem Chrome da seinen letzten DRM-Trip gestartet hat,

01:17:53.311 --> 01:17:54.799
hab ich gesagt, so fick die Scheiße.

01:17:54.859 --> 01:18:02.399
Ich bin auf Mobile-E mit dem Firefox unterwegs Desktop etabliert und das geht voll gut, da sind echt so, also das Beste, was ich sagen kann, ist mir fällt ja halt nicht auf.

01:18:03.402 --> 01:18:07.159
Also ich habe meinen Browser gewechselt und ich merke es halt nicht, wenn ich nicht gerade Zencaster aufmache.

01:18:07.159 --> 01:18:13.559
Und ein paar Sachen wie so deren Multiline, JavaScript, Playground da drin in der Konsole, finde ich besser als das, was Chrome da hat.

01:18:13.559 --> 01:18:19.363
Das ist total super, ist irre schnell, alle Extensions da, Blau Keks und immer mehr.

01:18:20.794 --> 01:18:24.164
Äh, ich weiß gar nicht, was ich sagen wollte. Du findest den gut.

01:18:24.224 --> 01:18:27.644
Ich find den gut, der fällt mir nicht negativ auf.

01:18:27.987 --> 01:18:33.364
Äh, und auch positiv jetzt nicht groß. Aber mein Desktop-Browser ist ja eh eine relativ unkomplizierte Sache.

01:18:33.424 --> 01:18:35.464
Ich hab drei Extensions, und das war's.

01:18:35.524 --> 01:18:38.964
Auf Mobile fällt er mir positiv auf. Aber trotzdem ist das ja so,

01:18:39.024 --> 01:18:42.204
dass immer, wenn man irgendwie da von Mozilla irgendwelche ...

01:18:42.264 --> 01:18:44.284
Die machen halt regelmäßig ihre Stunts.

01:18:45.416 --> 01:18:48.464
Und auch zum Beispiel Sachen wie dieses AI-Ding da in MDN, wo ich so denke ...

01:18:48.464 --> 01:18:54.344
Nee, ich hab, also jetzt wo du's sagst, erinnere ich mich, dass da irgendwas war, aber ich hab das nicht verfolgt.

01:18:54.384 --> 01:18:55.787
Ich hab keine Ahnung, was die da machen.

01:18:56.695 --> 01:18:58.804
Ja, also man kann ja so was bauen, testweise.

01:18:59.999 --> 01:19:02.464
Und man kann das ja irgendwie mal so sagen, hier, hast du versucht, ne?

01:19:02.504 --> 01:19:05.725
Ist ja auch ein Beta-Batch dran, so schön Web 2.0 ist ja völlig gut.

01:19:06.084 --> 01:19:09.464
Aber wir wissen ja, wie im Moment der Technik mit den Dingern ist.

01:19:09.504 --> 01:19:14.084
Du musst nicht viel Arbeit da reinstecken, um die dazu zu bringen, dass sie Käse erzählen.

01:19:14.124 --> 01:19:17.344
Und was machen die da? den du was fragen kannst, oder wie?

01:19:17.536 --> 01:19:19.903
Ja, genau, synthetisches Stackoverflow ist das Gleichsam.

01:19:21.299 --> 01:19:24.384
Ah ja. Da fragst du halt den, und dann sagt er dir irgendwie so,

01:19:24.424 --> 01:19:28.969
ja, du kannst mit dem Intersection Observer natürlich die Notelist um drei Elemente kürzen, so geht's.

01:19:29.944 --> 01:19:37.104
Mhm. Okay. Was halt so ein ganz klassischer Move ist, wo halt die richtige Antwort wäre, die Frage ist falsch,

01:19:37.144 --> 01:19:41.344
aber das ist halt nicht das, was die AI der Technik heutzutage beantworten kann.

01:19:41.473 --> 01:19:45.624
Ist ja okay, muss man ja ausprobieren, um festzustellen, dass es nicht funktioniert.

01:19:45.684 --> 01:19:51.339
Aber wenn dann halt wirklich Leute bei GitHub, kannst du ja bei MDN machen, sagen, hier, Bug Report,

01:19:51.582 --> 01:19:56.372
ich hab diese Frage gestellt, da kam Blödsinn raus, hallo, hier, mach mal was.

01:19:57.479 --> 01:20:01.044
Und dann die, sagen wir mal, ähm, Pro-Fraktion von diesem Feature,

01:20:01.104 --> 01:20:02.313
dass da sozusagen ...

01:20:02.984 --> 01:20:08.604
Dass da erhebliche Ressourcen reinverschwenden, um zu rechtfertigen, dass es ja zwingend nötig ist,

01:20:08.664 --> 01:20:10.757
dass da KI in MDN mit eingebaut wird.

01:20:11.090 --> 01:20:11.549
Mhm.

01:20:12.692 --> 01:20:16.762
Wo ich irgendwie so sagen würde, Leadership bei einer Firma,

01:20:16.762 --> 01:20:20.435
die ja schon so einen technischen Anstrich hat und wo so Produkte wie Webbrowser,

01:20:21.056 --> 01:20:26.052
oder von mir aus auch sowas wie Pocket und Konsorten ja schon irgendwie echt so Nerd-Unternehmungen sind,

01:20:26.511 --> 01:20:29.562
die sollten doch in der Lage zu erkennen, dass so ein Experiment da nicht hinhaut

01:20:29.562 --> 01:20:31.661
und dann auch relativ schnell den Stecker ziehen, aber der ist immer noch da.

01:20:32.524 --> 01:20:41.752
Ja, wobei ich glaube, ist MDN denn überhaupt noch Mutze da? Oder ist das nicht eher jetzt so ein von allen betriebenes Dings mittlerweile?

01:20:41.950 --> 01:20:46.217
Habt ihr mir dann alle MDN-Mitarbeiter bis auf einen ...

01:20:47.073 --> 01:20:52.262
Ja, gekündigt bei Mozilla und dann ... Warte mal, dann ist ja vielleicht das das,

01:20:52.322 --> 01:20:54.102
worüber ich mich aufregen sollte.

01:20:54.162 --> 01:20:56.462
Ja, dann solltest du dich darüber aufregen.

01:20:56.522 --> 01:20:57.749
Ja, ja, nee, das war schon schade.

01:20:58.362 --> 01:21:01.440
Redirekten wir das dann. Ja, ist nicht schade, ist halt irgendwie so ...

01:21:02.082 --> 01:21:05.662
Ich meine, okay, ich hab ja den Browser nicht ohne Grund gewechselt,

01:21:05.722 --> 01:21:11.342
weil immerhin wollen sie mir jetzt hier mit Mozilla-Stand jetzt nicht irgendwie DRM für Webseiten reinwirken.

01:21:11.342 --> 01:21:15.342
Trotzdem ist laut Mission Statement Mozilla schon an einen höheren Standard zu binden,

01:21:15.342 --> 01:21:19.342
als jetzt eine ganz normale Firma, wie Microsoft, wie Google.

01:21:20.453 --> 01:21:25.342
Da darf man mehr erwarten. Und wenn dann zwar objektiv mehr geliefert wird, als von der Konkurrenz,

01:21:25.342 --> 01:21:28.789
aber die an ihrem eigenen Anspruch scheitern, dann müssen wir trotzdem auf den Deckel kriegen.

01:21:29.680 --> 01:21:32.984
Zu Recht. Deswegen benutze ich den Browser und schimpfe, aber ich meine es gut.

01:21:34.533 --> 01:21:34.820
Ja.

01:21:36.549 --> 01:21:42.158
Ja, dann. Wir haben jetzt schon über eine Stunde aufgenommen. und du hast Termine.

01:21:42.508 --> 01:21:46.862
Die Frage an dich wäre, hast du Lust, noch mal ein Part 2 zu machen,

01:21:46.902 --> 01:21:49.566
wo wir uns noch die verbleibenden Sachen angucken?

01:21:49.662 --> 01:21:51.022
Weil wir sind jetzt ...

01:21:51.457 --> 01:21:54.337
Also, so ein paar seh ich noch, die ganz nett wären. Mhm.

01:21:55.273 --> 01:21:59.942
Also, nicht im Sinne von ... hier, wie du immer nett definierst, sondern ...

01:22:01.251 --> 01:22:06.742
Besprechenswert. Genau. Nee, das machen wir auf jeden Fall. Wir machen auf jeden Fall einen Teil zwei,

01:22:06.782 --> 01:22:12.662
weil ich hab hier schon mal sehr viel mitgenommen. Die werden endlos lang und werden viele, viele Links enthalten.

01:22:12.702 --> 01:22:18.902
Cool. Ja, dann machen wir das. Ich freu mich drauf. Und, äh, genau, wir bedanken uns fürs Zuhören.

01:22:19.669 --> 01:22:22.883
Hoffen, dass der Teil zwei nicht allzu lang auf sich warten lässt.

01:22:22.964 --> 01:22:27.709
Und ich bedanke mich auch bei dir für den tollen Austausch.

01:22:28.060 --> 01:22:33.389
Ich bedanke mich bei dir. Ich hab wieder viel mitgenommen. Dann bis zum nächsten Mal. Macht's gut. Tschüß!

01:22:34.000 --> 01:22:56.560
Music.