WEBVTT

00:00.000 --> 00:06.400
Ja wie bei CSS mit den Z-Indexen, also wenn du quasi so ein Stacking-Kontext bildest,

00:06.400 --> 00:09.840
dann kannst du da drin ja Z-Index eine Million reinschreiben.

00:09.840 --> 00:13.680
Ja man muss ja auch nur in die HGM2-Spezifikationen reingucken, dann weiß man sofort.

00:13.680 --> 00:19.240
Ich war noch nie an diesem Punkt, dass ich gedacht habe, auch nee, jetzt war ja meine

00:19.240 --> 00:23.600
eigene Error-Klasse, weil sonst komme ich hier mit meinen JavaScript-Errors im Fronten

00:23.600 --> 00:24.600
gar nicht klar.

00:24.600 --> 00:33.120
Find ich jetzt ein bisschen kompliziert ausgedrückt, aber kann man machen, ja.

00:33.120 --> 00:36.360
Diese Revision von WorkingDraft wird euch präsentiert von Mitwald.

00:36.360 --> 00:39.240
Mitwald ist der Hoster für Agenturen und Freelancer.

00:39.240 --> 00:43.280
Solltet ihr mehr als ein alzendes Webprojekt zu betreuen haben, dann könnte Mitwald euer

00:43.280 --> 00:44.280
Gamechanger sein.

00:44.280 --> 00:48.080
Ich erinnere mich damit grausen an meine eigene Freelancer-Vergangenheit, als ich für zehn

00:48.080 --> 00:51.800
Kunden bei 20 verschiedenen Hostern mit 30 Lockins zu jogglieren hatte.

00:51.800 --> 00:56.640
Bei Mitwald hingegen ein Lockin für alle Projekte.

00:56.640 --> 01:01.720
Wahlweise für den besucherbasierten Agenturserver oder den nördlich selbst konfigurierten Space-Server.

01:01.720 --> 01:06.360
Mit allen Features, die ihr euch nur wünschen könnt, formen Shopsystem-Installer über SSL-Zertifikate

01:06.360 --> 01:08.920
bis hin zum ausgefuchsten Rechte- und Rollensystem.

01:08.920 --> 01:12.080
Ihr wisst schon für das Management eurer zahllosen Projekte unter einem Dach.

01:12.080 --> 01:17.440
CO2-neutral und DSGVO-konform und solltest man haken und ihr den Support anrufen, dann

01:17.440 --> 01:22.440
kriegt ihr echte Nerds-Ansruhe, 24 7 an 365 Tagen im Jahr.

01:22.440 --> 01:27.960
Das alles könnt ihr haben, wenn ihr auf mitwald.de.slashworkingdraft vorbeischaut.

01:27.960 --> 01:33.200
Das schreibt sich miettwald.de.slashworkingdraft.

01:33.200 --> 01:37.080
Alle Infos zur Mitwald findet ihr natürlich auch in den Show-Notes zu dieser Revision.

01:37.080 --> 01:48.160
Wir danken mitwald für die Unterstützung von dieser Revision von WorkingDraft.

02:07.080 --> 02:18.280
Wir sind heute zu dritt und zwar alle aus dem Team, da wäre zum einen der Hans.

02:18.280 --> 02:19.280
Hallo zusammen.

02:19.280 --> 02:22.000
Dann haben wir den Peter.

02:22.000 --> 02:23.000
Moin moin.

02:23.000 --> 02:29.400
Und ich bin der Shep und eigentlich war heute ein Gast geplant, der ist aber krankheitsbedingt

02:29.400 --> 02:31.480
ausgefallen, relativ kurzfristig.

02:31.480 --> 02:37.040
Und was machen wir dann immer, wir schmeißen das Glücksrat an.

02:37.040 --> 02:40.640
Das Webtechnologie Glücksrat und das haben wir auch wieder gemacht.

02:40.640 --> 02:46.240
Also fuhr der Peter ja immer schön in der HTML5-Spec rumgescrollt, aber da fehlten uns

02:46.240 --> 02:52.560
ja dann ein paar Aspekte des Webs, die halt da nicht als Teil von HTML5 verzeichnet sind.

02:52.560 --> 03:02.520
Und genau jetzt speist sich unser neues Tool aus den MDN-Artikeln und sucht sich da entweder

03:02.520 --> 03:10.240
HTML-Elemente oder CSS-Features oder Browser-APIs raus, findet ihr auch, könnt ihr alle gucken

03:10.240 --> 03:16.040
unter workingdraft.e slash Glücksrat, genau und da gucken wir jetzt drauf, soll das schon

03:16.040 --> 03:17.200
per Websocket verbunden.

03:17.200 --> 03:23.640
Da können wir uns dann zufällig irgendwelche Sachen raus auswerfen lassen.

03:23.640 --> 03:31.120
Ich glaube, irgendwer von euch hat schon gedruckt, weil hier ist eben das erste Ding schon aufgeploppt.

03:31.120 --> 03:35.880
Ich weiß nicht, ich habe keinelei Verantwortung dafür, dass wir jetzt mit dem Thema konfrontiert

03:35.880 --> 03:36.880
sind.

03:36.880 --> 03:40.640
Ne, kann ich auch nicht zu sagen, ich habe noch nicht mal was angezeigt.

03:40.640 --> 03:42.440
Was ist es denn, Shep?

03:42.440 --> 03:51.600
Das ist aus der API-Ecke Selection und dann ist kollepst und da habe ich tatsächlich

03:51.600 --> 03:55.200
auch gerade höchstens eine Ahnung, was es sein könnte.

03:55.200 --> 04:00.240
Wollte aber sagen, wenn ihr zwei das nicht gedruckt habt, dann ist wahrscheinlich irgendwer anders

04:00.240 --> 04:03.240
gerade auf der Seite und drückt, was auch vollkommen ordentlich ist.

04:03.240 --> 04:07.640
So, die sind nämlich schlau, die Leute, die lesen die Tweets, sehen, dass wir gerade so

04:07.640 --> 04:11.240
was aufnehmen und dann drücken sie mal für uns und wollen nämlich mal ein Thema.

04:11.240 --> 04:14.240
Ja, die wollen uns mal hier bumpen.

04:14.240 --> 04:15.240
Genau.

04:15.240 --> 04:22.520
Ja, aber das ist ein spannendes Thema, also Selection.isCollepst.

04:22.520 --> 04:28.280
Read only property returns a boolean value, which indicates whether or not there is currently

04:28.280 --> 04:30.400
any text selected.

04:30.400 --> 04:38.760
Aha, no text is selected and the selection start and end positions are the same position in

04:38.760 --> 04:39.760
the content.

04:39.760 --> 04:42.200
Also, wenn man so stellt, ist jetzt...

04:42.200 --> 04:44.400
Okay, aber was hat das denn mit isCollepst zu tun?

04:44.400 --> 04:48.160
Naja, sie ist ja kollepst, wenn sie nix selektiert hat.

04:48.160 --> 04:54.840
Also, Start und Endpunkt, gleiche Koordinaten, ist ja gleich bedeutend, nichts ist ausgewählt,

04:54.840 --> 04:57.720
ist gleich bedeutend mit, dass was vorher ausgewählt war, ist jetzt nicht mehr ausgewählt, weil

04:57.720 --> 04:59.080
die Koordinaten zusammengefallen sind.

04:59.080 --> 05:07.040
Okay, hm, finde ich jetzt ein bisschen kompliziert ausgedrückt, aber kann man machen, ja.

05:07.040 --> 05:14.200
Habt ihr denn schon mal mit dieser nativen Selection API was getan?

05:14.200 --> 05:22.400
Also, ich habe damit schon mal gearbeitet, ja, ich überlege gerade, was ich damit gemacht

05:22.400 --> 05:23.400
habe.

05:23.400 --> 05:31.320
Tja, wenn ich das jetzt noch wüsste, ich glaube, ich glaube genau, um irgendwie HTML

05:31.320 --> 05:36.720
ins Clipboard zu kopieren, musste ich, also da musste ich, glaube ich, in eine Textarea

05:36.720 --> 05:41.720
oder irgendwie sowas in der Art, musste ich dann das HTML rein donnern, das ich haben

05:41.720 --> 05:45.280
wollte, dann konnte ich irgendwie selektieren und kopieren, ich glaube, irgendwie so in

05:45.280 --> 05:46.280
die Richtung ging es.

05:46.280 --> 05:49.480
Habe ich all das, aber glaube ich, nicht benutzt.

05:49.480 --> 05:53.560
Nee, das brauchst du ja dafür auch nicht, dann müsstest du ja im Prinzip plus sozusagen

05:53.560 --> 06:01.920
Textarea nehmen von Position 0 bis Value.length selektieren und dann kopieren, das ist ja

06:01.920 --> 06:06.760
wahrscheinlich deutlich gewesen vor der modernen Clipboard-API, die ja einfacher nicht sein

06:06.760 --> 06:08.760
könnte, wo man ja einfach irgendwie beliebigen Text reinbeben kann.

06:08.760 --> 06:17.360
Ja, wollte ich auch gerade sagen, also diese Clipboard-API, ich erinnere mich aber auch

06:17.360 --> 06:23.760
an irgendwie sowas, was du sagst, Chef, dass man eine Selection machen musste, um erstmal

06:23.760 --> 06:30.960
das kopierend zu können, aber ich weiß auch nicht mehr, in welchem Kontext, ein anderer

06:30.960 --> 06:35.200
Kontext, der mir dafür noch einfällt, ist halt das, was zum Beispiel bei jetzt einer

06:35.200 --> 06:40.680
Seite wie Medium.com passiert, wenn man was selektiert, dass man dann das Ganze irgendwie

06:40.680 --> 06:47.840
zitieren kann oder diesen Abschnitt twittern kann oder ähnliches, das kenne ich jetzt

06:47.840 --> 06:53.880
so als Use Case dafür, ich weiß nicht, was euch sonst noch so für Use Cases in dem Kontext

06:53.880 --> 06:54.880
einfallen.

06:54.880 --> 07:02.800
Also für jetzt die Selection, ah gut, so wie sie ist, wahrscheinlich halt wenig, also

07:02.800 --> 07:06.400
du brauchst es sowas halt natürlich, also generell den Umgang mit der Selection, wenn

07:06.400 --> 07:12.280
du irgendwie so ein Visivik-Editor bauen möchtest und irgendwie die aktuelle Selection soll

07:12.280 --> 07:15.640
irgendwie dann bolt werden und du musst ja gegebenenfalls, wenn du zum Beispiel so was

07:15.640 --> 07:19.720
machen willst, wie den Bolt-Button aktivieren oder deaktivieren, wenn nichts selektiert

07:19.720 --> 07:24.080
ist, dann würdest du natürlich gucken, aha, ist die aktuelle Selection kollepst und wenn

07:24.080 --> 07:26.040
sie das ist, dann machst du den Button disabled.

07:26.040 --> 07:36.800
Ja, stimmt für sowas könnte man das gebrauchen auf jeden Fall, ja, ich hab zum Beispiel

07:36.800 --> 07:39.960
also das letzte Mal, als ich mit einer mit einer Selection API, wenn auch nicht mit der

07:39.960 --> 07:45.840
handiert habe, war, dass ich mit der vom CodeMirror gespielt habe, um halt genauso was zu machen,

07:45.840 --> 07:50.240
so Formatierung in halt irgendwie so einer Textbox und da gibt es halt auch eine Selection

07:50.240 --> 07:54.840
API, aber halt eben eine Funktionale und nicht die Imperative DOM API, aber so die gleiche

07:54.840 --> 07:58.760
Idee und die gleichen Use Cases dürfen das ja schon sein.

07:58.760 --> 08:05.600
Ja, stimmt, für so ein Use Case ist es eigentlich interessant, aber dann halt auch in der Text

08:05.600 --> 08:13.720
Area, außerhalb der Text Area, ja, hat man das Beispiel mit Medium.com, ansonsten fällt

08:13.720 --> 08:19.160
mir da jetzt auch nicht so der starke Use Case an, ich hab's zumindest noch nirgendswo

08:19.160 --> 08:20.160
verwendet.

08:20.160 --> 08:26.360
Ja, gut so, könnte man sagen, fällt unter die Gnade der späten Geburt, dass du nicht

08:26.360 --> 08:31.640
wie der Chef seinerzeit damit Exec Command und der Selection irgendwie da copy-pasten

08:31.640 --> 08:32.640
musstest.

08:32.640 --> 08:39.520
Stimmt, Exec Command war das, das waren noch Zeiten, also nicht gute unbedingt.

08:39.520 --> 08:42.560
Ich wollte's grad sagen, kannst du vielleicht die Qualität dieser Zeichen noch herausstellen?

08:42.560 --> 08:45.400
Ja, es waren Zeiten, das kann man sich ja sagen.

08:45.400 --> 08:50.000
Ja, nee, nee, dann schnell, schnell weiter, würde ich sagen.

08:50.000 --> 08:51.000
Genau.

08:51.000 --> 08:52.000
Kann nur besser werden.

08:52.000 --> 08:53.000
Auf geht's.

08:53.000 --> 08:54.000
Wer drückt?

08:54.000 --> 08:55.000
Command.

08:55.000 --> 09:01.560
Ich drück mal drauf, ich hoffe, es funktioniert, oh ja, es funktioniert, als hätten wir nicht

