Wo wir sind ist vorne Folge 71, wie man sich embeddet, so liegt man.
Herzlich willkommen bei Wo wir sind ist vorne Frontend-Fakten-Frotzelein,
der Late-Night-Frontend-Talkshow rund um Webdesign und Entwicklung.
Es reden sich um Head und Kragen, HTML-Fundamentalist Moritz Glanz und JavaScript-Jongleurin Sarah
Häusler.
Ja, ich bin Moritz und mir gegenüber die Welt.
Nein, da draußen an den Geräten, an den Empfangsgeräten, die Welt.
An den Volksempfängern.
Nein, ihr hört uns natürlich über eure Podcast-App vielleicht hoffentlich.
Im Auto oder auf Kopfhörern oder wie auch immer.
Hoffentlich in besserer Qualität als früher auf den Volksempfängern das Radio empfangen
werden konnte.
Sonst machen wir uns diese ganze Mühe ja völlig umsonst, weil wozu hab ich, also,
dann kann ich auch in die Zigarettenpackung reinsprechen, wenn wir das als Qualitätsmerkmal
haben wollen.
Brauche ich kein damals 400 Euro teures Mikrofon oder so, oder was das gekostet hat.
Ja, Mensch, es ist mal wieder Podcast!
Ja, es ist doch wieder ein bisschen länger her, wir schaffen es nicht so ganz unser Vorhaben
so durchzusetzen mit der engeren Rotation, aber immerhin ist Regelmäßigkeit schon halbwegs
erkennbar im Vergleich zu dem, was wir vorher haben schleifen lassen.
Genau.
Und ich fand deinen Introspruch auch gar nicht so schlecht, ich hatte ja mit Schlimmerem
gerechnet, aber das fand ich echt gut.
Ja, ich hab vorher ein bisschen drauf rumgedacht auf unserem Thema heute und dann kommen manchmal
so Sachen in meinen Kopf.
Ich hab auch noch überlegt, doll legst du die nieder?
Aber egal, ihr wisst ja noch gar nicht, worum es geht, deswegen ist das vielleicht noch
ein bisschen wolkig, aber ihr werdet es ziemlich sicher, nein, aber ihr werdet es dem Sendungstitel
schon entnommen haben, wahrscheinlich, wenn ihr die Folge hört, das heißt, das, was beim
Intro gelabert wird, ist eigentlich gar nicht so wichtig.
Genau, ich komme zum Thema Getränk und ich hab heute in Ermangelung an Alternativen heute
noch mal meinen Whisky rausgekramt, den gibt's jetzt heute.
Es ist natürlich unter der Woche, da muss man aufpassen, was man macht.
Genau, aber hier gibt es wieder einen schönen Scotch, den habe ich schon öfter getrunken,
muss ich jetzt nicht noch mal genau sagen, welches es ist, ich mag ihn immer noch gerne.
Ja, ich halte mich ans gute alte Dehydrogenmonoxid, hab mir einfach nur Wasser heute unter der
Woche hingestellt.
Wir versuchen ja eigentlich sonst immer freitags aufzunehmen, das hat diesmal nicht so ganz
geklappt und ich muss ja zurzeit immer morgens recht früh raus und deswegen versuche ich
da einen klaren Kopf zu behalten.
Mensch, das weiß ich gar nicht, was das sein soll.
Also, so klar wie es bei mir halt wird, meine ich damit.
Achso.
Also nicht noch weiter vernebeln als eh schon.
Ah, okay.
Okay.
Dann können wir direkt wieder retro starten, oder?
Korrekt.
BBCV präsentiert die Retrospektive!
Und dann mache ich den Anfang.
Ich habe ja schon drüber erzählt, dass ich da so ein bisschen rumgebastelt habe mit Scan
Server für Home Assistant und ich dachte jetzt, ich mache jetzt schon so lange dran
rum und habe halt zwischendrin nicht wirklich viel gemacht, beziehungsweise so an Details
gefiled, dass nicht wirklich was vorangegangen ist, aber es funktioniert jetzt so für meinen
Einsatzzweck schon relativ gut und ich habe gedacht, ich poste jetzt einfach mal auch
die Links zu den Repositories und Benutzung auf eigene Gefahr.
Wie gesagt, Links zur GitHub kommen raus, kommen in die Shownotes, Scan Server, Add-on
für Home Assistant und das basiert auf einem Base-Image, das ich angepasst habe, also das
Debian-Docker-Base-Image für Home Assistant-Add-ons, das ich einfach erweitert habe, um Scene-D
und Scan-BD zu ermöglichen, damit einfach der Bild von dem Add-on selbst dann ein bisschen
schneller verstanden geht.
Ja, und was das Ding macht ist, ich fahre es hoch, das Add-on startet, ich kann auf
den Knopf an meinem Scanner drücken und es scannt mir das Ganze im Netzlaufwerk und damit
kann ich schon mal sehr gut arbeiten, also ich muss halt nicht mehr irgendwie da an dem
Gerät stehen und irgendwie drauf drücken und auswählen, scanne mir das auf mein NRS
und so weiter, wie ich das bisher musste, sondern ich habe diesen Einzugs-Scanner, der
steht jetzt aktuell auch oben in der Wohnung und nicht mehr hier im Büro und wenn ich
ein neues Dokument habe, lege ich das einfach ein, drücke auf den Knopf und das Ding scannt
und ich habe es an der richtigen Stelle liegen und kann von dort aus dann was machen, das
macht sogar ein OCR automatisch drüber.
Und jetzt hat auf die letzte Folge, wo ich das schon mal vorgestellt habe, hat der Lippe
einen Kommentar geschrieben, also es kam übrigens generell auch wieder einige Kommentare zu
den Folgen, zu den vergangenen und natürlich auch vom Shep, der Shep schreibt ja sehr oft
bei uns dann auch längere Kommentare drunter mit vielen wichtigen Informationen, aber ganz
kurz noch zu dem Konkreten, dann können wir darauf eingehen, der Lippe hat was empfohlen,
Paperless NGX und das hatte ich mir auch schon angeschaut, das ist so ein Tool oder Toolkit,
was man, ich glaube es läuft auch über Dockercontainer, wenn ich das richtig habe, ich habe es mir
noch nicht so tief angeschaut, aber man hat da im Endeffekt eine Dokumentenverwaltung,
also es kann auch OCR, wenn man die Sachen nicht eh schon OCR drübergejagt hat und kann
auch so Sachen wie, ich versehe Dokumente mit Tags oder in bestimmte Kategorien ordne
ich die ein oder eben auch per KI werden Tags automatisch vorgeschlagen oder hinzugefügt
zu den Dokumenten, da habe ich jetzt allerdings noch nicht geschaut, das möchte ich im zweiten
Schritt dann auch auf Home Assistant umsetzen oder vielleicht sogar optional in das Plugin
integrieren, aber ich weiß nicht wie die Performance z.B. jetzt auf einem Raspberry
Pi ist, um da per KI über irgendein Modell irgendwelche Tags hinzuzufügen und auch mit
Mehrsprachigkeit und so weiß ich natürlich nicht, das werde ich mal noch ausprobieren
wenn ich dazu komme und dann sage ich da auch Bescheid und bau das dann rein.
Habe ich schon öfter gehört, dass das cool sein soll und einige Leute benutzen das.
Ich muss nur immer so ein bisschen kichern, wenn ich von irgendwas höre, was NG heißt.
Ja, ja, ja.
Also ich meine es ist ja mittlerweile, werden ja da auch mit oft Angular Sachen gemeint
und ich glaube das ist in dem Fall auch gemeint, aber wenn NG nicht mehr reicht, dann muss
man noch was anderes hinzufügen, dann macht man halt noch ein X hinten dran.
Ich habe jetzt gerade nochmal, weil es mich jetzt interessiert hat, ich habe mich gefragt,
wann hat man denn eigentlich angefangen, Sachen NG zu nennen, weil ich finde es ein bisschen
lustig, etwas Next Generation zu nennen, weil NG ist halt auch irgendwann mal alt und es
gibt dann was Neueres, aber dann heißt das alte immer noch Next, also es ist ja immer,
die Formulierung impliziert ja, dass das immer einen Schritt voraus ist und das finde ich
ein bisschen witzig.
Jetzt habe ich hier, also Chat-GPT muss ich jetzt sagen, natürlich kann es halluzinieren,
aber es klingt gar nicht so abwegig, also Next, das Ding Next Generation heißen ist
schon aus den 60er oder 70er Jahren aus Militär und Luftfahrt bekannt, allerdings nicht so
mehr mit, nicht NG, es gab auch irgendwie von IBM mal was, was Next Generation hieß
oder Next Gen Konsolen, Spielekonsolen, aber angeblich hat Star Trek The Next Generation
den Begriff populär gemacht so richtig und ich finde es so ein bisschen, also bei Star
Trek stimmt es ja, weil es war ja vom Original Star Trek aus die Next Generation, da ist es
sehr treffend, da ist es nicht so ein random, ich bin jetzt halt neuer als das alte, aber
so wird es halt oft irgendwie verwendet.
Ich finde es macht Sinn zum Beispiel für einen Alpha Branch oder von mir aus auch Beta
Branch oder halt irgendwie so eine Vorab-Version von dem, was kommt, wo vielleicht noch nicht
so alles ganz ausgereift ist, aber dass das halt immer, also das ist wirklich immer so
das Nächste und was dann dem Next in der Stable-Version kommt, da macht das Sinn, aber
klar jetzt irgendwie ein finales Produkt Next Generation zu nennen und dann die Generation
weiter dann über Next.
Die haben alle irgendwie so, also ich habe jetzt gerade an Browser gedacht, die haben
lauter so verrückte Namen, also bei Chrome heißt es ja Canary, genau das was du gerade
gesagt hast, gibt auch irgendwie Beta oder so, aber Canary ist glaube ich so das ganz
Neueste.
Da sind dann auch Dinge drin, die es zum Beispiel in die Beta noch gar nicht schaffen oder
so, ne?
Bei Firebox sind es die Nightly-Bits, das kann man auch noch, also ja, kann man auch
noch.
Ja, wobei es von Chromium gibt es ja auch Nightlys, das ist auch wieder was anderes,
Canary ist dann nochmal so, da werden dann die Nightlys so nochmal fixiert, irgendwie,
ja?
Auf einen halbwegs stabilen Stand.
Ja, also es macht natürlich keinen Sinn, das so zu nennen, aber das Ding an sich sieht
echt cool aus und ich werde mich damit auch noch beschäftigen, es ist halt wirklich so,
wie der Name sagt, paperless, also ich will meinen ganzen Papierkram loswerden und eigentlich
die Dinge einmal einscannen und kann dann halt auch danach sortieren, welche, ja, Correspondent,
also von welcher Versicherung kommt es jetzt oder so und hab dann alles schön organisiert
und das ist natürlich grad für Menschen wie ich, die so verplant sind und in dieser
Zettelwirtschaft ertrinken, ist das natürlich total cool.
Genau.
Ja, so.
Ja, dann zum Kommentar, genau, da kannst du vielleicht noch was dazu sagen.
Da sag ich noch was zu, weil, also da war, also es ging um die letzte Folge, wo wir über
Video und Audio gesprochen haben und ich bin ja froh, dass der Shep im Prinzip nur so eine
super Spezialgeschichte kommentiert hat, das heißt, wir lagen nicht so komplett falsch
mit dem Rest, den wir gesagt haben, aber eine Sache daraus, also der Kommentar, den werden
wir auch verlinken, kommt in die Show Notes, eine Sache daraus, die fand ich besonders
bemerkenswert, weil ich davon noch nie was gehört hatte und zwar der Media Engagement
Index und zwar ging es um Autoplay, der Play-Methode auf Videos, welche Seiten dürfen das und
welche nicht, so und wir haben ja mal gesagt, naja, nach Interaktion und so, was der Shep
jetzt aber geschrieben hat, ist, dass der Browser quasi buchführt, wie oft ich auf
einer Seite irgendwie schon Play gedrückt habe sozusagen und je nachdem, wie oft, das
ist im Vergleich zu, wie oft ich die Seite aufrufe, wenn das besonders oft ist, dann
darf die Seite irgendwann Autoplay machen und was total abgefahren ist, das habe ich
jetzt gerade eben mal aufgerufen bei mir, in Chrome oder auch in Brave, also Chromium
basierten Browsern gibt es dieses Chrome Doppelpunkt Slash Slash Media Engagement, das ist eine
Seite, die habe ich gerade mal aufgemacht, bei Brave ist das halt Brave Doppelpunkt,
in Edge ist es wahrscheinlich Edge Doppelpunkt und da habe ich tatsächlich eine Tabelle,
wo alle möglichen Seiten, auf denen ich Media Playback gemacht habe, ich weiß nicht genau,
wie weit es zurückreicht, es kommt mir irgendwie so vor, als ob das nicht alles gewesen sein
kann.
Bei mir ist es relativ wenig, aber es ist halt auch meine Windows Instanz.
Es sind aber Seiten dabei, wo ich mir sehr sicher bin, dass ich die schon lange nicht
mehr auf hatte, also, obwohl, nee, warte mal, Last Playback, das geht nur bis 2024 zurück.
Okay, keine Ahnung, wie lange der, ich weiß gar nicht, ob das irgendwo definiert ist,
ob da die Zeit, in der das eine Rolle spielt, auf jeden Fall habe ich mal sortiert jetzt
nach Sessions with Playback und da habe ich, YouTube ist bei mir da natürlich ganz oben,
1974 Sessions insgesamt und 1282 davon mit Playback, also das ist ein relativ guter,
da kommt ein Score von 0,65 raus, das ist extrem hoch.
Bei ZUNO habe ich noch einen höheren Score, nämlich von 0,85, 27 Sessions, 23 mit Playback,
klar ZUNO ist halt die Musikenergierungs-AI, das ist super interessant, das ist hässlich
wie die Nacht, aber es tut seinen Zweck, also das ist total abgefahren, also das ist eine
interessante Statistik, die ich nicht, überhaupt nicht kannte, auch gar nicht, dass man darauf
zugreifen kann.
Man schreibt halt auch hier genau die Zahlen, also wenn das über 30% sind der Seitenbesuche,
die zum Abspielen geführt haben, dann kommt das auf eine interne Allow-List für Autoplay
mit Ton und fliegt wieder raus, wenn es 20% unterschreitet, also das ist echt interessant.
Also bei mir sind das dann, also das wäre dann in dem Fall der Score bis zu 0,3, da
kann ich mal genau vorlesen, das sind genau 4, 5 Seiten bei mir, die das, die quasi das
machen dürfen, Zuno, YouTube, TikTok interessanterweise, obwohl ich da eigentlich nie drauf bin, aber
offenbar habe ich da auf Play gedrückt, ZDF und adad-mediathek.de und alle anderen haben
einen Score unter 0,3, also unter 30%.
Man sieht auch oben so ein Setting, eine Übersicht über verschiedene Settings, wo dann drin
steht zum Beispiel minimale Sessions, die man braucht, damit es überhaupt greift und
eben diesen Threshold von 0,2 und 0,3 kann man wahrscheinlich auch bei About Config oder
so, kann man das bestimmt auch noch irgendwie fine-tunen, wenn man das möchte.
Aber jetzt stell dir vor, du weißt nichts von dieser Geschichte und du gehst auf eine
Seite und auf der einen Seite kannst du Autoplay machen, auf der anderen Seite nicht debuggen
das mal.
Ja, das ist schon seltsam dann, ja.
Das ist echt abgefahren.
Okay, aber wieder was gelernt.
Es ist wieder, die Welt ist voller Mysterien, die noch entdeckt werden müssen und es hört
einfach nicht auf.
Und der Shep hilft uns dabei.
Und der Shep hilft uns dabei, vielen Dank, Shep.
Aber Shep ist, glaube ich, auch treuer Hörer, also ich weiß, dass seine Queue lang ist,
das schreibt er auch immer mal wieder, also er ist nicht immer ganz tagesaktuell, aber
wer ist das schon?
Wenn ihr tagesaktuell diese Folge hört, an dem Tag, wo sie rauskommt, dann gerne mal
einen Kommentar schreiben, dann kriegt ihr ein Extra-Blümchen oder so was, ich weiß
noch nicht genau, einen Sticker oder einen Stempel, so wie man es halt früher in der
ersten Klasse, ihr wisst ja, Schmetterling oder so.
Ja, wo wir schon bei netten Sachen sind, ihr seid super nett, und zwar gab es einige Kofi-Unterstützung
an uns.
Mittlerweile, ich weiß gar nicht, habe ich in der letzten Folge schon gesagt, wir haben
mittlerweile da auch Leute, die uns tatsächlich regelmäßig unterstützen.
Jemand hat zum Beispiel gesagt, er hat sein Twitch-Abo nach Kofi umgezogen, was ich sehr
schön finde, vor allem bei Kofi, also jetzt mal abgesehen davon, dass wir jetzt gerade
keinen Twitch mehr machen, bei Kofi haben wir auch mehr davon.
Also, wer nicht weiß, was Kofi ist, das ist so eine Spendenplattform, die ist über Paypal
angebunden und wenn ihr da was spendet, dann landet das zu fast außer das, was Paypal
uns davon wegnimmt, was ein kleiner Teil ist, kommt es dann auch alles bei uns an, nicht
so wie bei Twitch.
Wenn man bei Twitch ein Abo abgeschlossen hat, dann haben wir nur die Hälfte von dem
Geld gekriegt.
Genau, wofür hilft es uns für unsere viel zu teure Top-Level-Domain, die wir für unseren
Podcast haben, wenn bei uns an Audio-Equipment noch was gebraucht wird und so weiter.
Wir haben ja auch schon immer mal wieder Verlosungsaktionen gemacht, wo wir T-Shirts dann oder sowas
verlost haben.
Wir kaufen davon Sticker und allen möglichen Kram.
Es ist also gut investiertes Geld, wenn ihr uns da was spendet.
Und wir haben auch noch, ich weiß jetzt nur nicht, ob wir es namentlich erwähnen, ob
das gewünscht ist, deswegen mache ich es mal anonym, da haben wir nämlich auch noch
gar nicht drüber gesprochen, wir beide.
Wir haben auch einen Amazon-Gutschein noch bekommen, auch in bedeutsamer Höhe, sag ich
mal.
So, hier ist mein Jahresbeitrag, das fand ich auch total lieb.
Also vielen lieben Dank, wenn du das hörst, ich weiß, dass du zuhörst auch regelmäßig
und ja, vielen lieben Dank dafür nochmal.
Das ist endlich jetzt mal die Gelegenheit, mir dieses Wenger Schweizer Taschenmesser
zu bestellen mit den 700 Funktionen.
Nein, Spaß.
Müssen wir noch drüber reden?
Genau, ja, vielen, vielen Dank an dieser Stelle nochmal dafür.
Genau, also da kommt einiges rein, wir freuen uns da sehr drüber, es tut uns leid, dass
wir nicht so regelmäßig sind, aber das ist quasi, was entschuldige ich mich eigentlich
noch dafür?
Das ist ja mittlerweile eigentlich fast das Programm.
Ich finde es trotzdem wahnsinnig toll, dass ihr uns trotzdem, und ihr wisst es ja mittlerweile,
dass das bei uns ein bisschen chaotisch ist und wir gegen die erste Regel von Nikolas
Wörl verstoßen hier regelmäßig, nämlich der Podcast muss regelmäßig kommen.
Also wir verstoßen mit Regelmäßigkeit gegen diese Regeln.
Immerhin.
Darauf ist Verlass.
Nein, immerhin.
Ihr könnt euch darauf verlassen, dass ihr euch nicht auf uns verlassen könnt, aber
irgendwann kommt dann doch was, so wie jetzt, jetzt, heute, also an diesem Tag, wo ihr das
jetzt hört.
Genau, also vielen, vielen, vielen Dank für die ganzen Spenden.
Wenn ihr da denkt jetzt, oh ja, irgendwie so ein Euro pro Folge klingt jetzt irgendwie
nach einer guten Idee oder ich würde gerne auch mal was beitragen oder hey, wir haben
dich jetzt hier irgendwie gut unterhalten, dann kannst du, wenn du es ganz schnell machen
willst, auf www.siv.de-spende gehen, dann wirst du weitergeleitet auf die jeweils aktuelle
Spendenseite.
Momentan ist das eben dieser Dienst Kofi bei uns, da kannst du mit Paypal Geld einwerfen.
Ich weiß gar nicht, ob das anders auch geht, das habe ich noch nie ausprobiert, aber ich
glaube mit irgendwie Karten gedöhnt.
Ich glaube, man kann ja bei Paypal auch teilweise, das ist auch so ein komisches Prinzip, glaube
ich, mit diesem Media Engagement Index, ob man das darf oder nicht, ohne Account ausgelockt
mit Kreditkarte zahlen.
Das geht manchmal, manchmal nicht, weiß ich nicht, von was das abhängt, teilweise von
der besuchten Seite oder von dem, an den das Geld geht, ich weiß es nicht, oder die eigene
Vertrauenswürdigkeit, keine Ahnung.
Achtung, jetzt kommt's.
Also es geht Paypal, es geht Debit oder Kreditkarte und es geht sogar SEPA Lastschrift, steht
hier.
Also das ist natürlich sehr cool, ich nehme mal an, weil wenn ihr SEPA Lastschrift macht,
dann könnte es sein, dass es nicht mal irgendwelche Gebühren kostet.
Also wenn ihr Paypal macht, dann gibt es, ach ne Moment, ich denke gerade falsch, weil
das Geld am Ende auf Paypal, über Paypal zu uns kommt und da wird noch was abgezogen.
Achso, ja.
Aber vielleicht kann man das auch ändern, wenn die mittlerweile SEPA haben, muss ich
mal gucken.
Aber ich glaube dann, ja das ist halt super bequem.
Also es gibt verschiedenste Wege und wir würden uns sehr freuen darüber, weil wir dann hier
weitermachen können, uns Equipment reparieren können, keine Ahnung, was halt so anfällt.
Wie gesagt, unsere Top-Level-Domain, die ist viel zu teuer.
Ihr könnt ja mal gucken, was eine Punkt-Show-Domain kostet.
Ich meine, das ist jetzt kein Vermögen, aber es ist was anderes als eine DE.
Im Vergleich.
Also ich habe jetzt bei, wie heißt es, NetCup, in so einem Deal, meine Domain, die ich letztes
Mal auch genannt habe, da zahle ich jetzt irgendwie 17 Cent im Monat für die Domain,
weil das so ein Special-Angebots-Dings war.
Und da kommen wir natürlich mit unserer Show-Domain bei weitem nicht hin.
Nee, ich würde sogar sagen, das ist Faktor 15 oder so teurer.
Ja.
Habe ich jetzt mal so grob im Kopf ausgerechnet.
Okay.
Gut.
Ja, der nächste Punkt, oder wolltest du noch was Abschließendes sagen?
Nein, nein.
Der nächste Punkt passt eigentlich auch so ein bisschen dazu, weil ihr macht das vorbildlich
so mit der Unterstützung, mit dem was zurückgeben.
Und ich habe so einen kleinen Vent, ein eigentlich altbekanntes Problem, das wir jetzt auch mit
diesem Vent nicht lösen werden, aber ich, weil es in den letzten Tagen immer mal wieder
akut war, sage ich mal, wollte ich das einfach jetzt auch nochmal ansprechen.
Und zwar, ich bin ja jetzt eh so ein bisschen aus diesem ganzen Programmier-Ding so ein
bisschen raus.
Aber ich würde schon gerne in meiner Freizeit noch so ein bisschen Open Source Projekte
weiterentwickeln und unterstützen und ich bin ja da auch Codemaintainerin von OpenType.js,
habe ich auch ganz oft schon hier drüber gesprochen und gerade in letzter Zeit kommen wieder ganz
viele neue Issues und oft ist das Problem, es gibt im Mainbranch eine Version, die kann
man auch online, in der Demo ist das die gleiche Version, die da halt dann als Build angezapft
wird.
Die ist halt deutlich weiter als das, was zuletzt released wurde vor keine Ahnung mittlerweile
zwei, drei Jahren oder was.
Also das ist eine uralte Version, auch auf NPM und sowas, die 1.3.4 und die kann zum
Beispiel keine Variable Fonts und keine Color Fonts und so weiter.
Das kann aber OpenType.js mittlerweile alles, nur halt eben in dieser noch nicht offiziell
releast Version.
Und das ist halt so, ich bin da im Moment gerade die Einzige, die da überhaupt noch
irgendwie Zeit investiert, sprich es kommen Issues und ich antworte wenigstens nach ein
paar Tagen oder so drauf und versuche zu helfen und oft ist es halt eben, ja probier doch
mal die aktuellste Version und nicht das letzte Release, dann hat sich das oft schon erledigt.
Aber halt auch Feature Requests und so weiter.
Und das ist irgendwie so ärgerlich, weil ich würde da gerne mehr rein investieren,
aber bei einem Projekt von der Größe und dem Umfang ist es halt zurecht so, dass also
jedes Pull Request braucht ein Review, d.h. die eigenen Sachen, die ich anbiete, die hängen
teilweise monatelang, hängen die da fest und es passiert nichts und es kommt nie in
die Version.
Klar, ich könnte sagen, ja scheiß drauf, ich merge das jetzt trotzdem, aber ich will
ja eigentlich, dass jemand dann nochmal drüber guckt, weil ich weiß, dass ich keinen fehlerfreien
Content produziere unbedingt und auch so Sachen, die einfach eine grundsätzliche Designentscheidung,
nicht im Sinne von Design, sondern Code Design oder Projektentwicklung angehen, so in welche
Richtung gehen wir denn, oder wie machen wir das, das gibt irgendwie 5 verschiedene Lösungsansätze,
welchen wollen wir denn, wollen wir das irgendwie modular machen oder als Plugin sogar anbieten
oder keine Ahnung was, das will ich gar nicht allein entscheiden, ich möchte eigentlich,
dass da möglichst viele Köpfe irgendwie sich zusammentun und das ist halt einfach
alles blockiert, dadurch, dass ich halt da komplett alleine aktuell überhaupt irgendwas
dran mache und ich finde das so schade, weil ich hätte gerne mal, ich würde zumindest
mal gerne den aktuellen Stand als aktuelles Release releasen oder sowas und das ist so.
Darfst du, könntest du das denn, kannst du ein NPM Release bauen, da hast du die Rechte
dazu.
Ich meine, dass der ursprüngliche Maintainer das als Token, als CQ, also so, dass ich es
nicht einsehen kann, aber es wird im Hintergrund über so ein Workflow, wird es getriggert,
ich könnte es, glaube ich, auf NPM pushen, aber die Version ist halt noch nicht ganz
so weit.
Es gab so ein paar Milestones, die wir drin haben wollten und die Doku müsste nochmal
geguckt werden, dass da wirklich alles aktualisiert ist und so mit den ganzen API-Änderungen
und ich schaff das aber halt einfach nicht alleine und das wäre halt, wenn jetzt jemand
sagen würde, er, sie sponsert irgendwie Arbeitszeit pro Monat oder sowas, ja, dann würde ich,
dann könnte ich das eher irgendwie machen, dass ich dann sage, okay, ich mach das jetzt
wirklich als Nebenberuf quasi, dass ich daran arbeite oder andere fühlen sich vielleicht
dann wieder eher, ich würde das auch ohne Bezahlung machen, wenn andere für Bezahlung
mitmachen, ja, also Hauptsache, es gibt irgendwie mehr Man- oder Woman-Power, ja, und das hat
mich einfach gerade die letzten Tage, weil wieder mehrere Issues kamen, so genervt, weil
zwei auch gefragt haben, ja, warum ist denn das Projekt so tot, und ich halt sagen musste,
na ja, ich mach jetzt schon seit über einem Jahr hier alleine dran rum und versuch so
das Nötigste, aber es geht halt einfach nichts voran und das ist echt schade.
Und die, die anderen, die, die melden sich nicht mehr oder wie viele Leute warten?
Sporadisch, wenn man die taggt oder sowas, dann kommt, oh ja, sorry, mein neuer Job frisst
einfach so viel Zeit, ich weiß, ich müsste eigentlich, aber geht nicht.
Und ich mach den Leuten ja auch gar keinen Vorwurf, ne, also es ist ja, jeder hat das
so und das eigentliche Problem ist halt eben generell, deswegen wieder zurück zu spenden
und so, dass man Open Source halt wirklich unterstützt und sagt, okay, das braucht Zeit
und Zeit haben Leute nicht zu verschenken, sondern dann muss die Zeit halt irgendwie
bezahlt werden, auch bei Open Source Projekten, auch bei Projekten, wo an sich das Endprodukt
kostenlos ist, aber irgendjemand muss diese Zeit entschädigen in irgendeiner Form, weil
man kann viel freiwillig machen, aber ich kann nicht die Zeit, die ich nicht für Familie
habe, die ich aber eigentlich brauche, um Geld reinzubekommen, die kann ich nicht auch
noch verschenken, indem ich da, ja, kostenlos meine Zeit da zur Verfügung stelle.
Ja, ich verstehe das total, ich habe jetzt, ich bin jetzt quasi auf der anderen Seite
bei einem Projekt, wo ich, wo ich jetzt gerade so Dinge so ein bisschen vorantreiben will,
wo ich keine Antworten bekomme auf meine Fragen und ich bin jetzt schon kurz davor, das zu
forken, weil selbst im, die haben einen Slack-Channel, also ich kann mal sagen, worum es geht, es
geht um Pally und Pally Dashboard, ich glaube, da habe ich auch vielleicht schon mal drüber
gesprochen.
Stimmt, ja.
Pally ist so ein Kommandozeilentool, mit dem man automatisierte Accessibility-Tests fahren
kann und Pally Dashboard ist im Prinzip quasi ein Frontend dafür, wo ich bestimmte URLs
eintragen kann und dann ich auch Cron-Jobs einrichten kann und dann auch so einen Verlauf
sehen kann, wie viele Fehler waren da, wann und welche sind das.
Ziemlich cool, wenn man so ein bisschen Seiten überwachen will, wie sie, wie die sich entwickeln.
Also das Tool an sich ist ziemlich gut, es hat aber so ein paar Schwächen oder so ein
paar Sachen, wo ich sage, da müsste, da müsste man mal ran und teilweise sind es nur Kleinigkeiten.
Ganz, ganz easy.
Also zum Beispiel habe ich gerade gesagt, es gibt so einen Verlaufsgraf der Fehler,
das ist eine coole Sache, nur ist der Graf, der fängt nicht immer unten bei Null an,
sondern der startet irgendwo in der Mitte, je nachdem, wie viele Fehler da dargestellt
werden.
Das bedeutet, dass zum Beispiel manchmal der Graf so aussieht, als ob er mega runtergegangen
ist, weil ein Fehler gefixt wurde von 50, also da geht von 50 auf 49 und der Graf sieht
aus, als ob du jetzt, jetzt hast du fast keine Fehler mehr, aber man sieht, die Null ist
halt nicht da, die Skala geht halt von 48 bis 51, das ist komplett irre.
Also ich verstehe nicht, wie er sich das ausgedacht hat.
Also eigentlich möchte, der Graf muss unten immer bei Null beginnen, sonst hat es gar
keine Aussagekraft, weil wenn ich einfach 5000 Fehler habe und davon einen fixe, dann
habe ich quasi ja nichts gewonnen.
Und da muss ich an einer Stelle eine Zahl einfügen in dieses Projekt und ich glaube,
so gut wie jeder würde zustimmen, dass das eine gute Idee ist und im Notfall, falls es
jemand ganz doof findet, könnte man es auch konfigurierbar machen, von mir aus.
Alles gut, aber es ist nicht möglich, irgendwie da Kontakt zu kriegen, ich habe GitHub-Issues
aufgemacht, ich habe in dem Slack-Channel kommentiert, wo aber nur lauter andere Leute
auch noch sind, die auch sagen, ich würde hier gerne und guck mal, es gibt Merch-Requests
ohne Ende und ja, keine Ahnung, also da tut sich irgendwie auch nichts und das ist so
ärgerlich und ich will eigentlich so ein Projekt nicht forken, weil da gibt es Leute,
die sich richtig gut damit auskennen und ich will eigentlich jetzt nicht anfangen, entgegen
deren Gedanken oder entgegen deren Architektur zu arbeiten, weil ich das am Anfang gar nicht
komplett durchsteigen kann, ich kann nach bestem Wissen und Gewissen irgendwie was beitragen,
aber ja.
Und du hast dann halt auch wieder, dann hast du deinen Fork, den du benutzt und dann kommen
aber Upstream vielleicht doch irgendwann wieder Neuerungen, dann musst du die wieder, wenn
die deins nicht merchen wollen, musst du das dann wieder irgendwie verheiraten.
Ja, es ist auch keine Dauerlösung.
Und ich kenne das auch, ich kenne diese Sicht nämlich auch, dass du irgendwo, du hast ein
cooles Produkt oder Projekt und dann, ah, das und das wäre cool oder da ist tatsächlich
wirklich ein Bug drin und dann gehst du aufs Repository und du siehst halt, ja gut, da
hat sich halt seit Monaten oder im blödesten Fall seit Jahren nichts mehr dran getan.
Es gibt irgendwie über 1000 Issues und keins davon wird beantwortet.
Das ist halt einfach schade und wie gesagt, man kann da niemandem einen Vorwurf machen,
weil ich kann auch sagen, okay, ich brauche das selber nicht mehr, ich arbeite nicht mehr
im Accessibility-Bereich, ich brauche das Produkt nicht mehr, deswegen entwickle ich
nicht mehr dran.
Ist mir völlig klar.
Oder ich mein, es kann auch passieren, dass Developer versterben, ja, und dann das Projekt
bracht nicht.
Aber es ist, ja, es ist schade.
Da gibt es einige Maintainer, aber ich glaube, seit einem Dreivierteljahr oder so hat keiner
mehr was gemacht, außer der Dependabot, der arbeitet fleißig vor sich hin.
Ja, da sind einige Dinge im Argen in diesem Projekt, also auch zum Beispiel, zieht Pally
das Dashboard nicht die aktuelle Version von Pally an und lauter so Sachen, wo man sagen
würde, na ja, wenn man da ab und zu mal ein bisschen Maintenance macht, aber dann sehe
ich auch auf der anderen Seite, ich verstehe das total, weil ich, wenn ich mir jetzt vorstelle,
ich würde einen Fork machen, also einen Fork, wo ich sage, alle, die jetzt davon genervt
sind, dass in dem anderen Projekt nichts passiert, die können jetzt auf diesem Fork weiterarbeiten.
Und wenn ich mir vorstellen würde, ich würde das jetzt machen, ich glaube nicht, dass ich
die Zeit hätte, den Fork zu maintainen, wenn dann andere Leute wieder kommen und zu mir
dann wiederum sagen, also ich kann meinen eigenen Fork maintainen mit meinen fünf Changes,
die ich machen will, kann ich den Fork für die anderen maintainen? Ich glaube, dass ich
die Zeit nicht dafür hätte. Außer, wie du schon gesagt hast, es gäbe irgendwie Spenden
oder es gäbe irgendwie die Möglichkeit, das finanziell auszugleichen, sodass ich sage,
naja, die Spenden, die gerade reinkommen, die reichen dafür, dass ich in der Woche
einen Tag daran arbeite, dann ist es cool. Das müsste nicht mal so viel sein. Das würde
ich, also bei OpenType würde es schon reichen, wenn da irgendwie zwei Leute zumindest mal
ein paar Stunden im Monat investieren können, ja, um einfach mal Issues abzuarbeiten, um
Pull-Requests abzuarbeiten. Also selbst solche so relativ kleine Beträge würden da eigentlich
schon ausreichen, dass Leute vielleicht Interesse daran haben. Aber gut, es ist, wie ich habe
ja schon am Anfang gesagt, wir werden es hier nicht lösen, aber ich muss das einfach loswerden,
weil ich es einfach so schade finde. Ja, mir ist gerade noch was eingefallen, auf der Liste
ist noch was dazugekommen gerade. Ne, wir werden es leider nicht lösen. Aber hier,
falls ihr die Idee gut findet eines automatisierten Accessibility-Testing-Tools,
was ich gerade, wie ich es gerade beschrieben habe, also mir geht es vor allem um das Dashboard,
dann und jetzt jemand sagt, ey, das ist genau das, was ich jetzt auch die ganze Zeit schon
brauche und jetzt fünf Leute sich finden, die sagen, lass uns doch einen Fork machen,
dann sage ich Fork you, Fork me, Fook you, wer sich erinnert bei Austin Powers, egal. Genau,
dann lasst uns das, lasst uns mal darüber reden, weil ich glaube, das ist ein richtig gutes Tool,
da können viele davon profitieren, wenn es das gibt. Vor allem, wenn es das kostenlos in
den Open Source gibt, da bin ich großer Fan von, weil ich mir sehr gut vorstellen könnte,
dass es schon einige kommerzielle Tools gibt, die den Source Code davon verwenden,
das weiterentwickelt haben und dann sagen, hey, da machen wir jetzt einen Pricetag dran. Und ich
könnte mir sogar vorstellen, wenn man das jetzt ein bisschen weiterdenkt, ja, Open Source, ich
habe jetzt nicht mir die Lizenz angeguckt von dem Ding, aber jetzt nur mal kurz weiterdenken,
jetzt will man das irgendwie sustainable funden, so ein Projekt, dann könnte man sagen, man macht
eine Software-as-a-Service-Angebot dafür, ja, das heißt, du hast einen Server, auf dem betreibst
du das Ding, immer auf der neuesten Version und sagst, hey, hier kannst du dir einen Account
klicken, dann kannst du da dein Pally-Dashboard machen und der Server liegt bei uns und dafür
wirfst du Geld ein. So. Und das könnte man ja dann quasi so pricen, dass quasi die Entwicklung
daran so ein bisschen querfinanziert wird. Und dann hättest du ein bisschen Funding für das
Projekt, dass du es weiterentwickeln kannst, wenn du quasi das Ding und ich glaube, viele Leute sind
zu faul, sich das irgendwo selbst aufzusetzen. Die würden dann ein paar Euro einwerfen.
Also die Lizenz, ich habe gerade mal geschaut, das ist GPL und LGPL, aber das hindert ja nicht.
Also das Ding soll ja Open Source sein und das ist ja auch völlig okay.
Ich würde ja den Code gar nicht wegsperren.
Genau. Und dann kannst du es natürlich, wie du lustig bist, auch als SS-Service anbieten. Du
hostest es halt und hältst es halt aktuell und so. Ja, klar.
Also das war nur so eine Spinnerei irgendwie, weil ich mir vorstellen könnte, dass das reizvoll
ist für Leute. Also ich meine, es fängt schon an, dass das ein NPM-Ding ist, was mit einer MongoDB
läuft. Das kannst du auch nicht auf jedem Shared Host mal eben so betreiben. Ich habe es auf
Uberspace zum Laufen gekriegt. Jetzt weiß ich quasi schon, wie es geht. Also jetzt müsste man
im Prinzip das nur noch sozusagen, was heißt nur noch, das ist gar nicht so einfach, aber man
müsste jetzt das halt quasi mandantenfähig machen. Das Ding hat halt keinerlei Access Management,
überhaupt nicht. Wenn du das Ding irgendwo betreibst, dann ist es einfach da, offen für alle.
Jeder kann alles machen. Das heißt, das müsste man noch drumherum basteln, sodass nicht jeder
alles angucken kann, sondern nur, du willst ja vielleicht nicht, dass alle die Ergebnisse von
deinen Tests sehen. Und dann wäre das doch eine coole Sache. Ich glaube, recht nützlich für viele
Leute. Achtung, Disclaimer nochmal. Automatisierte Accessibility Tests finden nur einen kleinen Teil
der Fehler. Nicht, dass ihr jetzt denkt, das ist die allgemeine Lösung für alles. Manuelle Tests,
da kommen wir nicht drumherum. Aber trotzdem helfen solche Tools natürlich, eben ganz viel
so Kleinkram zu finden, den man dann nicht von der Hand irgendwie suchen muss. Und es sind auch
schöne Zahlen, die man als Management weitergeben kann. Das wollen die immer. Die wollen immer so
schöne Graphen haben. Ausnahmsweise in diesem Falle soll der Graph mal nicht nach rechts oben
gehen, sondern soll nach rechts unten gehen. Er soll gegen Null streben. Dann sind alle happy.
Interessanterweise hat Chrome mit Lighthouse umgekehrt gemacht. Da willst du ein hunderter
Score haben und möglichst hoch. Vielleicht ist das Management kompatibler. Ja doch,
wenn du so ein Score ausrechnest. Aber der Score ausrechnen ist dann wieder kompliziert. Was geht
da in welche Richtung wie viel rein und so. Da ist es mit wie viel Fehler gibt es schon ein
bisschen einfacher. Genau, so das war das. Jetzt habe ich hier die Reihenfolge durch. Entschuldigung,
ich habe hier wild rumgeklickt im Trello. Jetzt kommt noch das extra Thema, was ich gerade noch
reingeschrieben habe. Was Barrierefreiheit angeht, ist immer wieder so ein bisschen der,
weil wir jetzt gerade schon bei Peli waren, ist immer wieder so ein bisschen das Problem,
Leuten zu vermitteln, dass sie die Originalressourcen vom W3C verwenden sollen und darauf
darschauen sollen, wie die Regeln sind und sich daraus bedienen sollen. Also in dem Fall die
Web Content Accessibility Guidelines zum Beispiel. Aber das sind noch viele, viele weitere Tools und
Richtlinien, die da zur Verfügung stehen. Zum Beispiel auch ARIA Coding Practices,
also so eine Art Beispiele, wie man ARIA-Attribute richtig verwendet und so. Und mir fällt es aber
extrem schwer, Menschen zu vermitteln, dass sie das als Ressource nehmen sollen. Und ich möchte
niemandem zu nahe treten, aber ich glaube, ich weiß so grupp warum, weil diese Originalressourcen vom
W3C extrem sperrig sind. Die sind weder meiner Meinung nach gut gestaltet, also so dass man einen
guten Überblick kriegt, was ist wie, noch ist die Sprache besonders zugänglich. Das muss bei
technischer Spezifikation so sein, die muss extrem präzise sein. Und wofür das sorgt, ist, dass es
eine Million Interpretationen davon gibt, die dann eben zugänglicher sind, aber die sich alle so ein
bisschen widersprechen und nichts ist wirklich so richtig so präzise wie der Standard. Und ich habe
da so meinem Ärger beim Masterton so ein bisschen Luft gemacht, indem ich halt gesagt habe, so so
ein bisschen überzogen, ja ich habe Bock so meine eigene Collection zu starten an irgendwelchen Best
Practices, aber es gibt halt ja eine Million schon. Also das ist dieses klassische XKCD-Ding. Es gibt
hier irgendwie 13 Competing Standards und ich erfinde jetzt einen to unite them all und dann
gibt es halt 14 Competing Standards so ungefähr. Ist natürlich nicht das, was ich will. Was ich
eigentlich will wäre und da bin ich wieder bei Contribution und überlegen, wie man es machen
kann, dass die Originalressourcen einfach zugänglicher werden oder dass das W3C eine
zugängliche, eine einfach formulierte Variante anbietet oder halt auch warum gibt es denn nicht
offiziell von der Web Accessibility Initiative eine Pattern Library mit Accessible Patterns,
die auch nicht ganz scheiße aussieht wie aus dem letzten Jahrtausend, sondern die vielleicht so
aussieht wie vor drei Jahren. Vor allem, wenn es schon um Accessibility geht, was spricht denn
gegen die Speck in einfacher Sprache? Ja, überhaupt nichts. Und da fehlt mir,
das habe ich glaube ich noch gar nicht erzählt, ich war vor einer Weile mit meiner Frau in Augsburg
und da waren wir in einem Museum, ein jüdisches Museum in einer kleinen ehemaligen Synagoge und
da ging es irgendwie um das Jüdische und Jüdisch hat mich schon immer irgendwie fasziniert. Das
sind wir da hingegangen. Und dann war direkt im Eingangsbereich ging es halt los mit so Texten
über das Jüdische, wie das entstanden ist und so, wie sich es verbreitet hat. Und dann habe
ich das gelesen und habe noch gedacht, so krass, alles voll so präzise Informationen, aber leicht
verständlich. Und habe dann an die andere Wand geguckt, wo mehr Text stand und habe das gelesen
und dachte, das ist doch das Gleiche, nur nochmal irgendwie mit Komplexität aufgeblasen. Und dann
ist mir erst aufgefallen, die hatten alles, was an Informationen da stand, einmal in einfacher
Sprache oder leichter Sprache wird es auch genannt und einmal halt als normalen deutschen Text
geschrieben. Und zwar sowohl auf Deutsch als auch auf Englisch. Und ich habe dann die meiste Zeit,
ab da die Texte in einfacher Sprache gelesen, weil es einfach für mich, ich hatte die gleichen
Informationen, ich habe es schneller gelesen. Das andere war wirklich nur ausgeschmückt mit
unseren, gerade im Deutschen, mit diesen schönen Füllwörtern und grammatikalisch tollen Formen
und so weiter. Und das andere war halt einfach nur gleicher Informationsgehalt, aber viel leichter
einfach ging es in den Kopf. Und dann dachte ich mir, warum, alles muss immer so toll klingen,
warum nicht einfach leichter Sprache? Und das wäre ja gerade beim Thema Accessibility
eigentlich wirklich ein Ding. Weil vielleicht möchten auch Menschen mit irgendwelchen
sprachverarbeitenden Einschränkungen, vielleicht möchten die auch zur Accessibility beitragen,
selbst als Betroffene. Und warum soll ich denen das Leben schwer machen, indem die sich durch
die vier Seiten von Specs wühlen müssen? Klar, wie gesagt, ich verstehe schon, wie du auch gesagt
hast, die müssen halt so spezifisch sein, deswegen ist es ein Speck. Aber warum das nicht zusätzlich
eben auch für alle allgemein verständlich formulieren? Und dann schließt man nämlich,
man schließt ja damit auch wieder Menschen aus, die es einfach kognitiv nicht schaffen,
solche komplexen Informationen zu verarbeiten. Das ist ja auch wieder eine Form der Barriere,
ja, in einem Dokument, wo ich beschreibe, wie man Barrierefreiheit schafft.
Also ich würde ja sehr, sehr gerne mal, das ist wieder so eine Geldfrage, ich würde ja sehr,
sehr gerne mal zwei Gewerke auf diese Specs loslassen. Und zwar einmal Leute, UX-Designer
innen, die sich sehr gut auskennen, auch mit Informationsarchitektur, die sehr gut verstehen,
wie baut man, wie strukturiert man Content, dass er leicht verständlich ist, auch wenn es viel ist
und komplex. Weil es ist viel und es ist komplex. Du wirst die schiere Menge, wirst du nicht
reduzieren können. Die ist da. So, aber man kann sie so aufbereiten, dass sie einen nicht komplett
abschreckt, gleich wenn du es nur zum ersten Mal aufmachst. Und das ist bei den WCAG so. Selbst wenn
du diese Quick Reference nimmst, ist das, du kriegst da so viel sofort ins Gesicht geklatscht,
du hast du hast sofort keinen Bock mehr. Das ist so mein Gefühl. Und ich weiß, mittlerweile habe
ich mich damit abgefunden. Es ist ja auch, ich glaube Peter Gröner hat mal bei Working Draft
gesagt, die so Specs lesen zu können, also sich da reinfuchsen zu können, das ist ein Skill. Wenn
du das einmal erworben hast, dann fällt es einem nicht mehr so schwer. Das ist, glaube ich, genauso
wie Kommandozeile benutzen. Das hat so einen Abschreckfaktor. Und wenn man da einmal drüber
weg ist, dann merkt man, das ist ja total krass, da kann ich ja voll viel Sachen mitmachen. Und
bei den Specs, finde ich, ist es ziemlich ähnlich. Allerdings kann ich niemandem vorwerfen, dass er
diesen Skill nicht hat. Und ich möchte auch keinen tun, was ...
Den muss man halt auch bewusst erlernen. Also bei mir war das zum Beispiel auch über OpenType.js,
bin ich da zum ersten Mal so richtig reingerutscht. Ich habe eine Spec von Microsoft über OpenType.
Und ich lese die und ich muss verstehen, was genau gemeint ist. Und es gibt ja auch dann
oft verschiedene Interpretationen. Da gibt es dann Issues, wo dann darüber diskutiert wurde,
ja, aber ich lese das aus der Spec so raus. Und ich glaube, wir müssen das so und so implementieren.
Und dann guckst du dir andere Implementierungen an. Guck mal, die haben es so gemacht, aber die
haben es so gemacht und so. Ja, das muss man erlernen. Man kann es auch erlernen, aber man
muss halt erst mal so die Notwendigkeit dafür haben. Damals war das halt irgendwie der Trieb,
ich will unbedingt das und das Feature implementieren. Wenn ich aber nur mal so denke,
oh, das interessiert mich und ich gucke es mir an und ich werde, wie du sagst, so erschlagen,
dass ich gar keinen Bock mehr habe, dann ist halt einfach die Einstiegskurve auch zu hoch,
um da was dran zu machen. Genau, also mein Drei-Schritte-Programm für SB3C ist UX-Designer
drauf loslassen, die wirklich wissen, wie man mit komplexen Informationen umgeht und die gut
strukturiert. Dann auf die Texte UX-Writer loslassen. Das sind Leute, die genau wissen,
wie man gut textet und wie es die Leute gut verstehen. Und dann hätte ich gern noch eine
Pattern-Library, die nicht aussieht wie 1995, sondern eine richtige zeitgemäße Pattern-Library
mit Accessible Patterns, wo nicht an jedem Pattern dran steht, ja, das ist jetzt nur eine
Referenz-Implementierung, das solltest du in Live-Code niemals so machen. Wo ich mir denke,
nee, es gibt Leute da draußen, die wollen jetzt nicht in der Tiefe bis durchexerzieren, wie jetzt
das ARIA-Tab-Pattern funktioniert. Die wollen eine Copy-Paste-Lösung. Und wenn die eine
Copy-Paste-Lösung kriegen, also wenn wirklich unser Anliegen ist, dass das Web barrierefreier
wird, dann muss auch so eine Lösung sehr nahe liegen, ja, sodass ich habe die Copy-Paste-Lösung
und dann kann jeder das in sein Framework implementieren genauso oder kann sagen, ja,
okay, ich habe jetzt hier das, das baue ich jetzt noch ein bisschen um, dann passt es in
mein Framework rein, dann ist es in den Frameworks besser und dann ist es in Seiten, wo Leute das
kopiert haben, einfach besser. Vielleicht bin ich dazu naiv, jetzt kommt jemand und sagt,
ja, aber das funktioniert so nicht. Bitte gerne in die Kommentare, können wir gern
darüber streiten, aber so eine, weil es gibt einige Pattern-Libraries oder es gibt einige
so Sammlungen von Accessible-Patterns, aber warum gibt es keine offizielle? Warum gibt
oder doch, es gibt diese ARIA-Patterns, aber die sind nicht wirklich, da ist halt nicht,
bei weitem nicht alles dabei, was Accessibility angeht und es gibt so viele, also ich bin
für mich so ein bisschen am Sammeln von, ich habe so eine kleine FAQ für mich selbst
gemacht, immer dann, wenn mir jemand eine Frage stellt, die ich nicht sofort beantworten
kann, was das Thema angeht, schreibe ich das auf meine FAQ-Liste drauf und sage, das ist
die Referenzantwort, nächstes Mal ziehe ich sie einfach aus dem Hut und sage, hier, guck,
das ist es. Und ich glaube, ganz viele von diesen Themen könnte man eben mit sowas abhandeln,
mit so einem, nicht, ich haue dir jetzt die Spec um die Ohren, die so geschrieben ist,
dass dir keiner lesen will, sondern ich zeige dir einfach ein Beispiel, guck mal, so kann
man das machen. Und es geht noch viel weiter als so einzelne Patterns, es geht zum Beispiel,
was auf jeden Fall in meiner FAQ einen Eintrag hat, ist das Thema Captchas. Das ist kompliziert,
da gibt es viele, da gibt es verschiedene Lösungsansätze, wie man das barrierefrei
machen kann. Spoiler Alert, wenn du ein rein visuelles Captcha hast, not going to work,
my friend. Du brauchst dann noch zumindest ein Audio Captcha oder es gibt auch noch andere
Ansätze. So, Rant Ende. Jetzt habe ich auch noch ein bisschen gewendet. Aber das ist halt,
ich habe da auch so ein paar, also auf Mastodon hat sich so eine kleine Diskussion da drum
entsponnen. Interessant fand ich, dass da auch Leute mir zugestimmt haben und gesagt haben,
hey, ich sehe das genauso, ich habe genau dasselbe Problem. Aber auch Leute,
die an den W3C Standards mitschreiben, haben da geantwortet und auch teilweise mir auch
zugestimmt und gesagt, ja, das ist nicht so richtig maintained alles und so bestimmte Teile. Und da
denke ich mir halt auch, da könnte ich mich beteiligen in Form von, ich helfe dabei mal,
aber ich weiß auch nicht, ob ich mich jetzt trauen würde, da so einen kompletten Bereich
irgendwie neu zu schreiben. Es gibt halt Leute, die sich da noch viel viel besser als ich damit
auskennen, aber da kann ich auf jeden Fall meine Hilfe anbieten, wenn das Ziel sowas wäre,
dass das zugänglicher wird für alle. Und damit meine ich jetzt nicht, dass ich es besser mit
der Tastatur bedienen kann, sondern dass es sprachlich und von der Inhaltsarchitektur und
von der Aktualität her zugänglicher wird. So, ja, wäre schön, wenn sich da was tun würde,
aber ich jelle jetzt at the clouds und mal gucken, was da passiert. Ja, genau, on that note. Da
haben wir die Retro gleich geschafft nach irgendwie, keine Ahnung, 45 Minuten. Ja,
ich mache gerade wieder vermehrt Freelancing. Wollte nur mal so einen Statusbericht abgeben,
das macht mir echt Spaß, das ist echt eine coole Sache. Ich habe da schon öfter darüber
geredet. Also ich nenne es mal fun with screen readers, nicht fun with flex, aber mache ich
gerade viel und das Barrierefreiheitsstärkungsgesetz, wer es jetzt noch nicht mitbekommen hat, dass das
irgendwie kommt, das betrifft uns alle hier in Europa und in Deutschland auch. Und ich sage nur
book me while you can. Es wird langsam eng, also wollte ich nochmal hier so gesagt haben. Ja,
so, das war's. Das war's schon. Hat ja gar nicht weh getan. Das kommt, das kommt später. Wenn die
Rechnung kommt. Es ist wie, mir fällt gerade nichts, mir fällt gerade kein Vergleich an,
es ist wie ein guter Kater. Ja, manchmal ist es auch beim Arzt so, wenn man selber zahlen muss,
hat gar nicht weh getan, aber tut dann weh, wenn die Rechnung dann kommt. Ja, manchmal gibt's ja
irgendwie Leistungen, die nicht übernommen werden. Beim Zahnarzt zum Beispiel. Ich glaube,
da habe ich noch nie was Teures gehabt. Sei froh. Also, ich habe schon mal so eine professionelle
Zahnreinigung machen lassen, die habe ich selbst bezahlt, weil das sind ja irgendwie Beträge,
die sind ja, keine Ahnung. Aber egal, langweilen wir euch nicht damit, sondern du machst weiter
mit der Property. Mir ist die Tage was über den Weg gelaufen, was ich noch gar nicht kannte. Also,
offenbar, vielleicht bin ich auch komplett clueless und alle kennen alles schon. Aber
das ist mir vollkommen egal. Für mich war es neu und exciting. Ich habe auf einer Webseite
ein Feature entdeckt, wo meine spontane Reaktion war, das kann ja gar nicht funktionieren. Coole
Idee, aber das kann ja gar nicht funktionieren. Und zwar war das Feature, dass eine Webseite
einen Toggle anbietet, der sagt, verhindern, dass das Gerät in Standby geht. Also,
dass der Bildschirm sich ausschaltet bei einem Handy oder beim Tablet. Und ich habe gesagt,
naja, das kann ja gar nicht gehen. Du kannst ja drücken, den Toggle. Das ist bestimmt irgendeine
exotische Schnittstelle, die nur im Samsung Galaxy S23 funktioniert. Nein, es gibt die
Screen Wake Lock API und die ermöglicht einem genau das, dass sich das Gerät nicht in Standby
begibt. Also in dem Fall war das eine Seite mit einem Rezept, mit einem Kochrezept. Und da ist
es natürlich tatsächlich sinnvoll, weil wer schon mal mit einem Tablet oder so nebenher gekocht hat,
der möchte natürlich das Rezept vielleicht die ganze Zeit offen haben, auch wenn er es gerade
nicht verwendet. Und möchte, weil er halt dann, hat er die Finger voll Mehl und möchte dann
vielleicht nicht jedes Mal das Tablet wieder antatschen müssen. Also wer schon mal mit Tablet
und Kochrezept gekocht hat, der weiß, wovon ich spreche. Das ist tatsächlich ein Use Case. Und
ich hätte nie gedacht, dass es sowas gibt, aber das verlinken wir auch schön hier in den Show Notes.
Ich gehe jetzt nicht weiter darauf ein. Ich sage nur, ihr habt eine Möglichkeit, es ist ganz easy,
mit ein paar Zeilen JavaScript tatsächlich das Gerät vor allem Standby zu hindern von einer
Webseite aus. Voll gut unterstützt. Also krass, ich hätte gedacht, das ist bestimmt wieder irgendwie
so Experimental oder sowas, ist echt cool. Also ich weiß, mein Bruder hört hier zu und da ich
ja nicht mehr in der Firma bin, wir haben da auch zum Teil mit so Foodblog so ein bisschen was
unterstützt mit WordPress. Das wäre doch ein cooles kleines Plugin, oder? Dass ich so eine
Schaltfläche habe, wo ich diesen Screenlock aktivieren und deaktivieren kann. Also Fabian
weiß, was zu tun ist. Genau, Link kommt in die Shownotes. Also gut, ich bin erleichtert,
du kanntest das auch nicht. Ich habe es interessanterweise vorhin im Zuge von was
anderem, auf was wir später noch kommen, bei irgendeinem Attribut, wo es um so Feature-Freigabe
ging. Da habe ich das gesehen, da habe ich das gelesen, irgendwo in der MDN und dachte noch so,
hä krass, okay, kann ja gar nicht sein. Ich habe ausprobiert. Okay, müsste man mal sich anschauen,
aber habe ich dann nicht aus Zeitgründen. Und ich habe gar nicht gewusst, dass du es jetzt als
Property machst, deswegen ist es echt lustig. Ich habe es getestet, ich habe es getestet. In
meinem Fall, in meinem Test hat es funktioniert. Cool. Also ich hätte nicht gedacht, dass ein
Browser sowas darf, irgendein Browser-Tab. Allerdings, ich habe jetzt nicht den kompletten
MDN-Artikel dazu gelesen. Ich wäre jetzt aber davon ausgegangen, dass man mit der Seite
interagieren muss, damit das funktioniert. Also dass die Seite nicht einfach sagen kann,
wenn ich offen bin, darfst du nicht ins Chat rein. Ja, ja klar. Also ich hätte jetzt irgendwie
erwartet, dass es quasi ist wie bei Notifications oder so, dass der Browser dann nochmal ein natives
Fenster einblendet, wo du bestätigen musst als User, dass du das wirklich machst. Das
hatte ich in meinem Test nicht. Aber dass das wirklich einfach so direkt geht, finde ich schon
krass. Ja, weil es ist ja schon ein Vertrauensbeweis. Aber du musst ja eh interagieren. Da das ja per
JavaScript getriggert wird, musst du wahrscheinlich eh über einen Button interagieren und kannst nicht
einfach sagen, ja, mach das jetzt, wenn die Seite lädt. Ich habe gerade überlegt, ich glaube,
ich habe es in meinem Standardbrowser, ich habe es in Brave getestet auf dieser Seite,
wo das Rezept war und habe dann gewartet, ich habe den Bildschirmschoner auf eine Minute
runtergestellt, dass er nach einer Minute anfangen soll und er hat einfach nicht angefangen. Und dann
habe ich das wieder ausgeschaltet und dann hat er sofort angefangen. Also da kann ich auf jeden
Fall sagen, das hat genauso funktioniert, wie man es erwarten würde. Fand ich echt verrückt. Also
so ein kleines Ding mal wieder. Ich hätte nicht mal danach gesucht, nach diesem Feature. Das wäre
wirklich, das ist wirklich so weit weg, das kannst du nicht, das gibt es nicht. Niemals. So, vielleicht
habt ihr ja was gelernt. Also ich auf jeden Fall. Sehr gut. Cool, dann kommen wir jetzt zu, oh je,
wir haben so viele. Entscheide dich, sound bad. Welche Werbung kommt denn? Achso, genau,
die kommt ja auch noch. Warte mal, ich mache hier so, ich wackele mit der Maus und da,
wo es stehen bleibt, da drücke ich jetzt drauf. Das ist wieder die kurze, aber macht nichts,
machen wir nochmal. Wenn euch der Podcast gefällt, dann spendet Geld. Genau, ihr habt es gehört. Da
kann man ja nicht widerstehen. Nein, auf keinen Fall. Gut, dann hier ist WWSIV mit dem Tagesthema.
Dann können wir jetzt verraten nochmal, wenn ihr den Titel nicht sowieso schon gelesen habt. Weil
wie man sich embeddet, so nennt man. Es geht um Embedded Content. Das ist der nächste Abschnitt
in dieser HTML-Tech-Reference-Übersicht von MDN. Und wir haben aber ein bisschen was ausgeklammert.
Wir machen nämlich Picture und Source, machen wir nochmal irgendwie getrennt, weil das gerade
mit responsive. Ich dachte eigentlich, wir hätten darüber schon mal gesprochen, aber ich habe da
noch mal geschaut auf unserer Seite und gesucht nach diesem speziellen Source-Set und so. Und ich
glaube, in der Tiefe haben wir es noch nicht besprochen. Ich habe glaube ich schon mal
drüber gewendet so ein bisschen, wegen dem Umbau von unserer eigenen, damals noch meine Mitfirmen-
Homepage. Aber ich glaube, wir haben jetzt noch nicht gezielt drüber gesprochen. Deswegen Picture
und Source, da machen wir eine eigene Folge dazu. Und wir reden jetzt heute über, ich glaube es
sind vier Elemente. Embed Object, iFrame und was, was ich auch noch nicht kannte, Fenced Frame.
Dazu muss man sagen, Fenced Frame ist Experimental Technology. Das ist noch nicht so klar,
ob das wirklich kommt. Das ist auch glaube ich noch nicht so lange in der MDN drin,
weil ich meine, als ich zum letzten Mal, keine Ahnung, vor zwei, drei Monaten diese Seite mit
den Elementen angeguckt habe oder keine Ahnung, vielleicht auch sechs Monate her, war das noch
nicht in dieser Liste drin. Ich habe diese Embedded-Content-Liste schon mal ohne das
gesehen, da bin ich mir relativ sicher. Wobei, das kann man doch auch, ich kann,
kann man da gucken. Im Web-Archive könntest du theoretisch. Ich wollte bei GitHub gucken,
wann dieser Change kam, aber es ist auch nicht so wichtig. Also, das ist, da reden wir jetzt
heute nicht so viel drüber. Aber wir reißen es mal kurz an. Genau. Auch gerade im Unterschied
zu iFrame habe ich da mal geguckt, was ist das, warum brauchen wir das denn überhaupt. Aber dazu
später. Genau, wir fangen an mit Embed. Davon ist auch, glaube ich, von Embed und Object das älteste,
das ältere. Und Object kam dann hinterher. Ja, Embed ist, um Sachen einzubetten, wer hätte es
gedacht. Also, externen Inhalte. Früher war das so die Möglichkeit, um Audio und Video in eine
Seite einzubetten. Und zwar über zusätzliche Plugins, die im Browser installiert sein mussten.
Und dann auch später sowas wie Flash oder irgendwelche Java Applets oder so, was es da alles
gab, eben in den Browser einzubinden. Also, wirklich Medien-Content in irgendeiner Form
zugänglich zu machen auf einer Webseite. Aber auch so Plugins, ne? Also, was hast du
gerechnet? Also, man brauchte eigentlich immer, ne? Man hatte dann irgendwie halt das Quicktime-Plugin
installiert und dann konnte man, wenn eine Seite über Embed Quicktime-Filmchen eingebunden hat,
dann konnte man das aufrufen. Also, die Browser kamen da nicht mit fertigen Sachen eigentlich,
sondern man hat damit wirklich zusätzliche Plugins angesteuert.
Also, ich will jetzt nicht vorwegnehmen, aber wir gehen auch noch drauf ein, wie realitätsgetreu
oder wie sinnvoll es heutzutage noch ist, das einzusetzen. Also, klingt jetzt erstmal so ein
bisschen hmm, okay, interessant, Plugin. Aber es funktioniert noch, ne? Also, es ist nicht komplett.
Die Browser hatten ja eine Zeit lang auch Plugins so fertig mit eingebaut. Also, Flash-Plugin gab's
ja teilweise fertig mit drin und keine Ahnung, was noch ist. Also, gar kein Plugin.
Muss man das nicht zusätzlich installieren? Ich dachte, man muss immer so Macromedia oder irgendwas.
Das war mal eine Zeit lang so, aber ich bin mir relativ sicher, dass es eine Zeit gab,
wo Firefox das beispielsweise fertig mit drin hatte. Ja, korrigiert mich, falls ich falsch
lege, aber ich bin mir sicher, es gab Browser, wo das einfach mit vorinstalliert war. Du hättest
das deinstallieren können, aber es gibt so, und Plugin interessanterweise ist nicht Extension.
Und das unterscheidet sich eigentlich immer. Also Extensions machen irgendwas mit dem Content
und keine Ahnung, Plugins sind irgendwie eine andere Art Technologie. Ich glaube in Chrome,
ich habe vor kurzem mal geguckt, was da für Plugins installiert sind und es ist irgendwie
eins und es ist irgendwas von Plugins. Extensions erweitern halt die vorhandene
Browser-Funktionalität im Sinne von, ich kann halt das, was der Browser mir zur Verfügung
stellt an UI oder sowas, das kann ich irgendwie aufbohren und die Plugins, die sind halt dann
wirklich, um zum Beispiel halt Medienformate wiederzugeben, was ja dann auch wieder teilweise
mit Hardwarebeschleunigung und so zu tun hat, was halt näher auch am System dann wieder irgendwie
ans System verknüpft ist. Genau, also gehen wir nochmal zurück zu Embed, also es ist ein,
vielleicht muss man dazu sagen, das ist ein Void-Element, das heißt es hat kein schließendes
Tag, das schließt sich selbst. Also das heißt auch, du kannst das nur mit Attributen verwenden,
du kannst da nichts reintun. Und das heißt auch, ich kann kein Fallback-Content reinmachen? Genau,
da kommen wir noch dazu, also da merkt man auch schon, es ist so ein bisschen älter. Ich würde
jetzt einfach die These aufstellen, seit es das Audio und das Video-Element gibt und die weitgehend
unterstützt werden, benutzt das so gut wie niemand. Ich könnte mir vorstellen, das rate ich jetzt mal
so, dass es vielleicht so in Corporate-Kontexten, wo es bestimmte Plugins gibt, die vorinstalliert
sind für irgendwelche, was weiß ich, was für Medientypen. Maschinensteuerung oder so, dass du
zwar ein Webinterface hast, aber das ist irgendwie total an die Hardware gekoppelt oder so. So was
könnte man sich zum Beispiel noch vorstellen. Da könnte ich mir vorstellen, dass es vielleicht
noch verwendet wird, aber so in the wild, und dann kommen wir vielleicht gleich mal zur Popularität,
benutzt das fast niemand mehr. Ich habe mir mal die Mühe gemacht, ich wollte wissen,
wie populär sind denn die Elemente, über die wir heute reden, weil ich so dachte,
das habe ich schon lange nicht mehr gesehen und ich habe es auch schon lange nicht mehr gebraucht,
die Populärsysteme. Und dann ist mir eingefallen, es gibt ja den Web-Almanack und die haben ja auch
so Auswertungen gemacht über alles Mögliche, also über diesen kompletten HTTP-Archive,
also Web-Archive-Content. Und da haben wir die Popularität der Elemente und wir haben da auch
einen Link dazu, da gibt es nämlich so ein schönes Google-Doc, wo das drin steht. Allerdings,
ich habe jetzt die Dokumentation dazu nicht genau genug gelesen, um zu wissen,
wie diese Popularität sich jetzt genau errechnet, was dieser Wert ist. Aber ich kann euch sagen,
an welcher Stelle der Popularität das M-Wert-Element steht, und zwar an Platz – und
jetzt, das ist nämlich echt verrückt – Platz 269. So, jetzt fragt man sich, wie kann das sein? Es
gibt doch nur 100 so und so viele HTML-Elemente. Und das sagt dann auch schon was darüber aus,
wie wenig populär das ist. Also ich kann mal dazu sagen – Moment, ich scrolle mal die Liste ganz
nach unten – die Liste hat insgesamt 542 Einträge. So, und M-Wert, habe ich ja gerade gesagt,
ist auf Platz 269. Moment, jetzt bin ich aber gerade – warte, stimmt das überhaupt? Nein?
Wieso? Hä? Habe ich es falsch hingeschrieben? Jetzt in der Tabelle sehe ich jetzt gerade,
es ist auf 227. Okay, ist auch egal. Korrigiere ich das nochmal? Stimmt, stimmt die Zahl nicht.
So, wie kann das jetzt sein, dass es bei nur 100 und so viele HTML-Elementen auf Platz 227 ist?
Nun ja, da sind einige, so Custom-Elements, sind tatsächlich davor. Also sowas wie Pixif-Icon oder
Wix-Dropdown oder Now-Message oder Next-Root-Announcer oder FA-Icon, ja? Also Elemente,
die sich jemand mal, Custom-Elemente, die sich jemand mal ausgedacht hat, die aber offenbar
öfter vorkommen. Also irgendwie Libraries, also FA ist, wie heißt das, FA-Icon, Font Awesome.
Ja genau, Font Awesome, die haben offenbar ihr eigenes Custom-Element erfunden. Wobei,
was mich jetzt wundert ist, haben die da dann rausgerechnet, dass, ach nee, das ist ja mit
Minus, nee, das passt alles, nee, vergiss, was ich gesagt hab. Und da gibt's ganz, ganz viele davon,
also NF-Section, AMP-Image und so weiter. Also man kann ja heutzutage alles erfinden, RS-Bullet,
RS-Module-Wrap, RS-Module, RS-Slides, die sind alle sogar davor. Und das spricht nicht so
unbedingt für die Popularität eines HTML, eines nativen HTML-Elements. Da steht auch 0,0 Prozent,
also es ist unter 0,01 Prozent in dieser Liste. Es ist sehr, sehr, sehr wenig, wie viele Seiten das
benutzen. Ja, ich finde, das sagt schon aus. Also ich meine, wir werden jetzt noch ein bisschen
darauf eingehen, aber wahrscheinlich braucht ihr es nie. Das wollte ich halt damit sagen.
So, ja. Die Attribute, die es haben kann, sind width, height, source für das, ja, das verlinkt
auf das eben, das Ding, das ich da reinladen will. Und type für den MIME-Type, damit das Plugin weiß,
das ist jetzt für mich sozusagen. Und dann noch ein lustiges Zitat aus der MDN. Keep in mind,
that most modern browsers have deprecated and removed support for browser plugins, so relying
upon embed is generally not wise. Fand ich irgendwie ein bisschen witzig. Falls ihr es
trotzdem verwendet, könnt ihr dem gerne das title-Attribut geben, damit Screenreader auch
wissen, worauf sie sich da einlassen. Wahrscheinlich ist der Inhalt davon, selbst wenn ihr das verwendet,
dann trotzdem nicht barrierefrei. Also kann schon sein, aber würde ich jetzt mich mal nicht darauf
verlassen. Aber damit man weiß, was es ist, also im beschreibenden Text das title-Attribut. Genau,
das war schon embed, oder? Genau, dann kommen wir nämlich schon zu Object. Zum nächsten wenig
populären Event. Genau, also embed war ursprünglich von Netscape eingeführt worden und Object war dann
so gedacht als standardisierter Ersatz für embed und auch für das Applet-Tag, dass das komplett aus
meiner Erinnerung verschwunden war und dass es auch in HTML5 im Standard überhaupt nicht mehr
gibt. Und ja, das war so gedacht, wie gesagt, als Standard. Also die Zeiten der Browser Wars,
ja Netscape macht das und IE hat dann das andere. Und es war dann so, dass Mangelskompatibilität
dann oft weiterhin trotzdem embed verwendet wurde oder im Fall von Flash zum Beispiel eine
Kombination von beidem mittels entweder Conditional Commons oder mit einem Embed
als Fallback-Content im Object. Damit nehme ich jetzt schon wieder vorweg, dass man ein Object
Fallback-Content benutzen kann. Aber das war dann so eine Verschachtelung. Ich habe auch so ein
Object und wenn der Browser das Object nicht unterstützt, dann fällt er halt zurück auf
dieses Embed und darüber konnte ich dann auf jeden Fall halt diesen Content einbinden. Ja,
also man sieht das so eine, ja, wie das halt damals so war. So ein Hickhack und so ein mehr
schlechter als recht. Und man hat dann irgendwie halt auch beides benutzt. Du hast es noch notiert,
Object ist Embed on Steroids. Stand das so in der MDN? Nein, nein, das stand nirgends. Das habe
ich dazu erfunden. Genau, also ich habe halt gedacht, naja, das Object, das kann halt ein
bisschen mehr halt schon mit dem Fallback-Content. Aber letzten Endes ist, glaube ich, die
Funktionalität eine sehr ähnliche. Es wird damit was sehr Ähnliches versucht, sage ich mal. Weil
ich habe auch diverse Quellen konsultiert und habe versucht herauszufinden, was sind jetzt
eigentlich genau die Unterschiede? Warum gibt es überhaupt beides? Und so richtig schlau bin ich
nicht geworden. Außer ich habe halt Fallback-Content und das ist ein bisschen, es sieht halt ein
bisschen anders aus. Was ich interessant fand, war bei dem Object habe ich das Source-Attribut
für die Quelle, aber bei Embed habe ich das Source-Attribut. Bei Object habe ich das Data-
Attribut mit einer URL. Also funktioniert irgendwie komplett anders, aber auch Type.
Und dann kannst du noch vieles anderes mitmachen. Gehe ich jetzt nicht extrem ins Detail oder
glaube ich nicht ins Detail, aber zum Beispiel gibt es ein Form-Attribut, wo man dann eine
ID zu einem Form reinpacken kann, auf die sich das dann beziehen kann. So fancy Zeug
gibt es da irgendwie. Und auf der Liste der beliebtesten HTML-Elemente ist das Object
auf Platz 132. Super beliebt, ja. Es gibt auch eine Menge nicht-Standard-HTML-Elemente,
die vor dem Object-Element sind in dieser Liste. Wobei man sagen muss, es gibt auch
Standard-HTML-Elemente, die in dieser Liste hinter Custom-Elements sind. Also nicht nur
die beiden, sondern es gibt auch noch weitere. Ich hab irgendwie noch was von Tables, irgendwie
hab ich vorhin noch was gesehen und so. Es gibt so ein paar Sachen, die sind da relativ
weit hinten. Haben wir Param schon angesprochen? Nee. Nee, ne? Param war so ein, also das konnte
man oder geht wahrscheinlich immer noch, ist nicht deprecated, aber damit konnte man eben
noch mal Parameter übergeben an das, was man mit dem Object-Tag einbindet. Stimmt.
Also bei Flash zum Beispiel Quality High oder so was konnte man da noch setzen. Genau, ansonsten,
ich glaub, das ist das Einzige, wo man Param verwendet. Das kommt dir aber gar nicht vor,
oder? Ich weiß gar nicht, also es gibt das Param-Element auf jeden Fall bei MDM. Ah,
aber auch deprecated. Ist doch deprecated. Das ist deprecated, ja. Object-Parameter-Element,
ja. Stimmt, also früher gab's da so, also die Älteren werden sich erinnern.
Wenn du so Flash-Geschichten einbinden wolltest, hattest du, und ich hab das nie von Hand geschrieben,
ich hab das immer irgendwo rauskopiert oder so, hattest du so einen großen Block. Du hattest das
Object-Element und dann so drei, vier, fünf Param-Elemente da drin, die irgendwelche Parameter
gesetzt haben. Genau, also das war dann so ein größerer Block, um irgendwie so ein Video oder
sowas einzubinden. Genau. So, und vielleicht noch, achso, du hast es schon, ich weiß nicht,
hab ich jetzt vorher nicht richtig zugehört, hast du das schon gesagt, dass das mal gedacht war für
alles so? Genau, also als Ersatz für Applets eben auch oder für, also als Ersatz für Embed im Endeffekt
und das Applet. Ah, okay, dann ist das was. Aber für Images zum Beispiel, jetzt weiß ich auch nicht,
dass das das auch irgendwie ersetzen sollte. Also ich habe vom W3C ein Dokument gefunden,
wo es um HTML 4.0.1 geht, wo gesagt wird, dass man auch das Object für alle möglichen Dinge,
die man einbettet in HTML verwenden sollten könnte. Also Object Data, Canyon PNG,
Type Image PNG sehe ich jetzt hier gerade, okay. Genau, also quasi ein global galaktisches,
ich lade externe Dinge in HTML rein und sage dem dann halt noch, was es ist. Also wenn man das so
macht, dann bräuchte man kein Image Tag mehr zum Beispiel. Oder iFrame. Oder Applet gab es ja auch
mal. Genau. Das fand ich noch einen ganz interessanten Fakt, dass das so, das sollte,
da hat sich mal einer gedacht, das könnte doch alles ersetzen, da könnte man doch alles abstrahieren.
Ist irgendwie nicht passiert, kann man jetzt schon mal sagen. Komisch. Naja, was heißt komisch. Ich
finde die Idee, ich kann verstehen, warum die jemand mal hatte. Ja, aber dass ich zum Beispiel
bei einem Image den Mime-Type dann explizit irgendwie angeben muss als Objekt, das ist ja.
Da hat halt jemand sich gedacht, ich denke jetzt mal in die Zukunft. Ich habe keine Ahnung, was es
noch für Medientypen geben wird. Ich mache mal ein generisches Objekt, das alles, was in Zukunft
kommt, einbetten kann. Und du hättest zum Beispiel dann halt kein eigenes Audio- und Video-Element
gebraucht. Genau. Ich finde den Gedanken an sich jetzt nicht ganz verkehrt. Ich finde den irgendwie
reizvoll. Hat sich aber irgendwie nicht durchgesetzt. Hat irgendwie offenbar keiner
gemacht oder weiß ich nicht genau. Kann der Chef ja mal sagen, was er davon hält.
Gut und jetzt kommt das Schlimme große mit ganz vielen Sachen, nämlich der iFrame.
Genau. Da haben wir auch in den vergangenen 70 Folgen auch schon ab und zu mal iFrames in
irgendeiner Form tangiert. Auch was so Content Security und so angeht.
Also was ist ein iFrame?
Jetzt stürzen wir uns noch mal so auf alles genau.
Also ganz allgemein, wer es nicht weiß, das hören ja vielleicht auch Leute zu,
die noch nicht schon 20 Jahre Webdevelopment machen. Ein iFrame ist ein Element, mit dem ich
quasi eine Webseite in eine andere integrieren kann. Das wird tatsächlich relativ viel verwendet,
auch wenn man das oft gar nicht sieht, dass das gemacht wird. So ein klassischer iFrame sind zum
Beispiel, wenn man Google Maps einbindet oder YouTube-Videos oder früher hat man mal Tweets
eingebunden, als es noch Twitter gab, Instagram-Posts. Also immer so dann, wenn ich Inhalt
von woanders irgendwie integrieren will. Auch Werbung wird ganz gerne in iFrames gepackt.
Die Werber wollen das nicht, weil die würden gerne auf den kompletten Content der Seite zugreifen.
Das dürfte denen aber nicht durchgehen lassen. Das ist jetzt mein heißer Pro-Tipp. Lass die Werber,
das muss alles in ein iFrame, der nichts darf. Ja, definitiv, definitiv. Auf keinen Fall irgendwie
direkt ... Die Wahrheit über Ads im Browser ist, die werden, die machen alles, jegliche schwarze
Magie, die ihr noch nie gesehen habt, versteckt sich in Werbe-iFrames. Da müsst ihr mal reingucken.
Das ist, das ist wirklich, da habt ihr, da habt ihr die Hölle gesehen, wenn ihr da mal reingeguckt
habt. Wascht euch danach die Augen mit Seife aus. Wascht euch danach, wascht euch, am besten danach,
danach einfach bitte in Desinfektionsmittel baden, euch mit kochendem Wasser abspülen und, ja,
Augen auswaschen auf jeden Fall. Da schaut ihr wirklich ganz tief rein. Also der iFrame ermöglicht,
dass sowas dann trotzdem nicht die Kontrolle über alles übernimmt. Genau, und da gibt es eine
Million Attribute und vielleicht gehen wir die mal so ein bisschen durch. Ich weiß jetzt nicht,
vielleicht nicht alle, aber so die wichtigsten. Also der iFrame hat halt eine Source. Das heißt,
da kann ich einfach den Pfad zu einer anderen Seite eingeben. Das darf auch Cross-Domain sein,
nichts Verrücktes an der Front. Wobei man auch da sagen muss, die Zielseite muss das einerseits
erlauben beziehungsweise darf es nicht unterbinden, weil auch das geht. Und natürlich auch die
Content Security Policy, da haben wir auch eine eigene Folge mal dazu gemacht, die ich gerade
schon nicht mehr weiß, welche Nummer das war. Nummer 48. Verlinken wir natürlich auch in den
Shownotes, was das überhaupt bedeutet, falls jetzt jemand von Content Policy gerade das erste Mal
hört. Genau, also es müssen bestimmte Voraussetzungen gegeben sein, aber wenn es jetzt nicht irgendwie
aktiv unterbunden wird, sage ich mal, dann kann man die Seiten einbinden. Genau, dann noch was,
was ein bisschen alt klingt, nee, was ein bisschen neu klingt, aber eigentlich alt ist, allow full
screen, nämlich so, dass du eben zum Beispiel, wenn du das YouTube-Video einbettest, dass der
iFrame trotzdem sich in full screen machen darf, also ein Inhalt daraus. Das gibt es, glaube ich,
gerade wegen diesem Video-Use-Case schon relativ lange. So Dinge, die, andere Dinge,
die im iFrame erlaubt werden oder verboten werden, das ist irgendwann mal ein bisschen
reformiert worden, sage ich mal. Deswegen hat da nicht alles ein eigenes Attribut bekommen. Aber
allow full screen hat man, glaube ich, damals vor allem für die Videos gebraucht, weil so ein
YouTube-Video irgendwo einbinden, das ist, glaube ich, ein Use-Case, der jetzt schon wirklich sehr,
sehr lange besteht. Da hat man was für gebraucht. Interessanterweise noch ein kleiner Fun-Fact. Das
Name-Attribut, damit er auch zum Beispiel von einem Form-Element getargetet werden kann. Also
ja, wer sich an die Zeiten von Framesets erinnert, also nicht iFrame, sondern wirklich Seiten,
die komplett nur aus einzelnen Seiten bestehen, die irgendwo anders sind, die müssen ja irgendwie
miteinander kommunizieren. Das heißt, wenn ich die Navigation im einen Frame habe, dann muss
ich irgendwie auch sagen können, aber jetzt bitte, wenn ich jetzt hier drauf drücke, soll sich jetzt
nicht der Link in diesem Frame ändern, sondern in dem anderen. Und ebenso kann man auch Formulare
in einem anderen Frame haben, auch im iFrame. Dafür unter anderem gibt es das Name-Attribut.
Das habe ich aber noch nie gemacht. Keine Ahnung, ob das alles so funktioniert. Ich
habe das nur aus der MDN gelösen. Oder Target, also Link-Target. Kann ich ja auch auf einen
benannten Frame setzen. Dann, wichtig zu wissen, und das sind jetzt die ganzen, die dunklen,
hohen Priester, die Werbung bauen. Jeder iFrame macht einen neuen Browsing-Kontext auf. Das heißt,
neuer Speicher, neue Ressourcen, neues alles wie quasi ein neuer Browser-Tab. Also,
falls ihr auf die Idee kommt, iFrame ist jetzt für alles und wir verschachteln sie tausendfach,
liebe Ad-Industrie. Wie gesagt, schaut euch mal den Quellcode von ich. Also,
irgendwie ein iFrame, der dann drinnen nichts anderes macht, als nochmal ein iFrame zu laden
von wieder einer anderen Domain oder so, ja. Also, pass auf. Ich sag das jetzt mal eher abstrakt.
Die Leute, die, manche Leute, die den Podcast hören, weiß ich, werden sich angesprochen fühlen
und das dann auch okay. Ich weiß, dass es eine vielfrequentierte Seite gibt, die, wenn man sie
zum ersten Mal aufruft und noch keinen Cookie-Sachen bestätigt hat oder so, einen erst mal umleitet auf
eine völlig andere Seite, die so aussehen soll, als ob es die Seite ist, aber ein Cookie-Banner
davor liegt, aber es ist nicht die echte Seite, die dann aber einem ein Banner aufmacht, der in
einem I-Frame ist, in dem wiederum ein I-Frame ist, in dem der Bestätigen-Button für die Cookies
ist. So, hab ich gehört, dass es sowas gibt. Und ich weiß genau, was du meinst. Und dass das so
verschachtelt ist, weiß ich auch noch nicht so lang. Ich sag's mal so, wenn man versucht,
automatische Tests laufen zu lassen, kann sowas echt zum Problem werden, wenn man nämlich nicht
auf I-Frame-Kontexte aus dem automatischen Test zugreifen kann. Und wenn es dann noch zwei sind,
verschachtelt, dann hat man richtig Spaß. Ja, so. Ich hab noch PostMessage aufgeschrieben.
Ist kein Attribut. Das ist so einfach nur mal so angerissen. Ich will da auch gar nicht in die
Tiefe gehen. Man könnte ja jetzt die Idee haben, man möchte von der Seite, die den I-Frame einbindet,
oder von dem I-Frame nach außen irgendwie Kommunikation betreiben. Man möchte da irgendwas,
man möchte Status wissen, man möchte wissen, was ist da drin gerade passiert. Ich hab da drin was
geklickt oder ich hab außen was geklickt. Da soll sich innen was verändern und so.
Ich hatte das zum Beispiel mal auch im WordPress-Kontext. Ich wollte Update-Meldungen
einblenden lassen. So, die auf einem anderen Server checken, gibt's da was Neues? Ist da
irgendwie eine Hinweismeldung, dass gerade irgendwie der Service down ist oder was? Und
wenn ja, dann zeig den I-Frame an und zwar halt mit genau der Höhe am besten, die diese Meldung,
die da drin steht, braucht, damit das so aussieht, als wäre das einfach nur eine Meldung in dem
WordPress-Backend. Und wenn nicht, dann versteckt den I-Frame einfach komplett. Und das läuft halt
auch darüber über PostMessage und über ein Resize-Event, dass ich halt abfrage, also
standardmäßig hat der I-Frame keine Höhe und wenn der I-Frame aber geladen ist, dann wird per
PostMessage kommuniziert, ich habe übrigens Content und mein Content ist so und so hoch und die äußere
Seite skaliert an den I-Frame entsprechend und eben halt bei Resize dann auch noch mal.
Es war früher ein pain in the butt, ein I-Frame so hinzukriegen, dass man nicht gesehen hat,
dass er da ist. Also der hatte irgendwelche Rahmen und dann eine feste Größe.
Und dann waren halt doch Dinge abgeschnitten oder so.
Genau und also wie gesagt, wir gehen jetzt nicht tiefer auf PostMessage ein,
aber da gibt es eine Möglichkeit rein und raus zu kommunizieren. Allerdings die MDN ist auch,
das fand ich super witzig, das ist glaube ich in der aktuellen Version nicht mehr so,
aber das wird für ewig in meinem Kopf bleiben, habe ich hier glaube ich auch schon mal zitiert.
Da stand mal drin, wenn du kein Security-Problem haben willst,
dann benutze einfach kein PostMessage. Und also das sei nur an der Stelle noch erwähnt,
das wird auch in der MDN relativ offensiv angesprochen, dass man da aufpassen muss,
von wo man Nachrichten zulässt. Genau, also da sollte man genau drauf schauen,
aber wie gesagt, es geht jetzt hier erst mal nur um das Tag und nicht um PostMessage. Da könnte man
eine komplette Sendung wahrscheinlich drüber machen. So, genau. Die nächsten Punkte sind von dir.
Genau. With Firepolicy ist noch eins, das aber analog zum ArTag funktioniert. Also hier Link
zu Folge 62 in den Shownotes. Und CSP ist aktuell auch noch hier experimental. Und zu CSP habe ich
ja vorhin schon den Link hingepackt, aber auch noch mal an der Stelle. Also da kann ich halt
solche Content-Security-Policy-Angaben direkt in dem Iframe-Element noch mal definieren,
die dann eben auf diesen Iframe-Content angewendet werden. Genau, das ist nur am Rande.
So Referral-Policy?
Genau, das ist ... Ach so, kannst du noch was dazu sagen?
Ich hab noch was dazu. Das sagt ja auch so ein bisschen, welche Referral verschickt werden. Und
da gibt es ganz interessante Werte. Also gibt es relativ viele Werte dazu. Wir gehen jetzt nicht
einzeln auf die ein, aber ich hab auch gedacht, das kann ganz spannend werden, welcher Referral
verschickt wird, je nachdem, in welcher Iframe-Verschachtelungsebene ich da befinde. Kann
das dann schon spannend werden, weil stell dir vor, du hast 27 verschachtelte Iframes. Welcher
Referral wird denn jetzt wohin geschickt? Also das ist schon spannend. So, genau, dann Allow.
Genau, da haben wir beide was dazu aufgeschrieben. Und ich war zuerst kurz ein bisschen verwirrt,
weil ich dachte, hey, Moment mal, ist das nicht das Gleiche wie CSP? Aber es ist nur,
von der Syntax her ist es ähnlich. Also das Allow-Attribut, da geht es eben nicht um die
Content Security Policy, sondern um die Permissions Policy. Und die wird ähnlich
definiert, aber statt halt irgendwelchen Security-Sachen, wer mit wem kommunizieren
darf und was für Inhalte dürfen überhaupt reingeladen werden und so, werden da eben
bestimmte Features ausgeschaltet oder halt gesagt, okay, zum Beispiel die Geolocation,
die darfst du nur benutzen, wenn es die eigene Seite ist, also Target Self oder nur eine bestimmte
URL, die eingebunden ist, darf das dann benutzen. Und deswegen wechselt man das leicht, CSP und
die Permissions Policy. Aber es sind eben zwei unterschiedliche Dinge, die damit konfiguriert
werden. Nur die Art und Weise, wie ich die konfigurieren kann und auf was ich sie einschränken
kann, die ist halt ähnlich. Und deswegen kommt man da vielleicht auf den ersten Blick ein bisschen
durcheinander. Genau, der Host kann halt bestimmen, ob ich die Kamera zum Beispiel verwenden kann oder
das Mikrofon oder Geolocation oder sowas. Das ist natürlich sehr, sehr gut und wichtig,
weil vielleicht habe ich ja tatsächlich iFrames eingebunden, denen ich nicht vertraue. Ads iFrames
zum Beispiel, denen solltet ihr auf keinen Fall vertrauen, weil es ist ja wirklich schon öfter
vorgekommen, dass auch irgendwie Zero-Day-Exploits genutzt wurden über Ads. Also ihr solltet Ads
niemals vertrauen, die dürfen einfach gar nichts. Oder lasst jemand den Ad-Server kapern und dann
irgendwelchen malicious Content ausspielen und ich habe dem Ding keine Sandbox gesetzt.
Muss gar nicht mal sein, weil heutzutage ja Ads ausgespielt werden. Du weißt ja teilweise gar
nicht, was für ein Ad auf deiner Seite ausgespielt wird. Das kommt von irgendeinem Ad-Server von
irgendwo. Irgendjemand hat das da geboten und da kommt ein Ad, wo du gar nicht weißt, was das ist.
Das kann ja tatsächlich jemand sein, der irgendwie bösen Code ausliefert, der den ganz
legitim irgendwie da den Werbeplatz gekauft hat. Also sowas solltet ihr auf keinen Fall jemals
vertrauen und dafür finde ich sowas ganz gut, weil wenn ihr nämlich trotzdem sagt,
naja das eine, das soll erlaubt werden, dann könnt ihr sagen, da soll es aber einen guten
Grund für geben. Dem entgegengesetzt ist das Sendbox-Attribut. Wenn man das einfach nur
reinschreibt, das verbietet nämlich erstmal so quasi alles. Interessanterweise kann man damit
auch wieder Dinge erlauben, indem man nämlich in das Sendbox-Attribut als Werte Dinge reinschreibt,
die so mit allow- beginnen und davon gibt es eine Million Sachen, die man dann wiederum erlauben
kann. Das gibt halt quasi einmal verbieten, einmal erlauben, nee es gibt zweimal erlauben.
Eigentlich ist es auch allow, ja, aber es funktioniert ein bisschen anders.
Ja, also das gibt es auf jeden Fall auch noch. Aber das ist sehr, sehr strikt. Das Sendbox-Attribut
ist extrem strikt. Ich glaube, wenn ihr das einfach nur draufhaut, dann ist die Wahrscheinlichkeit,
dass da innen drin einiges kaputt geht, relativ hoch. Aber so als Starting Point und dann zu
sagen, okay, ich erlaube jetzt nur, was wirklich nötig ist, finde ich eigentlich gar nicht so
schlecht. Dann unser Lieblingsattribut, was wir schon ganz am Anfang hier in dem Podcast mal
gefeatured haben. Warum benutzt das eigentlich keiner? Das geht auch mit iFrames, nämlich
Loading gleich Lazy. Ich glaube, es ging zuerst mit Images und dann auch später mit iFrames. Ja,
also nichts anderes als, wenn das Ding below the fold ist und ich scrolls in den sichtbaren Bereich
oder kurz davor, dann wird zuerst geladen und ich habe halt nicht direkt beim Laden der Seite dann
auch noch den ganzen iFrame-Content, der mitgeladen wird. Bedenkt, falls ihr Werbung ausspielt, das ist
schlecht für die Ad-Impressions, die dann nicht geladen werden, wenn sie below the fold sind.
Allerdings ist es natürlich aus User-Sicht ist es natürlich absolut toll, weil ich nämlich mir eine
ganze Menge Quatsch spare, der nicht über die Leitung geschickt wird, falls ich vielleicht gar
nicht runterscrolle. Gut und die Werber wollen halt vielleicht, dass die Impression auch wirklich
erst dann gezählt wird, wenn das wirklich im sichtbaren Bereich war. Da macht es ja schon
auch Sinn für das Tracking, weil was bringt mir das, wenn mein Werbemittel zwar irgendwie in der
Seite geladen wurde, aber halt irgendwie ich muss einen Kilometer scrollen, um dahin zu kommen.
Genau, das muss man dann aushandeln, weil das bestimmt ja der Host. Das kommt ja,
das kommt ja von außen, aber ich glaube, wenn ich mich recht erinnere, die Werber
haben auch noch andere Möglichkeiten zu sehen, ob ihr Ad wirklich angezeigt wurde,
auch von innerhalb des I-Frames aus. So und jetzt kommt noch was Kurioses, was ich vorher
noch nicht wusste und nicht kannte, nämlich das Source-Doc-Attribut. Kennst du das?
Ja, vor Urzeiten, früher mal, warum auch immer benutzt.
Das ist, das habe ich, das ist neu. Das war mir komplett neu. Das fand ich jetzt,
das war wieder so ein Ding wie, ich kann ein Monitor davon abhalten, irgendwie in Standby zu
gehen. Und zwar, das Source-Doc-Attribut ist ein Ersatz für das Source-Attribut. Wenn ich
kein Source-Attribut hinterlege auf dem iFrame, kann ich das Source-Doc-Attribut nehmen und dann
innerhalb des Werts HTML-Code reinschreiben, den ich dann quasi aber mit den iFrame-Sendboxing-
Mechanismen sendboxen kann dadurch. Was komplett verrückt ist. Also ich meine,
das kann, also ich verstehe den Anwendungsfall. Ich verstehe auch, wann man das machen möchte.
Also zum Beispiel habe ich irgendwelchen User-Generated-Content, von dem ich aber sage,
der ist potenziell böse. Ja, also der soll da irgendwie angezeigt werden, aber der darf jetzt
nicht auf den Kontext der Seite, der Host-Seite zugreifen, ausgründen, weil ich will nicht,
dass die Leute da irgendwelchen Quatsch machen. Dafür ist das, also ist schon so ein Development-Ding,
würde ich sagen, wenn man irgendwie Code anzeigen kann.
Ja, und man muss den Code halt mit HTML-Entities versehen, also damit, ja, sonst spreng ich mir halt
das Attribut vielleicht mit den Double-Quotes oder mit den 10-Quotes.
Genau, mit den, ja genau. Aber das fand ich, also das ist so eine Kuriosität, die mir über den Weg
gelaufen ist, das kannte ich noch nicht an der Stelle und das fand ich irgendwie cool und
erwähnenswert hier. Aus Accessibility-Sicht mal wieder, ebenso wie Object und, ne Moment,
jetzt springen sie schon durcheinander, doch, wie Object, iFrames sollten ein Title-Attribut
bekommen, um den Inhalt zu beschreiben, weil man sollte als Screenreader-Nutzer jetzt nicht
unbedingt mit allem Müll zugeschüttet werden und dann kann man sich halt überlegen, nachdem ich
weiß, nachdem im Title drin steht, ah, das ist jetzt ein iFrame für blablabla, dann kann ich
selbst entscheiden, ja, tue ich mir das jetzt an, gehe ich da jetzt rein, sozusagen, oder lasse ich
es bleiben, kann ich vielleicht ignorieren. Also, das solltet ihr in jedem Fall machen, weil
ansonsten würde jetzt im Screenreader einfach nur vorgelesen werden, iFrame, damit hat sich die Sache,
ich habe dann aber erstmal den Content nicht und, jo, genau. So, dann ist mir noch aufgefallen in
der MDN, ich habe in unserer Dokumentation das mal genannt, die größte Element-Kompatibilitätstabelle,
wo gibt, und zwar die Browser-Compatibility von iFrame, tatsächlich in der MDN. Und da sind die
ganzen Attribute mit aufgelistet. Und die Werte vor allem, das geht nämlich so auf. Und die Werte
der einzelnen Attribute. Also gerade bei Sandbox und bei Allow ist das halt echt viel. Da gibt es
endlos viele, genau, endlos viele Werte. Und die komplette, ja genau, die komplette Kompatibilität
der Browser, über die Browser hinweg, dieser Attribute und dieser ganzen Werte ist da
aufgeschlüsselt. Diese Tabelle ist ewig lang. Also ich glaube, ich habe in der MDN noch nie
so eine lange Kompatibilitätstabelle gesehen. Da kann man ein bisschen scrollen drin. Da kann
man sich schon ein bisschen drin verlieren. Fand ich nicht schlecht. Wir haben bei den
ganzen anderen Elementen, jetzt vorhin immer gesagt, wie populär sind die denn? Und dieses
Element, das iFrame-Element, das ist, glaube ich, gar nicht so, wird gar nicht so wenig
verwendet. Es ist auf Platz 34. Das liegt an der ganzen Werbung, mit der wir zugekleistert
werden. Ich kenne auch Seiten, wo es nicht für Werbung verwendet wird. Oh, sowas gibt's?
Ja, ja. Ob das jetzt in dem Fall sinnvoll ist, dass man es verwendet, oder könnte man
das nicht eleganter machen? Vielleicht schon, aber ich weiß, dass es Anwendungsfälle gibt,
wo es nicht für Werbung verwendet wird. Und dann ist es quasi schon so fast auf der sinnvollen
Seite in meinem Kopf. Gut, dann haben wir noch das vorhin schon erwähnte Fenced I-Frame. Und,
ja, das erste, nachdem ich so die ersten paar Zeilen gelesen habe auf dem MDM, war für mich
wirklich die Frage, warum brauche ich das denn aber, wenn wir I-Frame und diese ganzen Allow
und Sandbox-Geschichten schon haben? Und es gibt noch mal so ein paar Unterschiede. Es ist im Ende
Fakt wie ein Sandbox-I-Frame nur noch abgekapselter. Also man will da wirklich komplett vermeiden,
dass dieser Content in irgendeiner Form mit der Seite ansonsten interagieren kann. Und das heißt,
ich habe im Unterschied zu I-Frames, habe ich kein Post-Message. Das kann ich einfach gar nicht
benutzen. Da komme ich schon gar nicht in die Versuchung oder irgendwie Security-Risiken zu
öffnen. Ich habe keinen Zugriff auf Window-Parent. Local Storage und Cookies sind komplett isoliert.
Und dadurch habe ich eben keine Möglichkeit, irgendwas zu beeinflussen. Und das bedeutet
halt auch, ich habe kein Cross-Site-Tracking, dass ich irgendwie Third-Party-Cookies setzen
kann oder so. Es ist wirklich komplett abgekapselt. Ich lade diesen fremden Content da rein,
aber der ist komplett losgelöst eigentlich vom Rest. Und ja, eben Third-Party-Tracking
und Cross-Site-Tracking, der ist auch wieder aus dem Ad-Kontext, um das halt zu vermeiden
und halt eine datenschutzfreundliche Einbettungsmöglichkeit im Endeffekt zu bieten.
Stellt sich mir immer noch die Frage, brauchen wir dafür ein eigens benanntes Element oder hätte es
nicht gereicht, halt irgendwie das bestehende iFrame mit diesen Sicherheitssachen zu benutzen
oder halt ein Attribut zu setzen, von mir aus fenced als Boolean-Attribut. Aber gut,
es ist ein Vorschlag von Google, es gibt es auch nur in Chromium-basierten Browsern aktuell und
ja, muss man sich halt die Frage stellen, ob sich das so durchsetzen wird und in anderen
Browsern adaptiert werden wird oder ob es nicht doch irgendwann heißt, okay,
wir machen es mit den bisherigen iFrames. Es bleibt einfach mal abzuwarten.
Du hast noch hier geschrieben, FanStream taucht im Datensatz des HTTP-Archives nicht auf,
also da ist noch gar nicht, ist nicht mal irgendwie aufgeführt.
Genau, ChatGPT kennt es auch nicht.
Keine Statistik dazu.
Was, ChatGPT kennt es nicht? Doch, ich habe mit ChatGPT nämlich darüber gesprochen,
was der Unterschied ist zwischen iFrame und FanStream, ja.
Ich habe, das ist witzig, dann siehst du, da siehst du, das ist nicht deterministisch.
Mein ChatGPT hat, ich habe halt gesagt, hey, ich habe diese Elemente, erzähl mir mal ein bisschen was dazu.
Und zu FanStream hat es mir gesagt, ja, das ist irgendwie nicht so bekannt.
Das könnte sein, dass das irgendwas ist, was es früher mal gab, aber jetzt keiner mehr weiß.
Hä, okay, witzig.
Das finde ich, das ist witzig, das ist wirklich witzig, ja, krass.
Gut, ey, da sind wir schon durch.
Aber da seht ihr wieder, auf die AI dürft ihr euch nicht verlassen.
Was ich mittlerweile echt gut finde, ist, dass ChatGPT die Möglichkeit hat, das Internet
zu durchsuchen und ich sag dann immer, nachdem das mir sagt, ja, das ist so und so, sag ich,
jetzt sag mir mal die Quellen, die du verwendet hast.
Und dann kann ich das, ich muss das verifizieren, ich muss selbst nochmal nachlesen und gucken,
stimmt das auch, oder ist das jetzt irgendein Käse, weil das kann schon extrem hilfreich
sein, gerade so beim Akkumulieren von Informationen, so Dinge zusammenzufügen, um so ein Bild von
was zu bekommen, aber dann muss ich auch die Quellen dafür haben.
Und ich finde, dann ist es auch nicht problematisch, so etwas zum Beispiel für Recherchezwecke
zu benutzen, keine Ahnung, schreib eine Hausarbeit oder so, ja, ich kann mir das ja zusammenfassen
lassen von CharityPT, und solange ich das verifiziere, indem ich dann wirklich diese
Quellen mir ausgeben lasse und vor allem diese Quellen natürlich dann auch lese und da nochmal
drin nachlese, ob das dann stimmt, finde ich aber für so einen groben Überblick oder
um das eben am Schluss dann sich eine Idee geben zu lassen, wie man das zusammenfassen
könnte, finde ich das also schon eigentlich gut.
Ich erzähle dir im Nachgang nochmal was zur Recherche und CharityPT, das kann ich aber
nicht im Podcast erzählen.
Das ist ein krasses Teil, das ist ein krasses Teil.
Apropos krasses Teil, wir kommen zum Geil-Teil.
Ja, Geil-Teil, ich habe etwas entdeckt, was ich wahrscheinlich schon mal in der Vergangenheit
irgendwann mal gesehen habe, behaupte ich, wieder vergessen habe und jetzt wieder neu
entdeckt habe.
Als ich dann auf GitHub gelandet bin, habe ich gesehen, oh, der hat das, das ist tatsächlich
schon älter.
Erster Commit vor zwölf Jahren, letzter Commit vor fünf Jahren und zwar geht es um revenge.css.
Revenge.css ist CSS, was geschrieben hat der gute Hayden Pickering, von dem hatten wir
es, ich glaube, da haben wir im Stream mal was geschaut von ihm.
Der beschäftigt sich auch viel mit Barrierefreiheit, hat auch da mehrere Bücher geschrieben und
ich sage mal so, sein Ansatz, Wissen zu vermitteln, ist ein bisschen anders als der von vielen
anderen.
Er ist manchmal ein bisschen konfrontativ unterwegs und stößt die Leute ganz gerne
mal von Kopf.
Das ist aber manchmal auch wichtig, dass man das macht, auf eine ironisch-britische Art.
Das finde ich ganz sympathisch und er hat damals Revenge.css ins Leben gerufen.
Er hat sich nämlich gedacht, hey, einige Barrierefreiheitsprobleme kann man ja durch
clevere CSS-Selektoren finden und wenn man die dann noch ein bisschen cleverer macht,
dann kann man tatsächlich auch auf der Seite dann anzeigen, ey, du hast hier ein Problem
mit Before- oder After-Pseudo-Elementen.
Also, was hat er gemacht? Er hat halt versucht, eben genau solche Patterns zu finden und dann
mit Pseudo-Elementen dir auf der Seite anzuzeigen, das hier ist jetzt gerade nicht so cool.
Und zwar in dem Fall natürlich rot hinterlegt mit Comic Sans, wo dann eine Frage drin steht,
ich habe es gerade mal jetzt zum Beispiel bei der MDN ausprobiert, da taucht jetzt mehrfach
auf, this element is empty, why? So, genau. Und hier, also er sagt auch in der Readme von
dem Projekt steht auch drin, ja, was haben wir denn hier? Misplaced divs, deprecated
elements, malformed hyperlinks, inaccessible forms, empty elements, also alles mögliche,
was man mit CSS so abtesten kann. Das ist natürlich auch wieder nur ein kleiner Bereich,
alte Attribute, alte HTML-Elemente, die man nicht mehr verwenden sollte und so weiter.
Genau, und es gab auch mal ein Bookmarklet dazu. Ja, die Demo-Seite funktioniert leider
auch nicht mehr. Führt leider ins Nichts. Und ich bin gerade auch so ein bisschen durch
die Issues gegangen und da schreibt jemand zum Beispiel, Hayden's Code ist super old
and is no longer recommended, many things obsolete, many important things missing und
wird verwiesen auf Alex, also a11y.css. Ja, das habe ich mal ausprobiert, das gibt es
als Browser-Plugin und es hat bei mir nicht funktioniert. Einfach nicht funktioniert.
Aber vielleicht war ich auch einfach zu doof dafür.
Du kannst es einfach mal verlinken und vielleicht kriegst du es zum Laufen.
Ich habe das auch gefunden, diesen Hinweis. Ich fand trotzdem, also das stimmt, einige
Sachen sind nicht mehr auf dem neuesten Stand. Trotzdem hier mein Call an alle richtigen
Tough-Cookie-10x-Developers da draußen. Wer richtig krass ist und glaubt, dass das voll
drauf hat, so 10x-mäßig, der packt dieses CSS einfach mal in sein Live-Projekt ein.
Am besten was mit vielen Usern, weil wenn ihr es richtig drauf habt, dann habt ihr überhaupt
kein Problem, weil dann passiert einfach nichts. Und wenn ihr es nicht drauf habt, dann werdet
ihr bzw. deine User auch mit Comic Sans da drauf hingewiesen. So!
Alleine deswegen gewinnt doch Revenge CSS schon vor Accessibility CSS.
Ja, auf jeden Fall. Einfach nur wegen Comic Sans und einfach,
weil es Revenge heißt. Das finde ich auch einfach sehr, sehr schön. Ja, also nehmt
das nicht zu ernst, aber wirklich, packt das mal eine Seite von euch rein und guckt mal,
was dann passiert. Ich habe es gerade bei der MDN ausprobiert, da kommen ein paar Sachen.
Ihr werdet bestimmt auch, also auch auf meiner privaten Seite, glaube ich, habe ich etwas
gefunden. Man sieht ja auch manchmal was. So, Revenge CSS, ab morgen auf diesem Kanal.
Kostenlos bei GitHub. Ja, dann kommen wir zu unserem Lieblings-Dschingel.
Das Ende. Mein Whisky ist schon leer, scheiße. Brauchst du Alkohol, um den Dschingel ertragen
zu können? Es ist zu spät, ja. Ich finde ihn nach wie vor super. Du hast ihn ja auch gemacht.
Ja, vielleicht deswegen. Du hast ihn ja im Herstellungsprozess schon mehrere Male hören
müssen. Ich muss ihn ja zum Glück nur am Ende der Folge einmal hören jedes Mal. Ja,
da sind wir jetzt angekommen am Ende der Folge. Und ja, ich fand es mal wieder sehr schön,
dass wir zusammen aufgenommen haben und hoffe, ihr habt auch ein bisschen was mitgenommen an
Informationen, was euch noch nicht bekannt war. Und mehr habe ich eigentlich gar nicht zu sagen.
Nee, ich leier noch mein kleines Sprüchlein runter. Bewertet uns doch auf Podcastportalen.
Ihr habt es vorhin schon gehört. Ihr könnt uns auch ein bisschen Geld spenden. Links findet
ihr bei uns. Es gibt auch tausend andere Möglichkeiten, uns zu unterstützen auf
www.sev.de. Es gibt auch Dinge, die kein Geld kosten, wie man uns helfen kann. Wie gesagt,
Podcastbewertung überall. Wir haben übrigens den ersten, fällt mir jetzt gerade ein, den ersten
Spotify-Kommentar auf eine unserer Folgen bekommen. Weil ich wusste, es gibt dieses Feature. Ich wurde
glaube ich irgendwann mal gefragt, willst du das anschalten oder nicht? Und da kam tatsächlich
ein Themenvorschlag. Ich glaube, das habe ich auch in unsere Liste noch mit reingeschrieben. Ich glaube,
das hatten wir sogar schon auf unserer Liste, das Thema. Ja, also das ist mir gerade noch
eingefallen. Danke auch dafür. Also das könnt ihr auch benutzen. Nicht, dass wir jetzt so riesige
Fans von Spotify wählen, was Podcast so angeht. Aber wenn das sowieso der einzige Audioplayer auf
eurem Smartphone ist, mein Gott, dann nutzt es halt. Dann könnt ihr da auch einen Kommentar
schreiben. Aber schreibt uns lieber Kommentare auf unser Blog hier. Das heißt unser Blog auf unserer
Podcast-Seite zu den Kommentaren. Da können es dann nämlich alle lesen und nicht nur Spotify
Abonnenten. Das ist ein bisschen cooler. Da kann man auch auf Kommentare antworten und dann kann
sich eine kleine Diskussion daraus ergeben. Und dann könnt ihr auch da mal lesen, was der Chef
manchmal so schreibt. Da kann man nämlich auch noch was lernen. Auf jeden Fall. Genau. So,
das war jetzt relativ lang noch. Ja, deswegen drüge ich jetzt schon mal auf das Outro. Na gut,
macht's gut. Bis dann. Macht's gut. Danke fürs Zuhören. Ciao.
Ciao.
Outro-Musik