HTML VON A BIS Z-Z IX: Embedded Content

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. 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