09:01.560 --> 09:05.960
gerade erst das Thema angesprochen, Peter, du nanntest es schon, du möchtest in einer

09:05.960 --> 09:14.160
Visivik-Editor-Area etwas Bold machen, das ganze kannst du dann ja in html auch mit dem

09:14.160 --> 09:24.400
Bold-Element, also B-Element, darstellen und genau das ist es, was wir jetzt, aha, da

09:24.400 --> 09:28.400
kommt die Diskussion schon zu, ich wollte grad, ich wollte grad schon fragen, so, das war

09:28.400 --> 09:31.640
jetzt irgendwie jetzt nicht so der, nicht so der erste Satz aus den html-Spezifikationen,

09:31.640 --> 09:36.520
den ich jetzt so zitieren würde, so direkt, aber sag doch mal, Hans, was macht das B-Element?

09:36.520 --> 09:45.080
Ja, also klassisch verwendet man ja irgendwie das B-Element, um etwas in Fett dargestellt

09:45.080 --> 09:46.080
zu bekommen.

09:46.080 --> 09:51.880
Allerdings, wenn ich mich da richtig erinnere, gab's mit html 5 ja diesen Change beim B-Element,

09:51.880 --> 09:57.560
dass es nicht mehr darum ging, wie sieht das Ganze aus, weil man hat natürlich ja das

09:57.560 --> 10:02.920
Styling komplett weggebracht von dem, was in html passiert und das B war eher dafür

10:02.920 --> 10:12.120
da, etwas anders darzustellen, als es der Fleece-Text tut, das default Styling war

10:12.120 --> 10:19.960
halt das Fundweight Bold, allerdings wollte man damit ermöglichen, einen Text anders

10:19.960 --> 10:26.960
einfach darzustellen, ohne dem semantisch eine andere Meinung zu geben, im Vergleich

10:26.960 --> 10:28.960
zu Strong.

10:28.960 --> 10:37.880
Strong tut ja auch das gleiche visuell, stellt den Text Fett dar und hat aber dazu inzufügen

10:37.880 --> 10:45.080
noch die semantische Meinung, hier möchte man etwas betonen, so meine ich mich, wäre

10:45.080 --> 10:50.440
da die Unterscheidung zwischen dem B-Element und dem Strong-Element, wenn ich das richtig

10:50.440 --> 10:51.440
erinnere.

10:51.440 --> 10:55.600
Also für das kann man es nicht erklären, würde ich sagen.

10:55.600 --> 11:00.600
Ein Punkt, dem mir da natürlich auch wieder direkt ins Gehirn kommt, ist das Gleiche

11:00.600 --> 11:08.560
nämlich mit dem I für Italic und M für Emphasis, also das Element, grundsätzlich ist es da

11:08.560 --> 11:16.880
ja auch so, Emphasis ist wieder die semantische Meinung im Element, man möchte hier etwas hervorheben,

11:16.880 --> 11:23.120
das ist halt dargestellt dann zufällig durch Italic, könnte aber auch Customized werden

11:23.120 --> 11:30.600
vom Styling her und beim I ist es so, man möchte ohne semantische Meinung einfach nur

11:30.600 --> 11:35.880
eine visuelle Änderung herbeiführen, theoretisch könnte man da auch ja das B-Element verwenden,

11:35.880 --> 11:41.720
die müssten dann ja eigentlich synonym verwendet werden können, ist das richtig?

11:41.720 --> 11:47.800
Das ist fast, das wäre halt meine Bonusfrage gewesen, also Lautspezifikation ist die Idee,

11:47.800 --> 11:51.960
dass die beide ja das Gleiche machen, die setzen den Text halt eben einfach ab, ohne

11:51.960 --> 11:56.160
den jetzt irgendwie besonders auf oder abzuwerten und die Unterscheidung zwischen den beiden

11:56.160 --> 12:00.200
ist tatsächlich mehr so, wie würdest du es denn in Print machen, wie würdest du es durch

12:00.200 --> 12:03.280
diesen Text absetzen, also zum Beispiel du hast irgendwie einen Einschub in einer anderen

12:03.280 --> 12:08.160
Sprache, das würdest du vielleicht eher Italic machen oder das ist jetzt gerade das Produkt

12:08.160 --> 12:14.160
über das du redest, das würdest du vielleicht eher Bold machen und so macht man das dann,

12:14.160 --> 12:18.600
das ist so die semantische Idee dahinter, Bösezungen und ich würden behaupten, die haben einfach

12:18.600 --> 12:21.960
nur eine Ausrede gesucht, irgendwie diese Elemente da drin zu behalten und irgendwie denen einen

12:21.960 --> 12:26.680
Sinn zu geben, irgendwie noch so, irgendwie so noch eine Verwendung nach im Prinzip Rente

12:26.680 --> 12:31.120
noch zu ermöglichen und dann hat man halt die genommen, aber ist okay, ich mein ein bisschen

12:31.120 --> 12:33.600
besser als ein Spen mit Style-Attribut ist es halt dann doch schon.

12:33.600 --> 12:41.080
Das in jedem Fall, was ich mich jetzt allerdings frage, ne, einführend haben wir gesagt, der

12:41.080 --> 12:48.440
Use Case innerhalb eines Visivik-Editors, ich habe noch keinen Editor gesehen, der unterscheidet

12:48.440 --> 12:55.440
zwischen Bold und Strong, du hast halt diesen einen Button und das passiert dann halt mit

12:55.440 --> 13:02.520
dem Element gleich für Italic und Emphasis, aus meiner Warte gibt es also keinen Unterschied

13:02.520 --> 13:08.880
sozusagen, was verwenden die denn dann wohl, ist es eher das B oder ist es eher das Strong?

13:08.880 --> 13:18.360
Na, ich denke die werden wahrscheinlich intern, also die werden wahrscheinlich einen Strong

13:18.360 --> 13:24.400
auszeichnen, die Editoren, wenn man das eben erstmalig macht, aber werden wahrscheinlich

13:24.400 --> 13:29.480
genauso einen B entgegennehmen können, das ist mal meine Vermutung.

13:29.480 --> 13:39.520
Entgegennehmen können, also sozusagen, wenn man halt einen Text rein füttert, dann werden

13:39.520 --> 13:46.200
die Element, da funktioniert es schon, weil das ja eh nur HTML-Darstellung, ja oder wahrscheinlich

13:46.200 --> 13:55.200
machen es die meisten tatsächlich eher so wie Peter als Anti-Use-Case oder als Gegenthema

13:55.200 --> 13:58.280
sozusagen dargestellt hat, nämlich das Span mit einer Klasse.

13:58.280 --> 14:03.080
Ja, es ist halt eben schwierig sich zu entscheiden, also du hast im Prinzip nur einen Knopf und

14:03.080 --> 14:06.640
dieser eine Knopf ist ja der für die meisten Leute einfach nur so, das soll jetzt Fett

14:06.640 --> 14:10.840
sein und du kommunizierst damit ja keine Intention, also ist das jetzt Fett-Quar-Konvention

14:10.840 --> 14:16.040
oder Quar-Aufwertung und ich würde mal behaupten, dass da so eine Kosten-Utsen-Abrechnung einfach

14:16.040 --> 14:20.760
die Verkomplizierung des User-Interface durch, du hast die Wahl zwischen diesen beiden Varianten,

14:20.760 --> 14:23.400
dann einfach nicht wert ist in der Endabrechnung, dann nimmt man halt einfach irgendwas.

14:23.400 --> 14:31.400
Ja, vor allem was hat es da, also die semantische Bedeutung, wie spiegelt die sich denn wieder,

14:31.400 --> 14:38.000
also in der Darstellung klar, aber davon wollen wir ja gerade weg und dann ist es im Screenreader,

14:38.000 --> 14:43.680
wird das besonders hervorgehoben beispielsweise, nimmt eine Suchmaschine, das anders war, I

14:43.680 --> 14:44.680
don't know.

14:44.680 --> 14:48.400
Weil, kannst du sicherlich auch nicht so ohne weiteres sagen, kommt ja auch drauf an, ob

14:48.400 --> 14:53.400
das jetzt irgendwie so ein Old-School-Indexer ist oder irgendwie eine AI mit Semantik-Idee

14:53.400 --> 14:59.140
dahinter oder, oder, oder, die wichtigere Frage ist dann, glaube ich, mehr so wirklich

14:59.140 --> 15:03.200
von der produzierenden Seite her, interessiert diese Unterscheidung die Person, die da jetzt

15:03.200 --> 15:06.920
am Ende diesen Button klickt oder nicht klickt überhaupt und da ist die Antwort wahrscheinlich

15:06.920 --> 15:07.920
meistens, ne.

15:07.920 --> 15:15.080
Wahrscheinlich, ja, das stimmt, aber die produzierende Seite ist ja manchmal auch, sind ja auch

15:15.080 --> 15:18.760
manchmal Leute wie wir jetzt oder wie unsere Hörerinnen und Hörer.

15:18.760 --> 15:25.440
Schreibt ihr denn, wenn ihr dann mal HTML oder irgendwelche Texte schreibt, weil das

15:25.440 --> 15:30.840
gerade nicht aus dem CMS kommt, schreibt ihr dann irgendwie mal einen Bold oder einen

15:30.840 --> 15:35.880
Strong-Tag, also verwendet ihr die oder macht ihr dann lieber alles über Styles?

15:35.880 --> 15:44.600
Also ich schreib meine Texte meistens in Markdown und das wandelt das dann eben in, ja, gute

15:44.600 --> 15:45.600
Frage.

15:45.600 --> 15:47.480
Ich glaube Strong-Um oder so, würde ich jetzt mal schätzen.

15:47.480 --> 15:50.600
Das könntest du dir im Prinzip ja auch aussuchen, weil du ja dann auch kompetent genug wärst

15:50.600 --> 15:53.320
den Pasa gegen irgendwas auszutauschen oder irgendwelche Optionen zu setten, die dann

15:53.320 --> 15:57.200
dieses hier ein solches ausgeben oder du kannst ja auch Inline-HTML schreiben, wenn es dir

15:57.200 --> 15:59.320
mal ganz wichtig ist.

15:59.320 --> 16:05.480
Ja, genau, aber also tendenziell nutze ich eher Strong.

16:05.480 --> 16:10.520
Ich habe wenig Use-Cases, wo ich, also ich kann mir vielleicht vorstellen in so einem,

16:10.520 --> 16:16.160
vielleicht so einem Interviewablauf, dass man dann irgendwie quasi derjenige, der die

16:16.160 --> 16:21.640
Fragen stellt, der wird dann einmal fett geduckt und dann kommt so dessen Fragestellung und

16:21.640 --> 16:27.240
dann der Name des Interviewen in, auch das wär dann, da würde ich vielleicht ein Bold

16:27.240 --> 16:28.240
setzen, so.

16:28.240 --> 16:31.520
Da würdest du auch eine Definitionsliste verwenden, oder?

16:31.520 --> 16:38.640
Das auch, genau, das wär auch nicht schlecht, aber dennoch auch in dieser Liste würde ich

16:38.640 --> 16:41.720
glaube ich dann Bold, könnte ich mir vorstellen.

16:41.720 --> 16:45.160
Also da fände ich jetzt, glaube ich, strong, fehl am Platze.

16:45.160 --> 16:49.840
Glaub ich auch, also ich entziehe mich dem Problem ganz gerne, letzter Zeit, wenn ich

16:49.840 --> 16:54.960
so sage so, ich will im Prinzip ja ausdrücken, das soll hervorgehoben werden und ich gehe

16:54.960 --> 16:58.560
davon aus, dass die auslösenden Personen diese Unterscheidung gar nicht machen können

16:58.560 --> 17:04.080
oder wollen, dann nehme ich halt einfach ein formatiertes Markelement tatsächlich.

17:04.080 --> 17:08.880
So, der Text ist markiert und irgendwie gestylt, aber jetzt ohne mich in diese Diskussion hinein

17:08.880 --> 17:13.440
zu begeben, gebe ich den Leuten, glaube ich, damit am ehesten den Ausdruck, den sie damit

17:13.440 --> 17:14.440
machen wollen.

17:14.440 --> 17:15.760
Nämlich, hey, das ist jetzt irgendwie anders.

17:15.760 --> 17:16.760
Ja.

17:16.760 --> 17:26.920
Ja, das ist eine gute Idee, benutzt man eh viel zu wenig das Markelement.

17:26.920 --> 17:27.920
Das stimmt.

17:27.920 --> 17:36.440
Darf ich vielleicht hier so kurz rein sneaken, weil mir fällt gerade noch ein Element ein,

17:36.440 --> 17:44.920
was man auch super wenig oder was ich zumindest super wenig benutze, eigentlich nie das KBD-Element

17:44.920 --> 17:51.160
heißt es, glaube ich, mit dem man ein Keyboard-Charakter, glaube ich, darstellt.

17:51.160 --> 17:55.840
Ist das schon mal untergekommen und wofür habt ihr es verwendet?

17:55.840 --> 18:02.520
Das sind zwei verschiedene Fragen untergekommen beim Durchscroll durch die Spezifikation Ja,

18:02.520 --> 18:03.520
verwendet ich, glaube noch nicht.

18:03.520 --> 18:11.520
Also es würde natürlich Sinn machen, wenn man irgendwie so eine, vielleicht eine Hilfe

18:11.520 --> 18:17.680
anzeigt und sagt so, hier, du kannst diesen Menüpunkt vielleicht auch aufrufen, indem

18:17.680 --> 18:24.280
du folgende Tasten drückst, da würde das sicherlich Sinn machen, aber da ich diesen

18:24.280 --> 18:29.560
Use Case eigentlich nie habe, habe ich vielleicht auch dieses Element noch nicht benutzt.

18:29.560 --> 18:30.560
Ich verkenne es.

18:30.560 --> 18:36.640
Tue ich es eigentlich auch eher aus so Dingen wie, es gab, also ja, dass man mal drüber

18:36.640 --> 18:40.960
gestolpert ist, dass man mal so eine Liste aller HTML-Elemente sich angeguckt hat und

18:40.960 --> 18:42.720
da tauchtet es halt eben drin auf.

18:42.720 --> 18:50.680
Genau, aber das sind ja auch so sehr alte Elemente, so wie so manche deprecatete Elemente,

18:50.680 --> 18:56.880
die dann quasi so eine Art Terminal-Output darstellen sollen, also mein XMP-Element ist

18:56.880 --> 19:05.240
ja auch so eins, das so gerne mag, das soll halt quasi auch Terminal-Ausgaben im Browser

19:05.240 --> 19:10.360
rendern und ich glaube so aus der Zeit stammen da so einige Elemente.

19:10.360 --> 19:17.520
Ja, aber es ist halt nicht deprecated, anders als manche andere Elemente ist es halt nicht

19:17.520 --> 19:18.520
deprecated.

19:18.520 --> 19:25.000
Und ich glaube halt so dieser Use Case, dass man es irgendwie auf einer Hilfeseite vielleicht

19:25.000 --> 19:31.360
auch darstellt, verwende folgende Tastenkombinationen, dafür ist es vielleicht gut, aber es ist

19:31.360 --> 19:38.280
schon erstaunlich, wie wenig häufig man das Elemente verwendet dafür, dass es halt eigentlich

19:38.280 --> 19:43.960
die gleiche Wertigkeit hat wie so ein Image Tag, also IMG Tag.

19:43.960 --> 19:47.880
Ja, gut, aber ich meine, es kommt halt eben einfach aus einer ganz anderen Zeit.

19:47.880 --> 19:51.760
Also Chef hatten und ich hatten ja kürzlich auch mal über Media Queries gesprochen,

19:51.760 --> 19:57.320
wo es halt auch so Mediatypes gab, so nach dem Motto Handheld und TV, wo halt irgendwie

19:57.320 --> 20:01.520
so diese Geräteklassen so homogen waren in ihren Capabilities, dass das klar war und

20:01.520 --> 20:06.040
naja, ich will schon die ganze Zeit so sagen, ja, wir reden hier von Tastenkombinationen,

20:06.040 --> 20:10.760
aber demnächst wird irgendwie die Touchscreen-Aktion hier kommen und uns alle canceln, weil die

20:10.760 --> 20:14.720
haben gar keine Tasten und was ist denn mit denen, aber das war halt früher einfach nicht

20:14.720 --> 20:19.240
so ein Ding und da waren halt so Dinge wie Tastenshortcuts einfach auch ein viel, da

20:19.240 --> 20:23.040
gab es halt einen viel größeren Use Case für einfach, weil man mehr davon ausgehen

20:23.040 --> 20:28.400
konnte, dass mehr Leute sowas zur Hand haben, Keyboard und halt auch sagen wir mal Nerd

20:28.400 --> 20:29.680
genug sind, sowas auch zu benutzen.

20:29.680 --> 20:42.040
Ja, und man merkt natürlich auch ein bisschen im Gegenteil zu, also im Gegensatz zu den

20:42.040 --> 20:46.960
HTML5-Elementen, die so eingeführt wurden, dass man damals eben noch keine IDE hatte

20:46.960 --> 20:54.200
und echt so wenig per Hand tippen wollte wie möglich, also weil diese ganzen Elemente halt

20:54.200 --> 20:59.960
B ist ja auch so ein Kandidat, also anstatt bold, so das war schon zu viel, vier Buchstaben

20:59.960 --> 21:06.520
schreiben, doof, wir wollen nur einschreiben, Keyboard, KBD, so heißt das Tag ja eigentlich,

21:06.520 --> 21:12.880
ist ja auch mega kurz und genau dagegen halt einen strong Emphasis ist dann auch wieder

21:12.880 --> 21:19.880
abgekürzt, aber ich glaube das kann man daran auch ganz gut ablesen und ich finde es glaube

21:19.880 --> 21:23.960
ich besser wie es jetzt ist, als wie es früher war.

21:23.960 --> 21:30.840
Ja, auf jeden Fall, bloß nicht abkürzen, weil es ist uneindeutig und man muss überlegen,

21:30.840 --> 21:35.480
was heißt denn dieses KBD jetzt eigentlich, ja wahrscheinlich Keyboard, aber vielleicht

21:35.480 --> 21:41.400
heißt es halt auch was anderes, oder so, oder XMP, das finde ich ja besonders schön, was

21:41.400 --> 21:49.360
heißt das eigentlich, ich habe keine Ahnung, Example, ich soll das Example sein ernsthaft,

21:49.360 --> 21:57.480
was weiß ich, bin ich Brockhaus, keine Ahnung, Example, warte, ich guck mal schnell, ob

21:57.480 --> 22:04.920
ich das hier im MDN finde, Example, also in den Spezifikationen steht nur drin, dass

22:04.920 --> 22:09.000
man es nicht mehr benutzen soll, aber da steht keine Definition davon, was es denn mal gewesen

22:09.000 --> 22:10.000
sein sollte.

22:10.000 --> 22:15.520
Aber es hat spezielle Pasa-Semantik, das ist ja immer sehr schön, wenn im Pasa eigentlich

22:15.520 --> 22:16.520
Ausnahmen drin sind.

22:16.520 --> 22:24.520
Ja, ich denke mal, dass es auch deswegen deprecated ist, genau weil du kannst halt HTML-Code reinpacken

22:24.520 --> 22:29.440
und der wird dann, es ist ausgegeben, also wird dann quasi nicht mehr interpretiert,

22:29.440 --> 22:33.520
das finde ich ja in diesem Element so toll und so praktisch, man muss im Gegensatz

22:33.520 --> 22:41.120
zu Code und Co. nichts quasi Entities codieren, man kann es einfach da rein donnern, aber

22:41.120 --> 22:48.480
was, also woher diese Abkürzung kommt, das bleibt ein Rätsel.

22:48.480 --> 22:55.720
Ein Aufruf natürlich wieder an die Community, helft uns hier mal bitte weiter, wer von euch

22:55.720 --> 23:00.320
hat das schon mal verwendet, das xmp tag in der Vergangenheit und wo läuft es vielleicht

23:00.320 --> 23:08.200
auch noch in Production-Umgebungen, obwohl deprecated, und ihr sagt so, man müsste mal, schreibt

23:08.200 --> 23:14.720
es uns mal einfach auf Twitter oder in unseren, ich sag jetzt einfach mal, Patreon-Kommentaren.

23:14.720 --> 23:24.320
Okay, gut, haben wir die, dann gerne da, genau, aber eben vor allem, wofür steht

23:24.320 --> 23:29.320
xmp, das ist ja wirklich die allerspannendste Frage.

23:29.320 --> 23:35.520
Ich würde echt xmp annehmen, weil wenn du dir so diese Suppe aus so frühem HTML dir

23:35.520 --> 23:39.520
vorstellst, wo ja auch noch irgendwelche HTML-Texts sind, die ja noch mehr als das normale Obsolid

23:39.520 --> 23:45.000
in den Spezifikationen sind, wo ja tatsächlich das Web selber Gegenstand von Webseiten viel

23:45.000 --> 23:49.320
mehr war, und wenn du halt da direkt den Text ausgeben kannst, ist es ja ein Example für

23:49.320 --> 23:50.320
HTML.

23:50.320 --> 23:54.880
So komme ich auf diesen Drichter.

23:54.880 --> 24:06.320
Bei IBM, da gibt es die, beschreibe mal xmp-Tag, das, oder, mit Example.

24:06.320 --> 24:10.800
Also ich meine, eigentlich müsste man doch bloß in ausreichend alte HTML-Spezifikationen

24:10.800 --> 24:11.800
reinschauen, oder?

24:11.800 --> 24:17.800
Also HTML 4.01, zack, lass mal gucken, wahrscheinlich steht da auch nichts drin.

24:17.800 --> 24:23.200
Genau, aber xmp-Tag defines unformatted text with an information region.

24:23.200 --> 24:29.640
Das klingt, das ist auf jeden Fall ein Begriff, der mich auch sehr an IBM denken lässt.

24:29.640 --> 24:37.280
Ja, also, aber so, genau, also wir kommen dem Geheimnis trotzdem nicht näher.

24:37.280 --> 24:42.080
Ich werfe den Link einfach mal hier, was ich da aufgegabelt habe.

24:42.080 --> 24:49.240
Genau, das ist die Dokumentation von ZOS 2.1.0.

24:49.240 --> 24:52.080
Okay, was ist ZOS?

24:52.080 --> 24:55.800
Ich vermute irgendein IBM-Betriebssystem.

24:55.800 --> 25:02.200
Ja, ich habe es in den Spezifikationen von HTML 2 gefunden.

25:02.200 --> 25:07.160
Definiert zusammen mit dem Listing-Tag als Example-Endlisting.

25:07.160 --> 25:15.560
Ah, so, ja cool, guter Wald, ich wusste es nicht, aber jetzt weiß ich es.

25:15.560 --> 25:19.680
Okay, man muss ja auch nur in die HTML 2-Spezifikationen reingucken, dann weiß man sofort.

25:19.680 --> 25:22.760
Ja, und wer liest die nicht als gute Nachtlekteure?

25:22.760 --> 25:27.600
Also, ich finde das völlig normal und wer das nicht macht, ist komisch, so.

25:27.600 --> 25:33.120
So, das ruft doch danach, dass wir uns jetzt nochmal einem neuen Thema widmen, wo vielleicht

25:33.120 --> 25:36.680
andere Leute die gute Nachtlekteure von lesen.

25:36.680 --> 25:40.520
So ist es, soll ich mal?

25:40.520 --> 25:45.200
Okay, ich drücke auf Zufallsgenerator aktivieren.

25:45.200 --> 25:50.200
Yeah, Web-Audio-API, Zeug, von dem ich keine Ahnung habe, aber ich habe hier auch draufgeklickt,

25:50.200 --> 25:51.200
also müsst ihr das erklären.

25:51.200 --> 25:52.200
Pupup.

25:52.200 --> 26:01.480
Genau, das ist die Stereo-Penna-Node, nicht Penna wie Obdachloser.

26:01.480 --> 26:05.000
Wollts grad sagen, wie hast du mich genannt?

26:05.000 --> 26:13.600
Genau, aber es sind quasi Penna im Sinne von dieses Verstellen, quasi wo eben schäpfungmäßig

26:13.600 --> 26:18.760
der Ton rauskommen soll in einem Stereo-Setup oder vielleicht auch in einem Surround-Setup,

26:18.760 --> 26:24.600
so aus welchem Lautsprecher, da kann man eben hin und her Pannen und ich vermute mal, dass

26:24.600 --> 26:30.280
diese, also diese Web-Audio-API ist ja so, glaube ich, gestrickt, dass man wie so ein

26:30.280 --> 26:35.760
Flussdiagramm zusammenbauen kann, wo dann irgendwie der Ton verarbeitet wird und diese

26:35.760 --> 26:41.720
einzelnen Elemente sind eben dann Notes und ich vermute mal, die mit der Stereo-Penna-Node

26:41.720 --> 26:46.720
kann man dann eben einstellen, ob ein Ton eher eben aus dem linken Bereich kommen soll

26:46.720 --> 26:47.720
oder aus dem rechten.

26:47.720 --> 26:48.720
So sieht es aus.

26:48.720 --> 26:49.720
So sieht es aus.

26:49.720 --> 26:54.280
Ja, und ich werde das wahrscheinlich nie benutzen.

26:54.280 --> 27:01.920
Ja, wenn man so ein Interface bauen möchte, in dem man irgendwie Aufnahmen machen kann,

27:01.920 --> 27:08.920
zum Beispiel wenn man hier jetzt für den, also einen Monitoring-Ton bei uns im Aufnahmetool

27:08.920 --> 27:13.240
haben wollen würde von seiner eigenen Stimme, möchte man das vielleicht nur auf einem

27:13.240 --> 27:20.000
Ohr haben und dafür wäre das ja dann beispielsweise ganz praktisch oder, oder, oder solche Use-Cases.

27:20.000 --> 27:26.760
Man nimmt irgendeine Aufnahme auf und möchte die dann, also auf Phonic halt im Browser

27:26.760 --> 27:30.080
haben oder so, das könnte schon interessant sein.

27:30.080 --> 27:35.240
Ja, und ich denke mal, wenn du jetzt irgendwie Spiele programmierst, also dann ist es wahrscheinlich

27:35.240 --> 27:39.160
auch nicht, nicht schlecht, dass, dass man sowas hat.

27:39.160 --> 27:43.160
Ja, oder du kannst natürlich auch programmier, lernen Sandbox.

27:43.160 --> 27:46.600
Sowas gibt es ja ganz gerne mal mit einem Canvas-Element, weil man da irgendwie, man

27:46.600 --> 27:50.320
dreht irgendwie an drei Zahlen und schon verändert sich der Output, das kannst du ja visuell

27:50.320 --> 27:53.400
mit einem Canvas-Element sehr schön machen, aber mit einem Audio-Element könntest du

27:53.400 --> 27:54.400
es ja auch so machen.

27:54.400 --> 27:58.400
Das sind ja alles nummerische Parameter, an denen man bei solchen Notes dreht und da kriegt

27:58.400 --> 28:01.560
man ja relativ schnell den Effekt hin, okay, ich ändere jetzt mal diese Zahl, ah, was passiert

28:01.560 --> 28:02.560
denn hier?

28:02.560 --> 28:04.720
Ich gebe da was Negatives rein, ah, kommt ein Fehler.

28:04.720 --> 28:09.920
So, für, ich fummel da jetzt erstmals als irgendjemand, der da komplett unbeleckt ist

28:09.920 --> 28:13.960
an sowas herum, könnte ich mir auch als Use-Case vorstellen, muss ja nicht immer alles optisch

28:13.960 --> 28:14.960
sein.

28:14.960 --> 28:23.200
Ja, also ein bisschen wie Schaltkreise zusammenbauen und Lampe ans Leuchten bringen und so weiter,

28:23.200 --> 28:24.200
ne?

28:24.200 --> 28:27.080
Genau, das könnte so die LED des JavaScript Tutorials sein.

28:27.080 --> 28:37.520
Ja, cool, ansonsten auch wieder da der Aufruf, habt ihr die Stereo-Paner-Note schon benutzt

28:37.520 --> 28:45.600
und wenn ja, wofür, schreibt uns auf Twitter, machst du dann oder kommt in unseren Community-Slack?

28:45.600 --> 28:46.600
So.

28:46.600 --> 28:50.680
Und dann würde ich sagen, drücke ich jetzt mal auf den Knopf, oder?

28:50.680 --> 28:51.680
Genau.

28:51.680 --> 28:52.680
Sehr gerne.

28:52.680 --> 28:59.640
Ah ja, so, da waren wir doch vorhin schon in der Nähe, ne, also das Meta-Element ist

28:59.640 --> 29:00.640
jetzt.

29:00.640 --> 29:02.560
Ja, blödes Facebook übernimmt das ganze, übernimmt das ganze Internet.

29:02.560 --> 29:03.560
Genau.

29:03.560 --> 29:06.280
Ja, jetzt haben die sogar eigene Tags, Schweine.

29:06.280 --> 29:12.520
Und wer es nicht verlinkt, der wird auf Facebook nicht dargestellt und eure Eltern und Großelbe

29:12.520 --> 29:19.160
können sich sagen, nein Spaß, wir verwenden natürlich alle das Meta-Tag für verschiedenste

29:19.160 --> 29:23.960
Dinge, ich glaube so der, der normalste Use-Case in Anführungsstrichen sind wahrscheinlich

29:23.960 --> 29:29.120
eher so Descriptions, die man halt irgendwie mit dem Meta-Tag verbindet, aber man kann

29:29.120 --> 29:35.080
ja auch noch viel, viel mehr damit machen, weil das so ein Standard-Ding ist, ne, also

29:35.080 --> 29:41.040
man fängt ja eigentlich ganz oben im Dokument an und definiert erst mal das Zeichen-Set,

29:41.040 --> 29:45.560
mit dem man irgendwie unterwegs ist, indem man sagt, okay, das hier ist mein Car-Set,

29:45.560 --> 29:55.560
GTF-8 im Normalfall und dann kann man alle möglichen Meta-Daten eigentlich dazu einreichen

29:55.560 --> 29:58.080
oder einen, damit einrichten sozusagen.

29:58.080 --> 29:59.080
Ja.

29:59.080 --> 30:04.800
Was mich ja mal interessieren würde, ist mal, ich hätte gern irgendwie eine Webseite,

30:04.800 --> 30:09.560
die ich ansteuern kann, wo so da der aktuelle State of the Art drin steht, gerade was so

30:09.560 --> 30:14.280
da, was wenn es so darum geht irgendwie Informationen anzugeben, um sich da den diversen Social

30:14.280 --> 30:18.760
Media-Giganten und so auf die korrekte Weise anzudienen und ob man denen dann ein Bild

30:18.760 --> 30:22.640
hinterlegen kann und wenn man denen ein Bild hinterlegt, welche Dimensionen das denn bitte

30:22.640 --> 30:26.120
schön haben möchte, habe ich letztes mal probiert irgendwie so rauszufinden, weil ich mich da

30:26.120 --> 30:30.760
meistens nicht groß drum kümmere, gar nicht mal so einfach, gibt halt nicht so die zentrale

30:30.760 --> 30:34.720
Stelle, wo man irgendwie so sieht, so dann irgendwie, das machst du für Twitter, das

30:34.720 --> 30:37.840
machst du für Facebook, das machst du für Mastodon und dann musst du noch dis und dis und dis

30:37.840 --> 30:38.840
angeben.

30:38.840 --> 30:46.560
Ich dachte, es gibt doch diese Open Graphseite, die erklärt das aber auch nicht.

30:46.560 --> 30:49.680
Die erklärt das schon, aber ich glaube Twitter macht was anderes als das.

30:49.680 --> 30:52.160
Twitter hat ja so ein Twitter-Cards.

30:52.160 --> 30:56.280
Genau, wo der Validator nicht mehr funktioniert, weil sie den abgeschaltet haben, auch schon

30:56.280 --> 30:57.280
vor Spacecaron.

30:57.280 --> 30:58.280
Ja.

30:58.280 --> 31:10.360
Ja, aber keine Ahnung, also ich kenne nur diese Validator-Tools, aber ich kenne jetzt

31:10.360 --> 31:17.760
nicht die, also kein Tool, was dir sozusagen sagt, hier verwende bitte diese Tags, aber

31:17.760 --> 31:23.640
ja, das ist ein Problem, also Open Graph funktioniert ja relativ gut, aber auch da habe ich zum

31:23.640 --> 31:30.400
Beispiel festgestellt, gibt es halt manchmal das Verlangen eines Tags, das du dann schreibst

31:30.400 --> 31:38.880
halt Meter, also Spitzeklammer auf, Meter und dann, was schreibt man, normalerweise Content,

31:38.880 --> 31:47.560
ne, Entschuldigung, Name, genau, Name und dann ist es zum Beispiel Image, also OG Doppelpunkt

31:47.560 --> 31:54.760
Image, aber manchmal ist es dann halt auch nicht Name, sondern du musst Property verwenden

31:54.760 --> 31:58.400
und du kannst sie nicht Synonym verwenden, irgendwie sowas habe ich auch noch mal festgestellt

31:58.400 --> 31:59.400
irgendwann.

31:59.400 --> 32:06.080
Ja, weil es tatsächlich ist es ja auch da, das habe ich letztens mal recherchiert mit

32:06.080 --> 32:12.320
so denen, also was kannst du als Name alles angeben, also Medatec ist ja im Prinzip immer

32:12.320 --> 32:17.680
ein Name wertbar, Key und Value und welche Keys gibt es eigentlich alle und tatsächlich

32:17.680 --> 32:21.240
ist das nicht besonders irgendwie fest definiert, es gibt halt so die Keys, die man üblicherweise

32:21.240 --> 32:25.120
verwendet, aber es gibt halt sozusagen kein oberes Limit, also im Prinzip kann sich da

32:25.120 --> 32:29.200
jeder was ausdenken und das ist auch nicht notwendigerweise irgendwie groß gename spaced

32:29.200 --> 32:34.480
oder so, das ist wirklich weitgehend wilder Westen, okay, da passt jetzt nicht so rein,

32:34.480 --> 32:37.920
dass man sich da irgendwelche Attribute ausdenkt, weil das sollte man ja eigentlich tendenziell

32:37.920 --> 32:43.360
eher nicht tun, dann gleich das am Ende trotzdem zu uniformen Verhalten überall führt.

32:43.360 --> 32:50.280
Tja, also will nur sagen, da geht eine ganze Menge und das muss man alles irgendwie glaube

32:50.280 --> 32:52.760
ich nicht so strikt sehen wie so viel als andere.

32:52.760 --> 32:59.520
Du hast es ja vorhin schon gesagt, also das Character Set, das ist auf jeden Fall relativ

32:59.520 --> 33:04.760
wichtig, sollte auch als erstes kommen, dann gibt es ja noch diese Viewport, also quasi

33:04.760 --> 33:11.560
wie etwas, was Apple irgendwann eingeführt hat, das sind so die zwei Meterangaben, die

33:11.560 --> 33:15.920
glaube ich irgendwie Pflicht sind und die man haben sollte und die man auch möglichst

33:15.920 --> 33:20.240
früh setzen sollte, weil die auch einen Impact auf das Rändering haben.

33:20.240 --> 33:22.720
Ist nicht Pflicht, du kannst ja das Kastet auch mit einem Header mitschicken und wenn

33:22.720 --> 33:25.120
du das mitschickst, dann brauchst du die Metatech nicht.

33:25.120 --> 33:30.840
Ja, die Kollegen von, wo wir sind, ist vorne, die machen jetzt gerade so oder die haben

33:30.840 --> 33:35.720
in ihrer neuen Staffel, haben sich überlegt, dass sie quasi alle HTML Elemente durchgehen

33:35.720 --> 33:41.240
und in der ersten Folge ging es um die, die im Kopf bereicht sind und genau und die wollen

33:41.240 --> 33:45.400
wir auf jeden Fall auch verweisen, weil die auch noch ein bisschen ausschweifender über

33:45.400 --> 33:50.720
diese, weil sie sich auch nur um den Head Bereich gekümmert haben, über diese Elemente gesprochen

33:50.720 --> 33:57.680
haben und in dem Kontext hatte mich auch mal interessiert und habe ich nachgeschlagen,

33:57.680 --> 34:03.320
gibt es denn überhaupt ein Default Character Set, also wenn man, also man kann einen Header

34:03.320 --> 34:07.920
schicken, wie du gesagt hast Peter, man kann aber auch irgendwie beides nicht haben und

34:07.920 --> 34:16.240
dann, da habe ich herausgefunden, dass unterhalb von HTML5 ist das Latin One, was dann automatisch

34:16.240 --> 34:25.800
gesetzt wird oder genutzt wird und ab HTML5 ist es dann automatisch UTF-8, genau, aber

34:25.800 --> 34:31.320
trotzdem, also ich sage mal sicher ist sicher, das Character Set setzen tut einem hier noch

34:31.320 --> 34:34.480
nicht weh und sollte man tun.

34:34.480 --> 34:39.320
Was vielleicht da noch ganz spannend ist, ist, dass das ja so, das war ja früher ein bisschen

34:39.320 --> 34:47.640
aufwendigere Angabe, das Character Set auszuzeichnen und das ist ja eigentlich wie der HTML5-Docktype

34:47.640 --> 34:55.400
so ein quasi so ein Pasa-Hack, dass man das jetzt so kurz ausdrücken kann oder, oder

34:55.400 --> 34:56.400
wie will ich das schiefgewickelt?

34:56.400 --> 35:00.280
Ich meine, da wäre sowas in der Richtung gewesen, dass das früher komplizierter gewesen wäre

35:00.280 --> 35:02.840
und man sich jetzt auf diese Kurzvariante geeinigt hätte.

35:02.840 --> 35:11.440
Irgendwie war es doch so, dass es früher dieses HTTP Equif als praktisch Key sozusagen

35:11.440 --> 35:19.120
gab und dann hat man das Kassett angegeben und wenn ich mich richtig erinnere, hat irgendwer

35:19.120 --> 35:27.800
dann damals im Rahmen der HTML5-Thematik versucht, was kann man denn minimieren und die meisten

35:27.800 --> 35:33.200
Browser funktionieren dann trotzdem und daraufhin hat man halt herausgefunden, dass es irgendwie

35:33.200 --> 35:39.440
reicht, wenn man dann halt Kassett und dann halt das Kassett dazu schreibt, dass das ausreichend

35:39.440 --> 35:44.920
ist und daraufhin hat man dann halt gesagt, okay, dann schreiben wir halt nur noch das

35:44.920 --> 35:51.480
und brauchen nicht dieses HTTP Equif-Ding dazu packen, weil interessiert dem Browser

35:51.480 --> 35:57.080
eh nicht und dadurch wurde das dann so relativ kurz, sondern gab es immer diese ganzen Showcases

35:57.080 --> 36:03.880
hier, die kürzeste HTML-Seite, die valide ist und dann war da halt so das Metatec, der

36:03.880 --> 36:15.320
Title gesetzt und Body und das war es ungefähr oder Body brauchte man nicht mehr, glaub ich.

36:15.320 --> 36:21.080
Ja, ich versuch das gerade nochmal zu ergoogeln, aber es ist so ein Skandal, ich hab tatsächlich

36:21.080 --> 36:25.720
schon, ich hab mal, ich hab was geplant, nämlich alle HTML-Text tatsächlich einmal so durchzugehen

36:25.720 --> 36:30.480
in auch so einem Podcast-Format und jetzt erfahre ich hier in meinem einen Podcast,

36:30.480 --> 36:35.320
für meinen geplanten anderen Podcast, die Dritten sowas ähnliches schon machen, so

36:35.320 --> 36:36.320
ein Skandal.

36:36.320 --> 36:39.000
Das ist echt schade.

36:39.000 --> 36:40.000
Frechheit.

36:40.000 --> 36:41.000
Ja.

36:41.000 --> 36:42.000
Kannst du den Geld anbieten?

36:42.000 --> 36:43.000
Nee.

36:43.000 --> 36:47.680
Das sieht anders genug aus als das, was ich vorgehabt hab, insofern, wenn ich mal dazu

36:47.680 --> 36:48.680
komme.

36:48.680 --> 36:49.680
Ja, super.

36:49.680 --> 36:54.920
Aber meine Güte, ich dachte, ich hätte eine originelle Idee gehabt, so viel dazu.

36:54.920 --> 37:03.480
Aber so 20 Minuten nur über einen Element abnurden wäre auch cool, also du jetzt.

37:03.480 --> 37:06.680
Ja, das ist halt so die Idee, also weniger über das Element, weil was willst du irgendwie

37:06.680 --> 37:11.600
über das B-Element erzählen, weil meine Hand hat ja vorhin wirklich alles dazu erwähnt,

37:11.600 --> 37:16.440
was es zu erwähnen gibt in halt so drei Minuten, aber man kann halt damit immer so interessante

37:16.440 --> 37:17.440
Fragen verbinden.

37:17.440 --> 37:21.800
Also man kann ja tatsächlich irgendwie sagen, hey, das Element macht das, warum ist das so

37:21.800 --> 37:25.080
cool und was hat das mit X-RTML zu tun und warum haben wir zwei Spezifikationen, man könnte

37:25.080 --> 37:28.860
halt das so ähnlich wie beim Gücksrad ja auch, das eigentlich je Thema nur als so Startpunkt

37:28.860 --> 37:33.240
verwenden und eigentlich habe ich auch schon Skrips für zehn Folgen geschrieben, allein

37:33.240 --> 37:34.640
man müsste halt mal auch einsprechen.

37:34.640 --> 37:40.080
Und wenn ich nicht irgendwie Leute wie euch habe, um die Terminfindung irgendwie zu beschleunigen,

37:40.080 --> 37:42.080
dann passiert das halt nicht.

37:42.080 --> 37:47.320
Na ja, wenn du gleich Hilfe brauchst, sag gerne Bescheid.

37:47.320 --> 37:51.920
Okay, und was willst du machen, willst du meine Termin, willst du mich zur Termineinhaltung

37:51.920 --> 37:53.480
anhalten mit Peitscher und?

37:53.480 --> 37:57.400
Ja, irgendwie so oder ich verabrede mich mit dir zu einer Aufnahme und tauch da nicht

37:57.400 --> 38:01.240
auf, weil es ja eh nur du sein soll, weißt du, aber du fällst auf rein.

38:01.240 --> 38:04.200
Okay, so können wir das machen.

38:04.200 --> 38:09.320
Genau, ah, Mist, schon wieder eingefallen, Lila Schäpp, der ist echt ein Fuchs.

38:09.320 --> 38:10.320
Nächstes Mal.

38:10.320 --> 38:11.320
Ja.

38:11.320 --> 38:15.960
All righty, ich würde sagen, der Hans kann nochmal drücken, oder?

38:15.960 --> 38:16.960
So ist es.

38:16.960 --> 38:17.960
Genau, ja.

38:17.960 --> 38:21.800
Ich hau mal drauf und dann schauen wir mal, was bei rumkommt.

38:21.800 --> 38:30.400
Ah, ja, ah, ja, wir sind wieder im API-Bereich unterwegs, puh, puh, puh, wir sind im Error-Bereich

38:30.400 --> 38:31.400
unterwegs.

38:31.400 --> 38:38.160
Wir sind, ja, im Error-Bereich, genau, mediaerror.message.

38:38.160 --> 38:44.400
Es geht um Audio-Tags, denke ich mal, es geht um, ähm, jo.

38:44.400 --> 38:52.360
Ja, HTML-Media-Element, also so die Superklasse von Audio und Video und das hat anscheinend

38:52.360 --> 38:57.360
eine spezielle Klasse von Error mit einem Code und einer Message.

38:57.360 --> 39:04.040
Und genau, da gibt es halt diese Message drin und die kann man dann verwenden und sich da

39:04.040 --> 39:11.240
in dem Benutzer etwas auszugeben, dachte ich, aber Peter, du kennst dich jetzt nicht.

39:11.240 --> 39:14.560
Weil du hast ja mit Media-Element Fehler, die passieren können, die dir normalerweise

39:14.560 --> 39:15.560
nicht passieren können.

39:15.560 --> 39:19.200
Also du hast irgendwie, weil sie nicht undefined ist, nur zu functionen, ist ja eine andere

39:19.200 --> 39:22.920
Problemklasse, eine viel generelle Problemklasse, als irgendwie dein Audio-Codec wird nicht

39:22.920 --> 39:23.920
unterstützt.

39:23.920 --> 39:28.440
Und um diese Dinger abzubilden, gibt es halt die extra Klasse mit spezifischen Code-Konstanten

39:28.440 --> 39:32.520
1, 2, 3, 4, warum bei 0 anfangen zu zählen, macht ja anscheinend sonst keiner, was weiß

39:32.520 --> 39:33.520
ich.

39:33.520 --> 39:36.560
Und das sind halt wirklich so Dinger für irgendwie der Media-Streambude abgebrochen, Codec nicht

39:36.560 --> 39:37.560
unterstützt so kram.

39:37.560 --> 39:44.600
Ich habe meine mich da irgendwie vor irgendwie 20 Jahren mal beim HTML5-Buch auch mit befasst

39:44.600 --> 39:45.600
zu haben.

39:45.600 --> 39:49.440
Das kam jetzt gerade so kurz wieder, nachdem ich überlegt habe, was könnte das noch mal

39:49.440 --> 39:50.440
gewesen sein.

39:50.440 --> 39:55.040
Wann hast du das noch mal geschrieben?

39:55.040 --> 39:56.040
2009.

39:56.040 --> 39:58.760
Okay, nicht ganz 20 Jahre, aber gefühlt.

39:58.760 --> 39:59.760
Ja, cool.

39:59.760 --> 40:00.760
Lange sehr.

40:00.760 --> 40:01.760
Sehr.

40:01.760 --> 40:09.880
Aber ich würde sagen, damit haben wir es auch schon besprochen, oder?

40:09.880 --> 40:11.920
Viel lässt sich darüber ja nicht erzählen.

40:11.920 --> 40:12.920
Ich glaube auch nicht.

40:12.920 --> 40:14.920
Ja, was machen wir eh nicht, oder?

40:14.920 --> 40:16.920
Also wer behandelt denn etwas?

40:16.920 --> 40:22.400
Also die einzige Frage wäre halt noch so, macht ihr das eigentlich so eure eigenen Error-Klassen

40:22.400 --> 40:23.400
konstruieren?

40:23.400 --> 40:26.520
Weil geht ja heutzutage recht einfach, dass man so sagt, klar, das ist mein Custom-Error,

40:26.520 --> 40:27.520
Extenz-Normaler-Error.

40:27.520 --> 40:30.560
Kann man schmeißen, hat Stacktraces und so weiter?

40:30.560 --> 40:31.880
Nop.

40:31.880 --> 40:40.680
Also, die Frameworks, die nutzen das ja sicher so, also ich meine, wenn wir uns Reakt angucken

40:40.680 --> 40:44.680
oder so, gibt es immer ganz tolle Errors und ist auch wunderschön.

40:44.680 --> 40:52.120
Aber um ehrlich zu sein, habe ich also auch in Anwendungen mit vielen Errors oder vielen

40:52.120 --> 40:59.160
Benutzern und Benutzern drauf, halt nie das Problem, dass ich den Startpunkt des Errors

40:59.160 --> 41:04.600
beispielsweise nicht Pinpointen könnte anhand von irgendwelchen Logs, die du jetzt im Frontend

41:04.600 --> 41:05.600
erfasst.

41:05.600 --> 41:11.800
Also, ich finde der Use Case dafür, der ist okay, den kann man haben, aber es ist halt

41:11.800 --> 41:16.160
auch nicht so, also man braucht das nicht so oft, habe ich das Gefühl.

41:16.160 --> 41:20.080
Vielleicht red ich auch Quatsch und die Leute, die jetzt jeden Tag programmieren, die sagen

41:20.080 --> 41:26.360
jetzt Hans, ohne das geht das nicht, sonst komme ich nicht klar im Leben, okay, akzeptiert,

41:26.360 --> 41:34.640
ich habe keine Ahnung, aber irgendwie, ich war noch nie an diesem Punkt, dass ich gedacht

41:34.640 --> 41:38.680
habe auch, nee, jetzt war ja aber eine eigene Errorklasse, weil sonst komme ich hier mit

41:38.680 --> 41:42.280
meinen JavaScript Errors im Frontend gar nicht klar.

41:42.280 --> 41:47.120
Nee, also klar kommen sicherlich auch nicht, aber ich hatte mir das mal vor kurzem wie

41:47.120 --> 41:51.600
folgt gedacht und ihr könnt mir ja mal kurz erzählen, ob der Gedanke Käse ist.

41:51.600 --> 41:56.440
Aber im Prinzip ist ja Exception Handling, auch wenn man es so nicht verwenden sollte,

41:56.440 --> 41:59.120
ein alternativer Mechanismus, um Control Flow zu machen.

41:59.120 --> 42:03.360
Richtig, ich kann eine Error schmeißen, aus der aktuellen Funktion lossteigen, um mich

42:03.360 --> 42:07.640
dann irgendwo weiter oben im Stack catching zu lassen und dann weiter zu machen.

42:07.640 --> 42:15.520
So, wieder Aufnahme machen, nochmal probieren nach X Sekunden, whatever, ja.

42:15.520 --> 42:16.520
Genau.

42:16.520 --> 42:22.360
Und in dem Sinne, wenn man jetzt eine Exception in der Form denkt, ist die ja einem Event

42:22.360 --> 42:23.520
nicht ganz unähnlich.

42:23.520 --> 42:30.120
Stimmt, und du spaßt ja auch viele Return-Zwischenschritte, je nachdem, wie tief das runtergeht.

42:30.120 --> 42:33.720
Ja, jetzt bist du schon wieder sozusagen viel zu optimistisch auf der Sache und denkst

42:33.720 --> 42:38.000
so, ah, wie kann man das denn irgendwie für Gutes verwenden, was jetzt irgendwie originelle

42:38.000 --> 42:40.040
Control Flow Mechanismen sind oder sowas.

42:40.040 --> 42:46.280
Und ich meine, irgendein Ding aus dem React-Context, die schmeißen irgendwie Promises als Exceptions

42:46.280 --> 42:50.360
und so und damit irgendwelches Async-Handling in ihren komischen Komponenten, weil ich

42:50.360 --> 42:54.200
weiß jetzt nicht, ob das dieses Suspend-Resume-Ding war oder irgendwas anderes, aber es gibt

42:54.200 --> 42:55.200
Menschen, die das tun.

42:55.200 --> 42:59.120
Ich war jetzt aber tatsächlich noch dabei, den Error wirklich wie ein Error zu behandeln.

42:59.120 --> 43:02.320
Die Frage ist halt eben, was stecke ich da für Informationen rein?

43:02.320 --> 43:05.160
Und wenn ich halt sowas habe, wie undefinedes not function, irgendwie so ein Passerror

43:05.160 --> 43:08.560
oder so, ist der Fehler ja tatsächlich extrem allgemeiner Natur.

43:08.560 --> 43:13.480
Man hat halt eben auch sowas wie den Media-Error, der sehr spezifischer Natur ist, also Codec

43:13.480 --> 43:14.480
ist irgendwie kaputt.

43:14.480 --> 43:21.120
Man könnte sogar sagen, dass dieser Media-Error definitiv immer zu einem Dom-Element zugehörig

43:21.120 --> 43:22.120
ist.

43:22.120 --> 43:25.400
Woanders kommen die Dinger ja nicht her, irgendwo muss ja der Codec kaputt gegangen sein.

43:25.400 --> 43:30.640
Und wenn ich jetzt so meine Analogie aufmache zu meinem Event-Objekt wieder, ist es ja so,

43:30.640 --> 43:35.720
es gibt ein Event wie Click oder so, dann will ich ja wissen, welches Element wurde da jetzt

43:35.720 --> 43:38.160
geklickt zum Beispiel und dann mache ich halt Event.target.

43:38.160 --> 43:44.360
Warum haben solche Exceptions, die tatsächlich einen definitiven Ursprungspunkt in Form eines

43:44.360 --> 43:48.160
Dom-Elements haben, nicht auch so eine Target-Property, denke ich mir.

43:48.160 --> 43:54.040
Und manchmal gehe ich halt schon hier und mache mir halt eben so eine Custom-Error-Klasse

43:54.040 --> 43:59.120
und mache einfach nur ein ganz normales Extents-Error und gebe denen halt nur eine extra Property

43:59.120 --> 44:04.360
namens Target, die ich dann festlege, auf halt eben das Target und das kann ich ja irgendwie

44:04.360 --> 44:09.120
konstruieren, dass ich dann beim Error-Konstruktor ein Pflichtparameter habe, der das Target

44:09.120 --> 44:12.120
sein soll oder ich kann es optional machen, ich kann es undefined machen.

44:12.120 --> 44:15.840
Und das Nette daran ist natürlich auch, wenn man das so verwendet im Kontext von Web-Komponents

44:15.840 --> 44:20.200
ist, ich kenne das ja tatsächlich Typen, also jetzt nicht notwendigerweise den Error generisch

44:20.200 --> 44:24.640
machen, aber wenn ich zum Beispiel sowas habe wie diesen Media-Error und ich weiß, der kommt

44:24.640 --> 44:30.400
aus einem HTML-Media-Element, der Superklasse von Audio und Video, weiß ich ja noch nicht

44:30.400 --> 44:33.800
notwendigerweise, welches von beiden das ist, aber ich kann ja trotzdem da irgendwie sagen,

44:33.800 --> 44:38.200
hey, diese Schnittmenge dieser Superklasse mit so Sachen wie Play und Pause und so,

44:38.200 --> 44:41.680
die kann ich dann ja trotzdem zur Verfügung stellen, also sowohl jetzt rein logisch gedacht

44:41.680 --> 44:45.400
von, ich programmier das, als auch zum Beispiel aus der TypeScript-Perspektive, ich kriege

44:45.400 --> 44:48.600
dann ja aus diesen Media-Error-Informationen raus, wie zum Beispiel, aha, da kommt es

44:48.600 --> 44:52.720
her, aus dem Element will ich mir vielleicht die Source angucken und so Geschichten und

44:52.720 --> 44:56.560
ich finde eigentlich, dass bei sehr vielen Errors so eine Target-Property voll viel

44:56.560 --> 45:01.960
Sinn macht und bei meinen Web-Komponents, wo ich wirklich Errors frisch aus heißer Luft

45:01.960 --> 45:06.360
erschaffe, wo ich sage, das ist jetzt ein spezifischer Error-Fall, da gehe ich wirklich hin und mache

45:06.360 --> 45:09.880
mir so eine Klasse, weil es nicht viel kostet und ich baue ein Target dran und es wird für

45:09.880 --> 45:12.560
TypeScript ein bisschen besser und das ist eigentlich alles irgendwie ganz nett, finde

45:12.560 --> 45:13.560
ich.

45:13.560 --> 45:23.800
Ja, absolut, aber du könntest natürlich auch, also okay, und jetzt wäre natürlich die

45:23.800 --> 45:31.640
Gegenfrage, wenn du damit ein Control Flow irgendwie dir baust, oder wenn du das eventartig

45:31.640 --> 45:38.960
verwendest, dann, also ein Event selbst, also zum Beispiel, du könntest ja ein Error-Event,

45:38.960 --> 45:45.800
wie das Image-Element, das könntest du ja quasi Trigger'n, Custom Error-Event und da

45:45.800 --> 45:49.640
hättest du ja dann automatisch deinen, oder wer hättest du auch deinen Target drin und

45:49.640 --> 45:53.960
kannst du auch Infos reinstecken.

45:53.960 --> 45:58.320
Das ist richtig, aber das ist ein Error-Event und nicht eine Exception, also die Frage ist

45:58.320 --> 46:01.720
halt, was erwartest du?

46:01.720 --> 46:07.160
Du warst jetzt sehr auf Control Flow eingestiegen, so mit der Idee von wegen, das würde man vielleicht

46:07.160 --> 46:10.360
sozusagen gezielt dafür herstellen, damit man das in dem Sinne nutzen kann.

46:10.360 --> 46:13.120
Würde ich jetzt gar nicht so machen wollen, ich würde jetzt nicht sagen Control Flow

46:13.120 --> 46:16.640
per Exception Handling, sondern ich würde nur sagen, wer nur die Exception in die Finger

46:16.640 --> 46:20.920
bekommt, solltest du da natürlich alle relevanten Infos rausbekommen und bei so einem Media-Error

46:20.920 --> 46:24.720
einfach die relevanten Infos der Codec passt nicht, finde ich ein bisschen wenig, weil

46:24.720 --> 46:28.960
man ja vielleicht wissen möchte, okay, wem passt denn der Codec nicht und die Information

46:28.960 --> 46:32.600
würde ich halt eben einfach nur mitgeben wollen, für dann besseres entweder Debugging

46:32.600 --> 46:36.960
oder besseres Exception Handling tatsächlich, aber jetzt nicht mit der Idee Events irgendwie

46:36.960 --> 46:41.880
zu ersetzen oder zu ergänzen, sondern einfach nur Exception Handling besser zu machen.

46:41.880 --> 46:47.200
Ja, also klingt gut auf jeden Fall, finde ich super.

46:47.200 --> 46:51.240
Okay, dann mache ich damit weiter.

46:51.240 --> 46:56.240
Und ich drücke, oder?

46:56.240 --> 46:59.240
Ja, auch nicht.

46:59.240 --> 47:01.880
Ich glaube, das hatten wir schon.

47:01.880 --> 47:06.880
CSS Adrules, Font Fades, hatten wir schon in irgendeinem Glücksrand.

47:06.880 --> 47:07.880
Bestimmt, okay.

47:07.880 --> 47:09.880
Ich drücke einfach nochmal, oder?

47:09.880 --> 47:11.880
Mach mal, merkt keiner.

47:11.880 --> 47:18.840
Aha, 3 Element Internals, Area Colspen.

47:18.840 --> 47:19.840
Jawoll.

47:19.840 --> 47:27.280
Genau, über Element Internals hatten wir im Kontext der WebKit-Folge, wo natürlich

47:27.280 --> 47:34.600
direkt danach wieder ein Release rausgekommen ist, gesprochen und jetzt muss ich mal darüber

47:34.600 --> 47:35.600
legen, das war...

47:35.600 --> 47:37.840
Ich wollte doch sagen, du hast ja so gut zugehört, dass du alles noch exakt beißt.

47:37.840 --> 47:39.840
Ich habe so gut zugehört, ja, richtig.

47:39.840 --> 47:47.560
Ja, ja, ich, okay, ich muss weg.

47:47.560 --> 47:48.560
Ja.

47:48.560 --> 47:59.200
Nee, aber im Prinzip kann man dann noch, im Prinzip die internen Verhaltensweisen, glaube

47:59.200 --> 48:00.200
ich, abbilden.

48:00.200 --> 48:06.840
Also wie fällt sich das im Accessibility Tree und welchem Element ähnelt das irgendwie

48:06.840 --> 48:07.840
von seinem Verhalten?

48:07.840 --> 48:08.840
So war das, glaube ich.

48:08.840 --> 48:15.000
Genau, das ist im Prinzip eine User-Facing-API mit der diversen Algorithmen aus der HTML5

48:15.000 --> 48:17.760
Spezifikation per JavaScript zugänglich gemacht werden.

48:17.760 --> 48:21.840
Das sieht man zum Beispiel, wie jetzt in dem konkreten Beispiel, einer Web-Komponent,

48:21.840 --> 48:25.880
die man frisch aus heißer Luft erschafft, irgendwelche Area-Defaults vergeben kann.

48:25.880 --> 48:29.520
Weil haben ja normale semantische Elemente auch irgendwie Section und Main und so, die

48:29.520 --> 48:30.800
haben ja eingebaute Area-Roles.

48:30.800 --> 48:33.640
Und warum sollte das irgendwie mein Custom-Flu nicht auch können?

48:33.640 --> 48:34.840
Und genau dafür ist das da.

48:34.840 --> 48:42.120
Also für solche Area-Defaults und für Custom-Form-Elements, dass man das Verhalten eines Formular-Elements

48:42.120 --> 48:43.520
mit einem Custom-Element nachbauen kann.

48:43.520 --> 48:44.520
Ja.

48:44.520 --> 48:49.080
Wir verweisen auf die entsprechende Revision, da wird das nochmal in Länge und Breite

48:49.080 --> 48:52.120
erklärt, weil der Safari kann das nämlich auch.

48:52.120 --> 49:01.360
Und jetzt haben wir hier noch ganz konkret das Area-Colls-Ben-Attribut, dass ich tatsächlich

49:01.360 --> 49:04.640
irgendwie, dass mir gar nichts sagt, dass ich noch Liebe nutzt habe.

49:04.640 --> 49:10.920
Also man kann da irgendwie sagen, wenn man jetzt keinen echten Calls-Ben irgendwie angibt,

49:10.920 --> 49:14.840
wie man das ja bei einer Tabelle machen würde, soweit ich das hier richtig verstehe, kann

49:14.840 --> 49:19.320
es halt für eine Zelle, die du vielleicht anders darstellt, zum Beispiel mit einem Diff

49:19.320 --> 49:26.760
oder whatever, da halt noch sagen, okay, das ist eigentlich gedacht hier über zwei

49:26.760 --> 49:35.520
Columns, also zwei Columns zu spannen, also sich aufzuspannen sozusagen und kann dann

49:35.520 --> 49:37.880
sozusagen diese Zelle ein Stück weit vergrößern.

49:37.880 --> 49:43.320
Man kennt das ja so sozusagen breitere Zellen, als die Standard breiten.

49:43.320 --> 49:49.720
Okay, das heißt so, der Use Case wäre vielleicht, dass man interagiert mit einer HTML5 Canvas

49:49.720 --> 49:57.440
und in der ist drin quasi so ein Art Tabellenartiges Ding, aber weil die HTML5 Canvas ja im Endeffekt

49:57.440 --> 50:02.640
nichts anderes ist als ein Haufen Pixel, ohne Semantik könnte man jetzt zum Beispiel überlegen,

50:02.640 --> 50:12.680
ob man im Hintergrund dann quasi sowas modelliert wie eine Tabelle und dann sowas nutzt und

50:12.680 --> 50:20.600
der Screen Reader würde dann im Prinzip dieses modellierte Objekt verarbeiten und würde

50:20.600 --> 50:23.880
dann die Semantik irgendwie kommunizieren können.

50:23.880 --> 50:31.200
Genau, oder viel einfacher, du baust ja irgendwie ein Haufen Custom Elements, um das neue Element

50:31.200 --> 50:37.560
der Shaptable mit Shaptable Row und Shaptable Header und so weiter in die Welt zu setzen,

50:37.560 --> 50:41.240
das sich halt eben verhalten soll wie eine Tabelle, aber soll halt irgendwie per Default

50:41.240 --> 50:44.440
sortierbar sein mit einem fixierten Header beim Scrollen und so weiter und so weiter.

50:44.440 --> 50:47.200
Also du willst halt eben alles haben, was eine Tabelle hat, aber du willst halt nicht gegen

50:47.200 --> 50:51.240
die Default Implementierung einer Tabelle in HTML ankämpfen müssen, fängst auf grüner

50:51.240 --> 50:55.440
Visa an wie ein guter Reaktentwickler das so macht, baust alles aus Diffs, aber weil es

50:55.440 --> 50:58.760
gleich ist es halt eben in Web Components ein und gibst dem halt eben auch noch Area Defaults

50:58.760 --> 51:01.920
damit es halt auch zugänglich ist und nicht nur schön aussieht.

51:01.920 --> 51:08.640
Ja, cool, wieder was gelernt, Area Callspan.

51:08.640 --> 51:15.280
Okay, dann bin ich glaube ich mal dran mit drücken, oder?

51:15.280 --> 51:20.080
Oder der Hans, ich glaube das könnte gar gar nicht, könnte der Hans sein, ja du darfst

51:20.080 --> 51:21.080
auch.

51:21.080 --> 51:24.720
Peter, ich lasse dir noch einmal den Vortritt, ich glaube ich war ja zuletzt mit dem Meta-Element

51:24.720 --> 51:25.720
am Start, ne?

51:25.720 --> 51:31.280
Ja, kann gut sein, okay, dann drücke ich jetzt mal auf Zufallsgenerator aktivisieren.

51:31.280 --> 51:37.160
Vielleicht war es auch falsch, ah ne, ich war bei Media Error, I don't know.

51:37.160 --> 51:40.120
Jetzt, wir haben wieder ein Element, fantastisch.

51:40.120 --> 51:46.160
Ja, es ist tatsächlich wieder ein neues Old Schoolige HTML-Glückrat, Glücksrat ist es

51:46.160 --> 51:47.160
wirklich.

51:47.160 --> 51:49.680
Fantastisch, ja.

51:49.680 --> 51:50.680
Es geht um ein...

51:50.680 --> 51:52.200
Ja, es hat zwei Element was.

51:52.200 --> 51:57.240
Einen hat zwei Element, genau, eine Überschrift sozusagen, also es gibt ja die Überschriften

51:57.240 --> 52:03.360
von 1 bis 6, h1 bis h6 und da sind wir jetzt auf dem zweiten Level gelandet.

52:03.360 --> 52:09.560
Ich finde es interessant, ich wollte das vorhin schon erwähnen, als wir so über die Abkürzungen

52:09.560 --> 52:19.080
gesprochen haben, ne, weil das h steht ja in dem Fall für Heading, Heading 1, Heading

52:19.080 --> 52:26.080
2, Heading 3 und bis 6, ne, und auch hier hat man sich nicht die Mühe gemacht, das

52:26.080 --> 52:31.880
Heading auszuschreiben, man hätte es ja dann auch anders interpretieren können, h1 bis

52:31.880 --> 52:38.480
6 oder, warum hat man es überhaupt Heading genannt und nicht Title, also so was wie T1?

52:38.480 --> 52:45.280
Title war schon besetzt, ja das Title-Tag gibt es ja schon und genauso den Het an sich.

52:45.280 --> 52:50.480
Ja, und dann blieb die Heading noch übrig und es heißt ja auch Überschrift, also von

52:50.480 --> 52:51.480
daher.

52:51.480 --> 52:56.840
Genau, ergibt irgendwie Sinn, ich finde das jetzt ja gut, dass irgendwer, also wenn

52:56.840 --> 53:02.880
ich da jetzt am Design dran gewesen wäre, ne, ich hätte halt wirklich nicht bei 6 aufgehört,

53:02.880 --> 53:07.520
sondern es hätte irgendwie eine ungrade Zahl sein müssen, einfach nur um so die Leute,

53:07.520 --> 53:09.720
die so was nicht gut aushalten können, so ein bisschen zu triggern.

53:09.720 --> 53:10.720
Ach so, einfach so.

53:10.720 --> 53:15.360
Weißt du, wer nicht h7 irgendwie viel netter gewesen?

53:15.360 --> 53:18.160
Ich finde ja ungrade Zahlen meistens auch schöner, tatsächlich.

53:18.160 --> 53:19.160
Okay.

53:19.160 --> 53:22.160
Heißt das auch, du würdest keine h2 verwenden?

53:22.160 --> 53:28.720
Okay, Spaß beiseite, aber was ist denn eigentlich, also wie kommt man auf 6 Level?

53:28.720 --> 53:32.560
Ich weiß nicht, wann ihr zuletzt eine h6 verwendet habt, ich weiß gar nicht mehr, wie ich das

53:32.560 --> 53:33.560
noch stylen soll.

53:33.560 --> 53:40.920
Also eine h4 ist doch schon so was wie einfach nur noch ein em als font-size sozusagen und

53:40.920 --> 53:41.920
font-weight-bold.

53:41.920 --> 53:48.080
Ja gut, aber du, Hans, baust ja auch tatsächlich vernünftige Webseiten, die irgendwie sagen

53:48.080 --> 53:52.840
wir mal ein kommerzielles Ziel verfolgen, die so von Max Mütze und Lieschen Müller verstanden

53:52.840 --> 53:53.840
werden sollen.

53:53.840 --> 53:57.160
Du baust ja nicht, wie das fürs WWW eigentlich vorgesehen war, dein komplettes Paper über

53:57.160 --> 54:00.640
Partikelbeschleuniger in eine Webseite rein, und zwar von A bis Z.

54:00.640 --> 54:05.840
Ist das nicht die gleiche Zielgruppe?

54:05.840 --> 54:12.040
Ja, okay, wahrscheinlich ist den Köln Lieschen Müller ein bisschen anders drauf als jetzt

54:12.040 --> 54:13.040
hierzulande.

54:13.040 --> 54:18.880
Nee, aber ich würde mal vermuten, dass es so irgendwie so, also irgendwie muss ja auf

54:18.880 --> 54:21.960
diese Idee gekommen sein, und ich bin sicher irgendwo steht das auch, wie das gekommen

54:21.960 --> 54:25.680
ist, aber vermutlich hat einfach irgendwer geschaut, was sind so das längste wissenschaftliche

54:25.680 --> 54:28.440
Paper, das ich hier rumliegen habe und wie viele Unterüberschriften hat das.

54:28.440 --> 54:32.760
So, das nehmen wir jetzt einfach mal als Worst Case an und dann passt das schon.

54:32.760 --> 54:40.600
Ja, ich könnte mir auch vorstellen, dass da noch ein bisschen was anderes dahinter liegt,

54:40.600 --> 54:45.520
aber vielleicht noch mehr Algorithmik, wie sieht das herausgefunden haben, aber vielleicht

54:45.520 --> 54:47.520
überschätze ich es auch an der Stelle einfach.

54:47.520 --> 54:52.880
Ich wüsste jetzt gern, was Chechipitit zu der Frage sagt, warum es bis H6 geht.

54:52.880 --> 54:53.880
Ja, ja bitte.

54:53.880 --> 54:55.400
Kannst du mal fragen gehen?

54:55.400 --> 54:56.400
Genau.

54:56.400 --> 55:04.680
Also ich kann nur sagen, ich finde schade, dass, also da, ich glaube das sind ja viele

55:04.680 --> 55:11.600
der Meinungen, dass der HTML5 Outline Algorithmus jetzt irgendwie nie so richtig Fuß gefasst

55:11.600 --> 55:20.240
hat, weil gerade wenn du so Komponenten basiert arbeitest, dann stellen dich ja diese blöden

55:20.240 --> 55:23.280
Haar-Levels immer vor total dämliche Herausforderungen.

55:23.280 --> 55:28.920
Du meinst damit nur ganz kurz, dass noch als Einschub, du meinst damit sozusagen, dass

55:28.920 --> 55:36.080
man dann so ein Section-Element um Headlines rappen kann und dann ist halt die H1 in dieser

55:36.080 --> 55:43.840
Section eigentlich untergeordnet der nächsterüberliegenden Section sozusagen, also so heißt es,

55:43.840 --> 55:44.840
kann man dann...

55:44.840 --> 55:51.680
Ja, beziehungsweise, genauso gibt es ja so Sectioning-Elements generell, glaube ich,

55:51.680 --> 55:57.920
sozusagen so Articles, Section, Header, Futter, Aside und so sind so Kandidaten und das dann,

55:57.920 --> 56:03.840
sobald der Browser da sozusagen in das Element eintaucht, dass dann die Überschriften-Levels

56:03.840 --> 56:09.200
wieder quasi resettet werden und wieder von vorne anfangen können, ohne dass sie dann

56:09.200 --> 56:15.040
eben, wie du ja auch richtig sagst, dann höher sind als die Überschriften, die außerhalb

56:15.040 --> 56:17.760
dieses Elements sind oder waren.

56:17.760 --> 56:26.760
Also es ist quasi so ein bisschen wie bei CSS mit den Z-Indexen, also wenn du quasi so

56:26.760 --> 56:31.920
ein Stacking-Context bildest, dann kannst du da drin ja Z-Index eine Million reinschreiben.

56:31.920 --> 56:38.840
Wenn der Stacking-Context selbst eben auf Z-Index 1 ist und du hast ein anderes Element, das

56:38.840 --> 56:46.560
hat Z-Index 2, dann wird dieses in dem Stacking-Context befindliche Element mit Z-Index 1.000 trotzdem

56:46.560 --> 56:53.880
niemals über diesem Z-Index 2 Element sein und so, wer halt der Outline-Algorithmus und

56:53.880 --> 56:58.160
das ist halt eigentlich ganz cool, weil dann kannst du, dann musst du ein CMS und deinen

56:58.160 --> 57:04.920
Komponentenbasiertes System einfach gar nicht wissen, auf welchem Level sind denn gerade

57:04.920 --> 57:10.120
die Headlines um mich herum, muss ich jetzt irgendwie vielleicht mit einer 4-Headline-Level

57:10.120 --> 57:15.000
4 konfiguriert werden, damit das Semantisches, sondern man könnte dann einfach sagen so

57:15.000 --> 57:22.000
hey, diese Komponente ist ohnehin vielleicht ein Artikel oder so und ich starte da einfach

57:22.000 --> 57:25.960
neu drin mit meinen Headlines und Problemen gelöst.

57:25.960 --> 57:35.280
Ich würde sagen so die Headline-Level sind auch immer so ein Painpoint bei mir, beim

57:35.280 --> 57:38.440
semantischen Zusammenstellen von Dokumenten.

57:38.440 --> 57:45.400
Ja vor allem, dass du halt eine saubere Outline immer hast, also den H1 noch hinzubekommen

57:45.400 --> 57:50.960
okay, dann die H2, da drunter auch noch irgendwie okay, aber dann fehlt doch mal vielleicht

57:50.960 --> 57:56.400
irgendwo ein und dann ist da eine H3 und dann ist auf einmal wieder irgendwo eine H4 ohne

57:56.400 --> 58:01.280
dass da vorne H3 war oder ähnliches, gerade bei User-Generated Content und das ist halt

58:01.280 --> 58:04.960
so ein bisschen das Problem, finde ich zumindest.

58:04.960 --> 58:13.240
Ja, ja genau, User-Generated Content ist auch so ein Kandidat in der Tat.

58:13.240 --> 58:21.720
Ja, was auch noch eine interessante Fahrgestellung ist, es gibt ja manche, die sind Verfechter

58:21.720 --> 58:32.160
der Position, wie viel, also ich kann mehr als ein H1 Element benutzen auf einer Seite,

58:32.160 --> 58:39.280
es gibt ja als quasi Ober-Guru, als Ober-Überschrift gibt es ja noch das Title-Element, also das

58:39.280 --> 58:44.720
ist ja die höchste Überschrift und warum sollte ich die vielleicht, also die wird sowieso

58:44.720 --> 58:49.680
announced vom Screenreader, warum soll ich die nochmal wiederholen in der einen H1, die

58:49.680 --> 58:57.040
es dann vielleicht gibt, macht nicht ganz so viel Sinn möglicherweise und darum quasi

58:57.040 --> 59:05.600
kann man direkt mit den Unterschriften zwei oder zweiten Grades mit H1 starten, so.

59:05.600 --> 59:08.600
Also die H1 ist die gefühlte H2?

59:08.600 --> 59:09.600
Ja, genau.

59:09.600 --> 59:16.160
Ja, ich frage mich immer, was das Bedrohungsszenario ist, also die irgendwie, wir überspringen

59:16.160 --> 59:21.800
irgendwie die H3 und gehen von der H2 zur 4, weil irgendwie unsere Widgets jetzt nicht

59:21.800 --> 59:26.400
optimal programmiert sind, weil wir den Outline-Algorithmus nicht haben, also wem tut das denn jetzt

59:26.400 --> 59:27.400
wirklich weh?

59:27.400 --> 59:28.400
Lass dich doch gerne.

59:28.400 --> 59:34.000
Ich glaube, das tut auch kein weh, also ich hatte auch mit dem Marco Zehl mal da drüber

59:34.000 --> 59:40.480
gesprochen, damals bei der Randschen Post, wie wir so quasi so, hey, hier sind noch ein

59:40.480 --> 59:45.760
paar Artikel-Empfehlungen und so, datte er auch gesagt, also für ihn wäre das eigentlich

59:45.760 --> 59:51.560
vollkommen in Ordnung, wenn das direkt als H6 alles ausgezeichnet würde und nicht irgendwie

59:51.560 --> 59:56.400
wir gucken, was wäre denn jetzt da für ein richtiges H-Level, ich glaube, wo das halt nur

59:56.400 --> 01:00:01.240
ein Problem ist, ist, wenn du das vielleicht an der Einstelle so machst, aber du hast an

01:00:01.240 --> 01:00:09.000
der anderen Stelle in deinem Dokument dann Headline-Levels, die von der Nummerierung

01:00:09.000 --> 01:00:14.320
dann höher sind, aber eigentlich nicht höher wären, also die funktionieren ja eigentlich

01:00:14.320 --> 01:00:19.880
nur, wenn du die Gesamt betrachtest und das alles in Einklang zu bringen, finde ich, das

01:00:19.880 --> 01:00:21.880
ist halt schon schwierig.

01:00:21.880 --> 01:00:26.880
Ja, also dass du nicht sozusagen unbeabsichtigt einen Schritt entweder nach oben oder nach

01:00:26.880 --> 01:00:30.320
unten machst, wenn du keinen machen willst, aber wenn du einen machst, ist es auch egal,

01:00:30.320 --> 01:00:32.880
dass du vielleicht irgendwie zwei Schritte nach unten machst oder zwei nach oben, solange

01:00:32.880 --> 01:00:33.880
die Richtung stimmt.

01:00:33.880 --> 01:00:40.520
Ja, genau, und sofern du das eben dann überall auf deiner Seite so durchziehst vielleicht.

01:00:40.520 --> 01:00:45.080
Ja, aber ich meine, möglicherweise ist es ja hilfreich, also die Idee, was du gerade

01:00:45.080 --> 01:00:49.920
sagst, ist von wegen, dann sind halt diese unwichtigsten Sections da hinten, die fangen wir halt mit

01:00:49.920 --> 01:00:52.960
H6 an, finde ich eigentlich jetzt nicht, weil dann könnte man ja im Prinzip die Überschriften

01:00:52.960 --> 01:00:58.000
Scala von 1 bis 6 im Prinzip ja als eine sehen, die man aus zwei Richtungen angreifen kann.

01:00:58.000 --> 01:01:03.600
Also ich könnte von H1 nach H2 nach H3 gehen und von sozusagen rückwärts gedacht von irgendwie

01:01:03.600 --> 01:01:08.600
nach 6 nach 5 nach 4 und könnte sozusagen sagen, okay, ich bin jetzt irgendwie so der

01:01:08.600 --> 01:01:12.160
Seitentitel und irgendwie so die Überschrift in der Hauptspalte und dann bin ich vielleicht

01:01:12.160 --> 01:01:16.560
nach H1 oder H2 und ich baue halt irgendein Widget und das Widget ist garantiert in irgendwas

01:01:16.560 --> 01:01:20.600
eingebaut, so dass unterwichtigste, unwichtigste, ganz, ganz nach hinten geschobene, da kann

01:01:20.600 --> 01:01:23.960
ich dann halt eben bei 6 anfangen und wenn ich dafür eine Überschrift brauche, eine

01:01:23.960 --> 01:01:27.640
5 nehmen, dass man das so aus zwei Richtungen zählt, das finde ich eigentlich ganz charmant.

01:01:27.640 --> 01:01:28.640
Mhm.

01:01:28.640 --> 01:01:29.640
Mhm.

01:01:29.640 --> 01:01:30.640
Mhm.

01:01:30.640 --> 01:01:31.640
Mhm.

01:01:31.640 --> 01:01:32.640
Mhm.

01:01:32.640 --> 01:01:33.640
Gut.

01:01:33.640 --> 01:01:37.280
ChatGPT hat gemeldet, ich habe ihn gefragt, wer hat da ein Mattas mit den Überschriften.

01:01:37.280 --> 01:01:41.680
ChatGPT meint, dass W3C hätte das per Konsens rausgefunden und es sei total wichtig, dass

01:01:41.680 --> 01:01:43.760
ich sehr darauf achte, alles ordentlich auszuzeichen.

01:01:43.760 --> 01:01:44.760
Ach, süß.

01:01:44.760 --> 01:01:48.960
Ja, ich sage mal, das ist nicht falsch, aber ich glaube nicht, dass das richtig ist.

01:01:48.960 --> 01:01:53.440
Ja, also, aber er hat schon sich reingehängt.

01:01:53.440 --> 01:01:57.240
Ja, ja, ich habe auch dreimal nachgefragt, ich habe so, ja, wer war das denn jetzt?

01:01:57.240 --> 01:01:58.240
Ja, wann denn?

01:01:58.240 --> 01:02:01.560
Er hat sich aber sehr gut drum herum geredet, also würde ich sagen, kriege ich auf jeden

01:02:01.560 --> 01:02:06.960
Fall locker eine gute 2, ohne Plus und Minus, hat bestanden.

01:02:06.960 --> 01:02:08.960
Ja, sehr gut.

01:02:08.960 --> 01:02:14.360
Genau, dann will ich noch eine Frage stellen, und zwar, was ihr zu AgeGroup sagt.

01:02:14.360 --> 01:02:16.440
Äh, gibt es da noch?

01:02:16.440 --> 01:02:17.440
Zu dem Element.

01:02:17.440 --> 01:02:23.480
Ja, das gibt es ja wieder, glaube ich, das wurde mal, es gibt hier, äh, quasi das

01:02:23.480 --> 01:02:24.480
AgeGroup-Element.

01:02:24.480 --> 01:02:25.480
Pst.

01:02:25.480 --> 01:02:26.480
Hier ist der Link.

01:02:26.480 --> 01:02:27.480
Ja.

01:02:27.480 --> 01:02:28.480
Und Chat.

01:02:28.480 --> 01:02:29.480
Ja, gibt's.

01:02:29.480 --> 01:02:35.960
Ähm, genau, das, äh, sollte ja so Überschriften zusammenfassen, ich glaube, in der ursprünglichen

01:02:35.960 --> 01:02:44.720
Fassung war es so gedacht, dass man verschiedene, glaube ich, Haar-Levels darin, äh, gruppieren

01:02:44.720 --> 01:02:51.320
konnte, und mittlerweile ist es, glaube ich, so, dass man nur einen Haar mit dann einem

01:02:51.320 --> 01:02:58.280
P zu einem, zu einer Heading-Group zusammenfassen kann, was dann quasi das Szenario wäre.

01:02:58.280 --> 01:03:04.760
Ich habe einen, ja, ein Kicker-Headline über der eigentlichen Überschrift, zum Beispiel

01:03:04.760 --> 01:03:10.560
unter der Hauptüberschrift runter und also quasi immer so eine, so eine Zweier-Gruppe

01:03:10.560 --> 01:03:16.640
von, ähm, Überschriften zusammen, wie man es halt oft dabei so Nachrichten, Seiten

01:03:16.640 --> 01:03:17.640
sieht.

01:03:17.640 --> 01:03:22.920
Das würde man, so benutze ich es auch.

01:03:22.920 --> 01:03:28.080
Es ist also ein Header-Element mit irgendwie einem etwas stricteren Content-Bottle.

01:03:28.080 --> 01:03:29.080
Ja.

01:03:29.080 --> 01:03:30.080
Genau.

01:03:30.080 --> 01:03:39.920
Hm, aber warum nimmt man denn kein Header-Element?

01:03:39.920 --> 01:03:44.440
Also, man kann ja trotzdem sich, man kann ja im Prinzip trotzdem dieses Content-Model

01:03:44.440 --> 01:03:50.160
umsetzen, aber warum muss man denn von einem, also, warum muss man sich einen Element begeben,

01:03:50.160 --> 01:03:53.120
wo das das Einzige ist, was valide ist, was ich am Ende auch keinen interessiert?

01:03:53.120 --> 01:03:55.360
Also, mir ist der Use Case nicht ganz klar.

01:03:55.360 --> 01:04:00.400
Also, okay, man kann dann irgendwie eine Zwischenüberschrift machen, ein Header ist ja ein

01:04:00.400 --> 01:04:03.480
Header von der Section und eine Age-Gruppe könnt ja auch irgendwo innerhalb einer Section

01:04:03.480 --> 01:04:06.440
als Zwischenüberschrift Gruppierung vorkommen.

01:04:06.440 --> 01:04:07.440
Hm, ja.

01:04:07.440 --> 01:04:08.440
Da stimmt.

01:04:08.440 --> 01:04:13.000
Wobei das mit den Section-Überschriften wahrscheinlich auch in jemandem interessiert,

01:04:13.000 --> 01:04:14.000
oder?

01:04:14.000 --> 01:04:18.640
Nee, ich glaube, dass, dass wir da irgendwie auch viel zu, also uns viel zu sehr den Kopf

01:04:18.640 --> 01:04:23.160
drüber zerbrechen und in der Praxis wird das eben, also einerseits wahrscheinlich, weil

01:04:23.160 --> 01:04:28.840
die Semantik im Web eh so kaputt ist, gar nicht so in der Form konsumiert, weil man gar nicht

01:04:28.840 --> 01:04:31.400
damit rechnet, dass es noch funktioniert irgendwo wahrscheinlich.

01:04:31.400 --> 01:04:43.400
Zum anderen habe ich auch hier und da mal schöne Vorträge gesehen, wo Leute mit, zum

01:04:43.400 --> 01:04:50.680
Beispiel, assistiven Geräten teilweise auch überfordert sind von zu viel Semantik.

01:04:50.680 --> 01:04:56.480
Das heißt also, den tut es da auch gar nicht unbedingt immer was Gutes, wenn du Tausend

01:04:56.480 --> 01:05:03.680
Listen hast und Tausend Überschriften, weil das halt alles announced wird und genau,

01:05:03.680 --> 01:05:11.760
also ich glaube, wir können uns da den Kopf heiß denken, wie man das am besten strickt

01:05:11.760 --> 01:05:16.880
und in der Praxis ist das alles gar nicht so relevant, tatsächlich.

01:05:16.880 --> 01:05:25.200
Ja, Ausschnitt davon sind relevant, damit halt eben die Use Cases, die Blinden und die Suchmaschinen

01:05:25.200 --> 01:05:26.200
zufrieden sind.

01:05:26.200 --> 01:05:31.320
Ja, also Formulare zum Beispiel, also da ist natürlich Semantik total wichtig, aber

01:05:31.320 --> 01:05:36.800
so beim Dokumenten modellieren vielleicht dann eben nicht so.

01:05:36.800 --> 01:05:41.920
Es wird nicht so heiß gegessen, wie es gekocht wird.

01:05:41.920 --> 01:05:50.120
Genau, also kann man sich viel Gedanken machen, vielleicht können wir da auch noch mal ein

01:05:50.120 --> 01:05:56.240
letztes Mal unsere Höhren und Höhre fragen, wie ihr euch da so durchnavigiert, was ihr

01:05:56.240 --> 01:05:59.440
so für euch für Best Practices rausgearbeitet habt.

01:05:59.440 --> 01:06:06.480
Seid ihr da irgendwie sehr strikt, also so quasi geht ihr nach Lehrbuch oder habt ihr

01:06:06.480 --> 01:06:12.000
da, geht ihr da ein bisschen, sagen wir mal, Hemdsärmeliga oder vielleicht irgendwie aus

01:06:12.000 --> 01:06:19.280
der Praxis getrieben heran und wie löst ihr so Probleme wie eben Content Management Systeme,

01:06:19.280 --> 01:06:29.080
User Generated Content oder eben Komponenten basierte Webseiten und Überschrift Levels

01:06:29.080 --> 01:06:30.080
und so.

01:06:30.080 --> 01:06:39.080
Und ja, ich würde sagen, damit haben wir wieder eine schöne runde Glücksrat hier eingetütet.

01:06:39.080 --> 01:06:43.800
Genau, was auch keiner mitbekommen hat, ist, dass der Peter insgesamt fünfmal rausgeflogen

01:06:43.800 --> 01:06:45.400
ist und der Hans einmal.

01:06:45.400 --> 01:06:49.440
Ja, das ist doch alles gar nicht wahr, das lief genauso rund wie ein Glücksrat, deswegen

01:06:49.440 --> 01:06:50.960
heißt das doch so.

01:06:50.960 --> 01:06:51.960
Ja, stimmt.

01:06:51.960 --> 01:06:55.880
Du bist eigentlich fast so oft rausgeflogen, wie wir Runden gedreht haben.

01:06:55.880 --> 01:06:59.760
Das ist richtig, jedes Mal, wenn ein neues Thema war, bin ich erstmal so, ich muss

01:06:59.760 --> 01:07:00.760
weg.

01:07:00.760 --> 01:07:06.320
Ja, aber auf jeden Fall ist es nicht zu vergleichen mit den alten Zeiten, als wir noch Skype benutzt

01:07:06.320 --> 01:07:07.320
haben.

01:07:07.320 --> 01:07:08.320
Also, sofern.

01:07:08.320 --> 01:07:13.680
Ich erinnerte mich an so Show Notes von Markus, wo es noch so hieß, Thema hier, Thema da

01:07:13.680 --> 01:07:17.880
und übrigens, ich klinge, als hätte ich eben in einer Mülltonne aufgenommen, vertraut

01:07:17.880 --> 01:07:20.080
mir, so war das nicht.

01:07:20.080 --> 01:07:23.920
Nein, nein, das schneiden wir alles raus.

01:07:23.920 --> 01:07:35.480
Ansonsten, wenn ihr noch was habt, wie gesagt, schreibt uns auf Twitter auf, Mastodon oder

01:07:35.480 --> 01:07:36.480
im Slack.

01:07:36.480 --> 01:07:41.920
Die Kommentare sind ja schon ein bisschen länger zu, weil da eigentlich nur Spam reinkam.

01:07:41.920 --> 01:07:51.320
Genau, nächste Woche geht es um, genau, da geht es um TypeScript 5 und danach die Woche

01:07:51.320 --> 01:07:58.680
geht es um eine spannende neue Organisationsstruktur mit einem Gast und den Gast von dieser Folge.

01:07:58.680 --> 01:08:07.200
Da gucken wir mal den geplanten Gast, wenn wir den dann hier tatsächlich für eine Sendung

01:08:07.200 --> 01:08:08.200
zu Gast haben werden.

01:08:08.200 --> 01:08:10.800
So machen wir es.

01:08:10.800 --> 01:08:11.800
Danke euch.

01:08:11.800 --> 01:08:16.480
Vielen Dank, dass ihr wieder euer Wissen geteilt habt, was das Glücksrat anbelangt.

01:08:16.480 --> 01:08:21.760
Manchmal sind es ja dann doch etwas älterere Themen, aber es ist doch immer mal wieder

01:08:21.760 --> 01:08:26.760
gut, die auch mal wieder aufzufrischen vom Wissen her und man lernt ja dann doch immer

01:08:26.760 --> 01:08:27.760
viel dazu.

01:08:27.760 --> 01:08:34.080
Zum Beispiel heute die Stereo-API, mit der man da links oder rechts ausgeben kann vom

01:08:34.080 --> 01:08:39.040
Ton, ist dann doch schon auch interessant und vielleicht, man weiß es ja nie, irgendwann

01:08:39.040 --> 01:08:41.280
braucht man es dann doch mal.

01:08:41.280 --> 01:08:43.480
Ja, hast recht.

01:08:43.480 --> 01:08:45.480
So ist es.

01:08:45.480 --> 01:08:50.280
Also macht's gut und bis nächste Woche, tschüss!

01:09:15.480 --> 01:09:20.200
Beep. Beep. Beep. Beep. Beep.