Revision 702: Das <geolocation>-Element, mit Thomas Steiner

0:00Das große Thema Permissions, aufgespannt mit vielen, vielen Problemchen, großen, kleinen Problemen, wo man sich unendlich lange aufhängen kann und sagen, ja, man könnte das ja vielleicht ein bisschen besser machen, wo erscheint denn überhaupt die Permission? Aber dann gibt es die Line of Death und oberhalb derer, also da typischerweise die URL-Zeit ist, da kann einfach kein Web-Content mehr malen, da sind die Toolbar-Icons und so weiter und ein bisschen drüber über diese Line of Death erscheint typischerweise der Permission-Prop.

0:30User Media, das sehen wir noch mittendrin. Es gibt aktuell einen Origin-Trail, wo man das schon mal testen kann. Hey, kurze Werbeansage von uns. Seit 2011 sind wir regelmäßig auf der Beyond Tellerrand, einer Konferenz für Kreative und Entwickler. Und sie inspiriert uns bis zum heutigen Tag. Das nächste Mal findet die Konferenz am 27. und 28. April 2026 in Düsseldorf statt. Tickets kosten 349 Euro, was für zwei Tage Konferenz mit dem Line-Up ein Schnapper ist.

1:03Und wir würden uns freuen, dich dort zu treffen. Auf der Webseite beyondtellerand.com ohne Bindestrich gibt es alle Infos. Und noch ein Tipp. Gönnt euch ein Zimmer im Holiday Inn oder im New Tab neben der Venue. Denn abends kann man dort oft noch mit den Speakern und der Community an der Bar abhängen. Wir alle freuen uns, wenn du dabei bist. Und wer darüber hinaus noch Bock hat, dem gebe ich persönlich gerne eine Führung durch Düsseldorf inklusive Königsallee, Altstadt, Medienhafen und japanischem Viertel.

1:45Wir sind heute zu dritt. Da hätten wir aus dem Team den Peter. Hallo Peter. Moin, moin, moin. Ich bin der Schöpp und das bedeutet, wir haben wieder einen Gast da und zwar den Thomas Steiner. Hallo Thomas. Hallo, mein Sam. Du warst erst neulich bei uns, deswegen da hast du dich eigentlich schon im Detail vorgestellt. Vielleicht skippen wir das einfach und verweisen auf diese Folge. Ich will es wissen, du arbeitest bei und für Google und hast auch so diverse Webstandard-Themen, die du da weiter vorantreibst.

2:21Früher ganz viel so FUGU-Themenkomplex. Genau. Und jetzt, ja, weiß gar nicht, wie man das jetzt nennen kann, UX, würde ich sagen, viel UX. Nämlich, wir wollen heute über Permissions oder Permission-Abfragen im Web sprechen, was daran am aktuellen Stand vielleicht noch nicht so cool ist und was man da besser machen kann. Ganz genau, ja. Und der Aufhänger dafür war ein Blogpost von euch, das nämlich Chrome ein neues HTML-Element shippt, und zwar das Geolocation-Element.

3:04Und ja, das fand ich ganz spannend. Und ja, Erinnert mich auch, dass ihr da irgendwann schon mal was gemacht hattet und da haben wir gedacht, vielleicht können wir ja mit dir, mit euch mal über so diese ganze Geschichte, wie es dazu kam und was vielleicht noch kommt, sprechen. Ja, das können wir sehr gerne machen. Ich dachte, ich hole mal so ein bisschen aus, weil die meisten Leute haben zwar ein vages Konzept von Permissions, aber eigentlich nie richtig drüber nachgebracht.

3:37Und das Erste, was man als Permission typischerweise denkt, ist Permission Spam. So, man geht auf irgendeine Seite und die Seite fragt sofort nach, hey, ich will Notifications schicken, darf ich das? Und genau, wie kamen wir eigentlich dahin? Ja, da muss man ganz, ganz lange zurückgehen in die Geschichte von HTML und sich mal überlegen, was waren denn die ersten Permissions, die man so hatte. Und vermutlich, ich habe es jetzt nicht 100% recherchiert, aber vermutlich war die erste Permission, die es gab, die für Geolocation.

4:11Nämlich, ja, ist das relativ einfach. Man verwendet die Geolocation-API und wenn man das erste Mal versucht, sie zu verwenden, erscheint automatisch ein Permission-Prompt oder wo der Browser einen fragt, hey, möchtest du, dass die Seite deine Location bekommt? Das ist so das quasi implizite Prinzip. Man verwendet irgendeine API und automatisch fragt die API dann, wenn sie die Permission nicht schon hat, darf ich, was auf immer das Featured-Signwork nutzen.

4:39Ich springe direkt mal rein. Also dieses, wenn man das verwendet, das ist sozusagen dann aus EntwicklerInnen-Sicht und also die eine Partei verwendet und die Besucherin, der Besucher muss dann quasi, kriegt den Request und muss abnicken, ne? Das muss nicht unbedingt durch die initiiert werden. Genau, also das ist, wenn man die API versucht zu verwenden als Entwickler. Was auf PageLoad gegeben hat, was passieren kann. Die zweite Art und Weise, die man typischerweise kennt, ist, man hat eine statische Methode, zum Beispiel Notification.

5:18Und dann Permission, Request, Request Permission, ich weiß gerade gar nicht mehr. Genau, Request Permission, so, wo man, bevor man das Video verändert, ganz explizit fragt, hey, darf ich das denn? Ziemlich populär wurde dazu auch der iOS-Fall, wo Apple auf einmal beschlossen hat, sie fragen für Device Orientation jetzt nach Permission, weil das wurde im Hintergrund verwendet, um zum Beispiel rauszufinden, bist du gerade unterwegs, läufst du gerade, gehst du gerade, joggst du gerade?

5:46Wenn man die Device Motion Patterns so ein bisschen analysiert, da ein bisschen ML drüber, ja, kann man sehr schnell anhand der Patterns sehen, was passiert im Bereich. Und da gingen ganz viele Seiten kaputt, weil natürlich keine Seite das erwartet hat, dass auf einmal eine Permission nötig ist und diese statische Permission-Anfrage ist dann natürlich explizit, also anders als implizit, ich verwende eine API und warte, was passiert, da muss ich ganz explizit nachfragen, darf ich das denn.

6:13Bis sowas gab es noch eine andere Form, nämlich Navigator Permission.request. Wo man ganz gezielt nach einer Permission fragen konnte. Und Permissions ist ja immer so ein bisschen durcheinander, weil ich hatte gerade schon erwähnt, es gibt zwei verschiedene Arten und Weisen, wie man Permissions erfragen kann. Und diese API hatte dann quasi den Ansatz zu sagen, okay, wir lassen das ganze Kleider-Radach aus historischen Gründen natürlich da, aber wir verändern, dass wir machen eine API, Navigator Permission, Not Request, wo man dann ganz gezielt fragen kann nach wohl definierten Labels, also Notifications oder was auch immer, Dual Location.

6:52Und das war ein Objekt, das man dieser Methode überreicht hat oder übergeben hat. Und da war dann auch ursprünglich die Idee, ein Objekt kann natürlich mehrere Keys haben. Da kann ich dann auch verschiedene Permissions zusammenbündeln. Also so das Vorbild ist wahrscheinlich dann, wie das, also genau, ich bin ein Android-User, Oder so, dass man irgendeine App startet und die ja dann en bloc direkt Permissions oder Erlaubnis abfragt für den Zugriff auf verschiedene Bereiche.

7:20Genau, da wäre ich jetzt direkt drauf gekommen. Das war damals das Android-Modell. Man installiert eine App und dann muss man sofort alles abblicken. Und es gab keine feingraduelle Möglichkeit zu sagen, das eine ja, das andere nein, das andere barte ich erstmal und vielleicht später. Das war einfach nur ja oder nein. Und erneut kam dann relativ schnell auf den Trichter, das kann das nicht sein. Die Leute, ja, können sie eine App nutzen, wollen, klicken das einfach nur weg, machen keine, auf Englisch-Segment-Maschinen, keine educated decision, also denken nicht wirklich sogar nach, sondern wollen einfach nur den Dialog weghaben und die App nutzen.

7:58Und ja, das hat natürlich dieses Jahr viel Missbrauchgefühl, wo man dann als Entwickler sagte, ja, ich bin ein Spiel, ich brauche eigentlich Geolocation nicht, aber die Daten lassen sich vielleicht ganz gut verkaufen an ICE oder was auf immer, die dann damit. Mehr oder weniger illegal oder was auch immer nach jeweiliger Definition Migranten jagen. Und ja, also sehr, sehr schwieriges Thema natürlich. Android, wie gesagt, kam dann auf den Trichter und haben gesagt, nee, nee, das kann es nicht sein.

8:24Wir machen das, dass wir die Permissions nur nach quasi bei Bedarf abfragen. Und das Web kam dann auch ziemlich schnell dahinter, dass man das wohl nicht in Navigator Permission Request machen sollte. Und ja, dieser AGL wurde dann in einem Issue, Issue 83, auf der Permissions-Repository-Seite wieder quasi revoked. Es war eine Idee, es war nie wirklich implementiert in vielen Browsern. Ich glaube, in Chrome war es nur hinter einer Flag, aber nicht wirklich exprimiert.

8:58Genau, dann wurde diese Idee beerdigt. Gut, das Problem war natürlich nach wie vor da. Man hat Permissions, man will Apps nutzen und muss natürlich irgendwann nachfragen. Nicht auf PageRoot idealerweise, sondern kontextuell, wenn es Sinn ergibt. Also ich bin auf einer Landkarte und möchte sagen, wo bin ich denn eigentlich? Dann drücke ich irgendwo den Locate-Me-Knopf und dann kommt der Mission-Programm. Dann kann man natürlich immer sagen, ja, diese On-Load-Variante hat natürlich schon seinen Vorteil, nein, ihre Vorteile, die Variante hat ihren Vorteil.

9:32Dass man zum Beispiel als Suchmaschine sagt, ich gebe jetzt in eine Suchmaschine ein, Pizza, da kann das heißen, ich möchte Pizza als App, das kann aber auch heißen, ich möchte Pizza in der Nähe finden, also eine Pizzeria in der Nähe, und wenn die Suchmaschine dann schon weiß, wo bin ich denn eigentlich, dann kann das Suchergebnis entsprechend anpasst werden. Kann man jetzt sagen, okay, ja, schwieriges Thema, und die verschiedenen Browser-Navigatoren sehen das auch so, dass das ein schwieriges Tier war, ist, äh, Chrome lässt dich die Permission speichern, also du kannst dann sagen, okay, ich bin fein damit, dass Google jedes Mal meine Location haben darf, wenn ich die Seite starte.

10:09Safari macht das nicht. Selbst wenn jetzt ein Nutzer sagt, ich bin persönlich okay damit, es gibt einfach in Safari keine Möglichkeit, dauerhaft zu sagen, eine Seite darf meine Location haben. Das gilt dann nur für die Session-Dauer. Genau, praktisch. Und dann sind wir auch sehr schnell beim Thema Permission-Fatigue, also dass die Leute einfach die Permissions gar nicht mehr wahrnehmen, weil wenn bei jedem Load mehr oder weniger eine Permission kommt, dann ist es irgendwann einfach nur ein visueller Lern-Noise.

10:37Ja, kennen wir von den Cookie-Bannern auch. Genau, man klickt es einfach nur noch weg. Und ja, das ist dann quasi das große Thema Permissions, aufgespannt mit vielen, vielen Problemchen, großen, kleinen Problemen, wo man sich, unendlich lange aufhängen kann und sagen, ja, man könnte das ja vielleicht ein bisschen besser machen. Wo erscheint denn überhaupt die Permission? Das Konzept Line of Death, zumindest auf Desktop, wo man sagt, okay, es gibt den Bereich im Browser, wo Web-Content Inhalte generieren darf.

11:09Also ich kann mit der Kernmas irgendwo was hinzeichnen, ich kann ein Bild hinsetzen, ich kann da Text hinsetzen, ich kann da ein Frame hin positionieren, was auch immer, aber dann gibt es die Line of Death und oberhalb derer, also da auch typischerweise die URL-Zeit ist, da kann einfach kein Web-Content mehr malen, da sind die Tool-Bar-Icons und so weiter und ein bisschen drüber über diese Line of Death erscheint typischerweise der Permission-Propt.

11:32Sozusagen als Nachweis, dass das jetzt ein natives Browser-UI ist, also weil nur das kann dann eben dahin gerendert werden, ne? Richtig, dass man eben sagt, okay, als Benutzer, ich falle jetzt da nicht auf einen Fake-Dialog rein, der zwar so aussieht, als sei er offiziell, aber weil er eben unterhalb der Line of Death positioniert ist, ist es eigentlich so in Security-Kreisen zumindest angenommen. Den Benutzer, klar, okay, das ist fake. Aber ja, in der Praxis, die wenigsten Benutzer dürften das wirklich aktiv wahrnehmen.

12:05Auf Mobile ist das natürlich sofort ein anderes Thema. Auf Mobile scrollt das UI ja weg, das Browser-UI, wenn man ein bisschen in der Seite drin ist. Die Permissions werden dort historisch auf immer schon zentriert angezeigt. Auf Desktop, ja, war es üblich oder zumindest Chrome und Firefox auch, dass man die Permission oben links anzeigt, weil eben Line of Death. Ja, heute haben wir natürlich sehr große Monitore, wo dann jemand auf einem 27 Zoll Bildschirm mit verschiedenen Feinsten offen, vielleicht nicht wirklich sofort zieht, dass da ein Permission Prompt jetzt aufgegangen ist, wenn eine Aktion auf einer Seite war oder vielleicht auch so bei Onload irgendwas passiert ist und dann wundert sich dann, man klickt mit der Maus Bild drauf los, aber nichts passiert, die Seite reagiert scheinbar nicht und irgendwann realisiert man dann, oh, links oben war ja das Permission Prompt.

12:54Und genau, also da haben wir auch ganz viel wie du schon gesagt hast, der UX-Probleme, wo man sagt, okay, wie nimmt man das denn jetzt wahr als Benutzer? Soll man vielleicht den Hintergrund der Seite abdunkeln? Viele Seiten machen das ja automatisch schon. Soll man versuchen zu detektieren? Die Seite ist schon automatisch abgedunkelt. Ich brauche das nicht nur mit einem Blur-Filter machen auf quasi browser-nativer Ebene oder wie auch immer. Sehr schwieriges Thema, sehr spannendes Thema. Da gibt es ja noch so Aspekte wie zum einen, dass manche Permissions, glaube ich, brauchen ja auf jeden Fall eine User-Interaction auch.

13:32Und dann muss die Abfrage, oder wie ist das denn? Oder nee, Quatsch. Also ich glaube, bei den Permissions ist es nicht so. Es gibt ja diese Sachen, wo man User-Interactionen braucht, auf jeden Fall, bevor man überhaupt was benutzen kann. Eventuell gibt es das dann bei den Permissions. Dann gibt es wiederum dann zwei Wege. Das eine ist, dass ab dann alles freigeschaltet ist bei bestimmten Dingen und manchmal hat man nur eine Sekunde Zeit nach der User Interaction, bis dann die sozusagen die wieder ungültig geworden ist und man den nicht mehr machen kann.

14:05Das große Thema User Activation und da spricht man immer von Sticky und Non-Sticky, beziehungsweise Transient User Activation. Also sprich, du hast irgendwie auf einen Knopf geklickt, dann gibt es zwei Arten und Weisen. Sticky, das heißt, wenn du das einmal gemacht hast, dann zählt quasi deine Interaktion auf der Seite als registrierend. Ich glaube, das ist so Video-Play und sowas wäre so ein Fall, glaube ich, oder? Ich glaube, ja, genau. Und dann gibt es andere Fälle, wo man halt wirklich ganz explizit ein sehr kurzes Zeigfenster hat, innerhalb dessen man reagieren kann.

14:39Das ist zum Beispiel bei der Safari-Implementierung der Async-Clipboard-API so. Wenn man da was pasten möchte, dann erscheint ein Knopf, der quasi von Safari generiert wird und den muss man dann erst drücken. und erst, wenn man diesen Knopf gedrückt hat, erst dann ist die HTI freigeschattet sozusagen. Und das andere Ding ist, dass es ja auch so ist, dass wenn man bestimmte Permissions aktuell nicht vergibt, also zunächst ablehnt, dass es dann auch schwierig ist, das rückgängig zu machen.

15:11Also zumindest jetzt in Safari nicht. Der fragt jedes Mal neu. Aber in Chrome ist das ja der Fall, dass man erst mal oben dieses Einstellungsknöpfchen links in der URL-Bar drücken und finden muss. Und dass der Browser auch manchmal, glaube ich, sich selber da zwischenwirft und Dinge unterdrückt. Genau, wir sind dann beim Thema Machine Learning basiertes Notification Spam zum Beispiel erkennen. Und in Chrome haben wir dieses sogenannte Blue Chip Konzept, wo anstelle von einem modalen Permission Prompt on load in der URL-Bar so ein blauer Chip erscheint, wo dann entweder drinsteht Location zum Beispiel oder Notification Access erlauben, ja, nein.

16:04Und das ist dann zwar da, man kann immer noch damit interagieren, aber es ist nicht mehr aggressiv modal da, es blockiert nicht mehr die Interaktion mit der Seite. Das wird, wie gesagt, bei uns basierend auf ML. Was ist denn so historisch? Zum Beispiel die Akzeptanzrate von einem Notification Permission auf einer gegebenen Seite. Und wenn man da natürlich als Browser so eine globale Sicht hat und sagen kann, okay, was auch immer, 70% der Browser, Benutzer, die die Seite wählen, sagen typischerweise ja oder wenn man dann feststellt, okay, die Leute sagen zwar ja, aber sind dann sehr schnell wieder dabei und sagen, wir blockieren die Notifications.

16:47Das sind natürlich dann alle Signale, die man in so einen Machine Learning reinstecken kann und dann halt sagen kann, okay, was gebe ich denn jetzt heraus als Blue Chip oder Modaler Dialog oder das ist dann das Extrem, dass man sogar ganz einfach blockt und sagt, okay, da wollte zwar die Seite nachfragen, aber ich habe das als Browser blockiert, also ich bin da dazwischen gegangen und dann, wie du schon sagst, muss man in die Site-Settings gehen und dann eben manuell quasi wieder freischalten.

17:17Das kann passieren bei Seiten, die sehr spammig sind. Es kann dir natürlich aber auch passieren, du klickst aus Versehen auf Block, ohne dass du es wolltest, also blockierst du die Permission, weil vielleicht, keine Ahnung, du warst gerade dabei, irgendwas dort zu klicken, wo jetzt der Permission-Prompt erscheint und in dem Moment erschien dann der Prompt. Und da ist jetzt so eine sehr kurze Zeitspanne, wo der Prompt sagt, okay, wenn jetzt nicht innerhalb von, was auch immer, 500 Millisekunden der Klick erfolgte nach dem Erscheinen, dann zählt das nicht.

17:44Aber manchmal erwischt man es eben dann doch, dass man halt genau diese Zeitspanne verpasst und der Prompt dann den Klick registriert. Ja, oder man erst später merkt, was man davon gehabt hätte. Also wenn der Prompt zu früh kommt und dann ist man auf der Seite und merkt so, ah, kacke, jetzt Geolocation wäre vielleicht doch nicht schlecht gewesen. Genau, das nennen wir dann Permission Regret, dass man sagt, okay, ich hätte das jetzt gerne eigentlich doch gehabt. Und beziehungsweise es gibt es natürlich auch andersrum, wo wir ein Notifications-Thema sind.

18:14Man denkt sich, okay, News-Seite könnte bestimmt nützlich sein, aber dann spammen sie einem mit, was auch immer, Fußballergebnissen. Man ist überhaupt nicht sportinteressiert und die sagen dann, das sei Breaking News und man optet dann wieder aus. Genau, also das ist dann auch Permission-Reparated, aber halt andersrum sozusagen. Und dann ist es ja auch, glaube ich, so, dass gerade bei den historischen APIs, ich glaube, bei denen, die so Request-Permission unterstützen, Das sind so die neuere Generation, da ist es nicht der Fall.

18:42Aber bei den Älteren ist es, glaube ich, schwer herauszufinden, ob man eine Permission schon hat für was Bestimmtes, glaube ich. Oder wie ist das? Man kann einfach nur zugreifen und dann fällt das oder nicht. Es gibt die Permissions API, ja, ich hatte es schon erwähnt vorher, es gab ursprünglich Navigated Permissions Request, das wurde, wie gesagt, beerdigt, aber es gibt auch dort eine Methode, wo man sagen kann, habe ich denn die Permission, also ich glaube, Query heißt sie, also Navigated Permission.query und dann übergibt man auch so und wirkt und da kann man dann feststellen, habe ich denn die Permission, um was auf jeden Fall mit Notifications zu senden.

19:19Also das ist einheitlich implementiert. Genau, das ist auch sehr unumstritten. Da sind sich alle Browser-Vendor einig. Das ist eine nützliche API. Die wollen wir auch. Ja, damit man eben auch sozusagen weiß, ob wenn man jetzt auf Geolocation zugreifen würde, würde man dann erstmal wieder einen Prompt triggern. Also das will man ja vielleicht auch zu UX-Sicht dann in dem Moment nicht. Aber wenn man die Permission schon hat, dann könnte man das eben dann mit einbeziehen.

19:46Da macht das irgendwie Sinn. Und ja, also da haben wir dann auch schon so ein spannendes Thema mit quasi so zweiphasigen Prompts. Erstmal der interne Site-generierte Prompt. Das kann alles sein von, und dann hat ihr das Meme vielleicht schon mal gesehen, click here to prove that you're not a robot, und dann klickt man da als nicht wissend Benutzer, denkt das sei irgendwie so ein Capture-Gedöns und eigentlich ist das nur, um dann also die User-Gesture, um das Permission-Prompt anzuzeigen, gibt es dann natürlich aber auch in gutmütig sozusagen wo man dann Videokonferencing-Software ist und dann sagt, okay da wird jetzt gleich was kommen, klick hier um den Prozess zu starten, also Also ich habe mich hier gerade auf Sendcaster eingewählt.

20:29Das ist eine Plattform gleich, wo ich normalerweise nicht bin. Und bin dann eben genau diesen Freud durchlaufen, wo die Seite mich präpariert hat auf das Thema, okay, da wird jetzt gleich was kommen. Du musst da ja sagen, weil sonst geht es halt nicht. Ohne Video und ohne Mikro kein Podcast. Und genau, also das ist dann dieses zweiphasige System. Und da ist natürlich als Seite die Versuchung groß, dann diesen zweiphasigen Dialog so natürlich oder so quasi nativ wie möglich aussehen zu lassen, um eben den Benutzer zu tricken.

21:00Und ja, also Permissions, großes Thema, da ist Permission Abuse eben immer sehr, sehr spannend. Man denkt immer, es wäre doch schön, wenn, aber in Web gilt dieser Satz, man kann leider keine schönen Dinge haben. Es wird immer irgendwie missbraucht. Ja, und genau, da gibt es, also die Geschichte hinter den aktuellen Entwicklungen ist das 2023 auf der TPEC, das ist immer so das W3C, das jährliche W3C Wir-Kommen-Alle-Zusammen-Event, glaube ich, wo man auch die Gelegenheit nutzt und viele Themen versucht irgendwie mit allen Leuten zu besprechen.

21:44Da hat sich offenbar eine Gruppe Leute zusammengetan zu einer Web-Intubation-Community-Group letztendlich, die dieses Thema irgendwie baggern wollte. zu, ne? Genau, da sind wir dann beim großen Thema Pepsi, Page Embedded Permission Control, also P-E-P-C. Intern ist da so ein Soda-Drink entstanden, also Pepsi wird es dann ausgesprochen. Und die Idee war eben, aufgrund dieser ganzen Probleme, die ich jetzt erwähnt hatte, von Abuse bis Onload bis kontextualisierte Anzeige von dem Prompt und so weiter, dass wir das ganze Thema komplett neu denken. müssen.

22:28Und genau das ist eben geschehen mit dem sogenannten Page Embedded Permission Control. Die Idee war, dass das ein neues HTML-Element wäre mit dem schönen Namen Permission und dem HTML-Element würde man dann mit dem Type-Attribut beidrängen, für welche API an der Netzpermission möchte. Also ganz konkret würde man sagen, ja. Square bracket auf und dann sagt man Permission, Type-Attribut mit dem Wert Geolocation und dann hier Brackets zu und fertig wäre das Element.

23:03Und das würde dann gerendert werden als Button, wo der Browser automatisch merkt, okay, das ist ein Type-Geolocation, also fülle ich da entsprechend den Text ein, wie zum Beispiel UseMyLocation oder was auch immer. Es hätte auch noch ein Leng-Attribut gegeben. Das heißt, du könntest das dann auf DE setzen und dann würde das auf Deutsch automatisch vom Browser besetzt werden. Die Idee war, das Ganze sehr, sehr limitiert zu gestalten, was die Freiheit angeht, wie das aussehen soll.

23:34Also man gab dann eine Liste von CSS-Attributen mit und Werten, die man als Designer setzen kann und eben auch ganz explizit Sachen, die man nicht darf. Also zum Beispiel durfte man nicht mit der Transparency dieses Knopf, was spielen, also der Versuch wäre natürlich... Dass man den nicht schweben lassen kann über was anderem. Genau. Und man klickt es dann, ohne es zu merken. Richtig, dass man eben solche Tricks macht, wie der Knopf ist komplett transparent, man denkt eigentlich, man klickt was anderes, aber eigentlich klickt man den Knopf.

24:04Der Knopf darf nicht überlagert werden mit was anderem, also so, dass man irgendwas anderes drüber positioniert, dass dann vielleicht den Klick durchlässt und man denkt eigentlich, man klickt das andere Ding, ähm, letztendlich ist das so gesetzt, dass es, äh, die Klickaktion einfach durch passieren lässt über CSS, ähm, Davon auch nicht und das wurde dann sogar so weit ausgelegt, dass man selbst wenn man dem Ding einen Schatten gibt, dass dann über diesem Schatten auch nichts drüber liegen darf, weil natürlich einen Schatten kann man auch Tricks betreiben.

24:38Wer jemals CSS-Button-Designer gesehen hat, was die für crazy Tricks machen mit Boxshadow, ja, man kann den Schatten dann nach innen legen, man kann den Schatten irgendwie auf die ganze Seite ausbreiten und was auch immer. Und ja, da gab es eben dann sehr, sehr strikte Regeln, was erlaubt war, was nicht. Die Idee war, wie gesagt, dass über das Typ-Attribut oder Type-Attribut man dem Ratten beigebracht hat, was darfst du denn jetzt eigentlich damit erlauben oder nicht?

25:08Die Idee war auch zu sagen, okay, wir erlauben da mehrere Werte, also klassischerweise, wenn man jetzt so Videoconferencing hat, brauchst du ja eigentlich immer Mikrofon und Kamera zusammen, also es gibt zumindest bei vielen Videoconferencing-Systemen, dass man beides erlaubt. So ein bisschen wie das Videocontrols-Attribut, Und das wird dann auch so einfach so verschiedene Tokens, das Leerzeichen getrennt, glaube ich, entgegennimmt. Und bei Geolocation gibt es dann auch die, oder gab es die Idee zu sagen, okay, wir erlauben das jetzt vielleicht nur mit geringer Präzision.

25:43Also wenn du so quasi auf Geolocation IP eben, also ich bin ganz grob im Raum Frankfurt und das reicht dir als Info. Da könntest du sagen, ich brauche jetzt nicht auf dem Meter akkurat die GPS-Location, sondern der Browser kann das irgendwie anders über was auch immer Informationen er hat, der Seite zur Verfügung stellen. Und das wurde dann über ein sogenanntes Type-Axt-Attribut übergeben in einem JSON, wo man dann eben sagt, okay, das sind verschiedene Konfigurationsparameter, die die Geolocation-API oder was auch immer benötigt oder bei der Kamera, User-Media-Geschichte ist ja immer, welche Auflösung brauche ich und so weiter.

26:20Also halt einfach solche verschiedenen Werte. Und ja, das haben wir ausgerollt. Das ist so zeitmäßig, also Timeline-mäßig, das war dann so ein Jahr später, also so 2024, würde ich sagen, oder? Ja, so ungefähr. Also ich habe es jetzt auch nicht mehr 100 Prozent im Kopf. Da gab es einen Origin-Trial, da haben dann auch große Firmen mitgemacht, also Zoom zum Beispiel, die eben genau in dieses Problem reingelaufen sind, dass sie die Leute hatten, die eben nicht mehr sich in ihre Zoom-Meetings einwählen konnten, weil sie irgendwann mal die Permissions blockiert oder aus Versehen blockiert hatten.

26:55Und ja, mit diesem Permissions-Element konnten sie dann eben sich wieder auslupfen sozusagen und sagen, okay, ich möchte mich jetzt dann doch wieder an der Videokonferenz einwählen mit dem Videosignal. Und genau, das hat dann eigentlich sehr gut funktioniert. Die waren super zufrieden damit. Und ja, parallel haben wir dann natürlich mit anderen Mendooren gesprochen und Webkit und Mozilla ganz konkret gefragt, hey, was haltet ihr denn davon? Und ja, dann fing es an, kompliziert zu werden.

27:25Genau, wobei man sagen muss, ich glaube, die waren auch schon mit involviert bei diesem TPEC-Diskussionsrunde, glaube ich. Und genau, jetzt ging es sozusagen dann ans Eingemachtere und genau, dann fragt man ja immer die anderen Vendoren, was so deren Position dazu ist und, Je nachdem, um welche Themen es geht, kriegt man da Zustimmung oder eben auch ein bisschen mehr Gegenwind. Bei Permissions ist das natürlich schon ein schwieriges Thema. Genau, also ich erinnere mich an das erste Meeting, wo das vorgestellt wurde und Tess O'Connor von Apple meinte dann, und ich glaube, das Zitat ist relativ wörtlich, I don't immediately hate it.

28:15Das ist doch schon mal gut, von Apple ist das doch schon mal gut. Ja, das ist ja quasi so das, das veräppelte, die veräppelte Version von kein Lob ist, oder keine Kritik ist Lob genug, so. Genau, also ja, das war dann die primäre Reaktion. Es stellte sich dann am Ende raus, sie haben es doch nicht so toll gefunden. Und ja, es gab dann immer diese großen Diskussionen in den Issues, können wir dann natürlich für die Show-Notes verlinken. Mit der WebKit und mit der Mozilla-Stein-Up-Position.

28:51Was waren da so die vorrangigen Kritikpunkte der anderen Vendoren? Die Argumente waren erstmal so, wenn die Permission nicht kontextualisiert dargestellt wird, also das, was ich erwähnt hatte, mit dem großen Bildschirm und man klickt vielleicht in Google Maps unten rechts auf den Wo-bin-ich-eigentlich-Knopf und oben links erscheint die Permission und da sind, keine Ahnung, ist eine Album Meter dazwischen, dann kann natürlich ein Land nur sagen, ja, wenn ihr das in eurem Permission-Prompt so macht, dann ist das euer Problem.

29:17Das ist nicht ein Problem der API. Und damit haben sie natürlich ein Stück weit recht. Man kann natürlich auch sowas wie, ob man heute mit Anker Positioning macht, dass man versucht, dann in der Nähe von dem Klick, wo es eben gerade passt, also ein bisschen drüber, ein bisschen drunter, ein bisschen links, ein bisschen rechts davon, was auch immer, den Prompt dann anzuzeigen. Da ist dann natürlich wieder das Problem Line of Death, wo die Security-Leute meinten, ja, das ist ja ein Konzept, das können wir nicht einfach so über Bord werfen.

29:47Wie macht Apple das? Weißt du das aus dem Kopf, wie Apple das macht? Also wie verändern die dieses Problem, also dass, wenn man was im Webseiten-Bereich rendert, dass man theoretisch auch einen Fake-Request da reinrennen könnte? Ich glaube, sie verdunkeln die Seite und Und haben auch so ein Konzept of Line of Death. Aber bei Mobile ist das natürlich immer ein anderes Thema. Bei Mobile machen, glaube ich, alle Vendoren den Dialog zentriert und modal.

30:20Das heißt, man muss dann irgendwas damit machen und kann nicht quasi irgendwelche der hinterliegenden Elemente benutzen, solange dieser Dialog da ist. Okay, aber das könnte man dann theoretisch ja auch als Entwickler in Faken. Also fast. Ja, ein Stück weit. Also es gibt dann sogar Integration mit dem Backbutton. Also man muss ja nicht zwingend mit dem Dialog interagieren. Man kann ihn auch schließen. Das ist auch noch eine Möglichkeit teilweise. Und auf Android zum Beispiel kann man mit dem Backbutton dann quasi den Dialog dismissen und sich zu keiner Entscheidung durchringen.

30:59Am Ende wird dann natürlich der Dialog das nächste Mal wieder auftauchen. Ich bin dann teilweise so ich wollte nur sagen, du hattest ja eingangs erwähnt dass ihr ja auch diese Navigator Permissions API mal angedacht hattet, wo man so ein ganzes Objekt mit Abfragen reinsetzen konnte wahrscheinlich leidet dann dieses Permissions Element unter den gleichen Kontraargumenten dass es vielleicht zu viel auf einen Streich wäre in einem so einem Element, oder?

31:31Ja, also ich bin ja ein großer Freund von dem Konzept Permission Bundles und zwar semantische Permission Bundles. In Chrome haben wir, wie du schon erwähnt hast, ich war ja ursprünglich im Fugu-Bereich aktiv, wie wir das nennen, sehr mächtige Bowser-APIs und da haben wir solche Sachen wie File-Handling zum Beispiel, du installierst eine App und dann kann diese App zum File-Handle werden und wenn du dann auf .example-Files klickst, dann kann diese Applikation eben aufgehen als installierte PWA und alle deine .example-Files abfrühstücken und handeln.

32:04Das ist eine Permission, die ist natürlich interessant für Productivity-Apps, Editoren, ja, im weitesten Sinne. Und dann hast du solche Sachen wie Clipboard, du hast solche Sachen wie, ja, natürlich Installation an und für sich. Da gibt es ja auch eine neue API von Microsoft pilotiert, die Web Install API. Und ich bin ein großer Freund dann, wie gesagt, vom Thema semantische Permission Bundles, dass man sich dann versucht, zusammenzusetzen als Bedrohung und sagt, ja, okay, das ist jetzt eine Videokonferencing-Applikation, die braucht typischerweise Notifications, die braucht typischerweise Mikrofon, die braucht was auch immer, Kamera natürlich, aber sie braucht jetzt nicht, keine Ahnung, Web Bluetooth, dass man eben sagt, okay.

32:49Das sind jetzt die semantischen Video-Conferencing-Notifications und anstelle von für jedes Einzelne nachzufragen, könnte ich dann eben einmal sagen, okay, möchtest du für diese semantische Permission-Bundle die Permission geben oder nicht? Es gibt da irgendwo im Permissions-Reco ein Issue von mir offen, da ist jahrelang nichts passiert. Also da wollte man sich eben den Weg offen halten im Permissions-Element, indem man eben sagt, mit dem Type-Attribut, man erlaubt da verschiedene Werte, oder mehrere Werte, aber letztendlich ist da nicht wirklich arg viel draus geworden, wie gesagt.

33:26Die Vendoren waren dagegen, sie haben gesagt ein Stück weit, ja, das ist euer Problem, wenn wir das falsch anzeigen, in Anführungszeichen. Es ist euer Problem, wenn ihr Onload-Permissions erlaubt. Es ist euer Problem, wenn eure Site-Settings schwierig zu finden sind und so weiter. Aber letztendlich, irgendwann mussten sie dann schon einsehen, okay, auch ein Firefox-Benutzer, auch ein Safari-Nutzer hat sich mal aus Versehen verglückt und möchte dann wieder zurück auf die, was auch immer.

33:55Video-Conferencing-Permission und möchte die Kamera wieder verwenden. Und, ja, dann kam irgendwann die Idee auf, was, wenn wir das Ganze etwas spezifischer machen, weil, wie ich schon erwähnte, die Permission mit dem Type-Exed-Attribut, das wird dann natürlich relativ komplex, wenn du verschiedene, ja, sehr komplexe APIs, also Get-User-Media mit vielen, vielen Dingen, die du konfigurieren kannst, in einem JSON dann in so einem Attribut drin hast und, ja, da kam die Idee auf, was, wenn wir das aufsplitten, nicht ein Element das alles kann, sondern indem wir das aufteilen in verschiedene Elemente, die verschiedene Dinge tun.

34:36Aber dann auch sehr schnell die Idee, pass auf, wenn wir das Geolocation-Element haben, das sollte nicht nur die Geolocation, die, also die Permission, dir geben, sondern was wäre denn, wenn das eigentlich dir tatsächlich auch die eigentliche Geolocation gibt, im Sinne von den Wert, also nicht nur die Erlaubnis, sondern auch den Wert. Und das ist so ein bisschen in einem, ja, breiteren Kontext in letzter Zeit mit, ähm, ja, quasi deklarativen Ansätzen, ähm, also bei Button gibt's ja diese Inbooker, Comments und, äh.

35:08Die Dialoge können jetzt aufgemacht werden, ohne dass man dafür JavaScript braucht, indem man einfach nur die Invoker-API verwendet. Es gibt verschiedene Invoker-Commands, wie gesagt, wo du dann sagen kannst Next zum Beispiel als Invoker-Command und das sind eben wohl definierte Konzepte, die man eben deklarativ dann mitgeben kann im Element und ja, da war dann eben die Idee, okay, lass uns doch für diese verschiedenen Elemente, die wir jetzt uns einfallen lassen, also ganz konkret arbeiten wir bei Chrome-Team an Geolocation.

35:38Das ist jetzt in Chrome 144 geschippt worden und am User-Media-Element, das für Kamera und Mikrofon dann eben steht. Und genau, also da ist dann eben die Idee, wir machen nicht nur die Permission, wir machen auch die eigentliche Aktion. Und dann gibt es Event-Listener, auf die man sich registrieren kann, also man nimmt dann das Geolocation-Element zum Beispiel und registriert sich auf ein Position-Update-Event oder ein Position-Event, wenn die Position nur einmal nicht angefangen wurde und ja, auf diese Art und Weise kann man dann eben mit relativ wenig JavaScript-Code die gleiche Funktion realisieren, die man auch mit der, in Anführungszeichen, Legacy-Geolocation-API ähm, bekommen könnte.

36:25Und, ja, das Ganze ist natürlich dann, wie gesagt, deklarativ, ähm, die Geolocation-API ist ja, ja, ein Stück weit Legacy im Design, weil da sind Callbacks drin, würde man heute nicht mehr machen. Es gab, äh, in der diesjährigen TPEC-Diskussion, sollten wir vielleicht die, äh, äh, die API aktualisieren, modernisieren und, äh, sie Promise-based machen. Da war dann aber das Argument am Ende, okay, ähm. Komplett ist wahrscheinlich schwierig, weil nicht jeder erwartet jetzt, dass man dann Promise zurückbekommt, was, wenn jetzt jemand das anders verratet hat und da eben nichts zurückerwartet und auf einmal kommt Promise raus.

37:05Solche Dinge. Und dann eben einfach zu sagen, okay, aber wir lassen die API, wie sie ist, als historisches Artefakt quasi, aber wir schaffen einen neuen Weg, das mehr oder weniger Gleiche zu tun, aber besser. Das ist allerdings selten in der HTML, aber manchmal dann eben doch. Wenn ich jetzt mal meinen normalen Webentwickler, Webentwicklerin Hut aufsetze, kannst du mir das Ding nochmal verkaufen? Weil wenn ich jetzt irgendwie so als normaler Mensch unterwegs bin und ich werkele da jetzt irgendwie mit einem der populären Frontend-Frameworks darum, habe ich jetzt nicht so zu 100% die Überzeugung gewonnen, dass diese Features, wie zum Beispiel, dass das deklarativ und zentralisiert und in eine schöne API eingepackt ist, ein noch zu lösendes Problem ist.

37:50Wenn ich jetzt einfach mal so spontan google, wie integriere ich jetzt irgendwie Geolocation in mein React zum Beispiel rein, fliegen mir die Lösungen fertig installierbar in mein Framework direkt eingebohrt, die sprechen bereits die richtige Sprache, die fliegen mir haufenweise entgegen, und ich kann da ja dann auch jeden Style drumherum stricken, den ich haben möchte. Ich weiß, warum das keine gute Idee ist, aber wenn ich halt einfach nur jetzt so ein normaler Mensch bin, der irgendwie bitteschön dafür zu sorgen hat, dass das alles irgendwie so sitzt, wie Schäfer das haben will, bin ich doch wahrscheinlich eher geneigt, so mit dem alten Zeug weiterzumachen wie bisher, das alles einfach mit JavaScript wegzuabstrahieren.

38:26Warum will ich trotzdem das Geolocation-Element haben? Also ein Pattern, das wir sehen, ist, dass Entwickler dann eben sagen, okay, das ist Last Resort, weil es eben dieses Feature hat, dass man sich anblocken kann und im normalen Flow verwenden sie dann die alten APIs, so wie immer und eben komplette Style-Freiheit hat, aber haben dann eben diesen Emergency-Modus, wo man sich anblocken kann, wo dann das Styling erstmal legal ist, in Anführungszeichen, selbst wenn das jetzt nicht dem Design-System vielleicht von Zoom oder wem auch immer entspricht.

39:00Wichtiger ist dann eben, dass man eine Möglichkeit hat, sich da wieder herauszuarbeiten aus diesem blockierten Status. Also das ist ein Pattern, das wir sehen. Und ja, letztendlich natürlich, wenn du jetzt guckst, was gängige Praxis ist, was dir ein LLM ausspupft oder was auch immer, natürlich gibt es diese Lösungen fertig verdrahtet. Es gibt Geolocation in React oder was auch immer. Schon fix an alle, aber eben mit den bekannten, in Anführungszeichen, Nachteilen, die ich versucht habe, so ein bisschen zu erwähnen.

39:33Und ja, das Geolocation-Element zum Beispiel zeigt dir der Pervision-Prompt zentriert an. Es verdunkelt den Hintergrund von deiner Seite. Und dann hat es eine interessante Art und Weise, wie es quasi Stück für Stück, ja, dein Vertrauen gewinnt. Und zwar, wenn du das allererste Mal auf einer Seite landest, dann hast du die Auswahl zwischen erlauben bei jedem Besuch, also quasi für immer. Oder einmalig für die aktuelle Sitzung, also für den aktuellen Besuch.

40:07Wenn du das einmalig erlaubt hast, Und du zeigst das Element wieder an, dann wird der Dialog sich ändern und da steht dann drin Continue Allowing, also einfach nichts, mach einfach weiter so wie bisher oder Stop Allowing, also quasi, dass man wieder zurückrudeln kann und sich dann zurücksetzt auf den ursprünglichen Zustand und dann nochmal neu fragen muss. Wenn du aber dich blockiert hast, also wenn du eine Notification Permission, sagen wir, blockiert hast, dann kommt der Dialog auf und da steht dann drin als zwei Knöpfe Continue Not Allowing, also sprich, mach gar nichts, mach einfach weiter mit dem blockierten Zustand oder Allow It This Time.

40:48Also da geht dann nicht sofort Allow on every visit, sondern man muss quasi sich das Vertrauen zurückerarbeiten, dass man dann sagt, okay, für die aktuelle Sitzung darf ich dann die Permission zurückhaben und wenn du dann bei der nächsten Sitzung erneut fragst, dann bist du wieder in dem Zustand, wo du auch für jedes Mal erneut, Quatsch, für immer quasi die Permission dir erlauben kannst. Okay, also das heißt so kommunikationsstrategisch lese ich das als so ein bisschen, ja, du musst jetzt die Styling-Pille schlucken, aber dafür kriegst du halt eben diese grundsätzlich bessere API.

41:24Wir lassen die alte API, wie sie ist und willst du diesen besseren Mechanismus haben, musst du halt eben das machen über dieses Element. Das könnte man so sagen, ja. Also Design-Pilze ist jetzt nicht so schwer zu schlucken. Also es gibt da schon ein Stück weit. Ja, da kenne ich Leute. Ja, also ist auch ein Thema, das natürlich WebKit und Mozilla aufgebracht haben. Und das sind wir auch sehr schnell bei der Design-Sprache des Betriebssystems. Also, dass dann zum Beispiel die Orte verschiedene Erwartungen haben, wie sieht denn jetzt ein Betriebssystem aus.

41:58Also ich erinnere mich noch ganz, ganz früher, als Opera noch Presto verwendet hat, ich liebte deren Buttons. Die waren wunderschön. Und ich weiß noch, ich habe eigentlich täglich in den Bauch Firefox verwendet, aber als ich Screenshots gemacht habe, für Dokus oder so, habe ich immer auf Opera umgestellt, weil einfach deren Buttons so schön aussagen. Und ich glaube, da ist ein Stück weit auch, was eben Leute an ihrem Betriebssystem mögen.

42:23Also wenn du gewöhnt bist, auf was auch immer, Windows sieht den Knopf so und so aus und habt Schatten und fühlt sich 3D an und auf macOS ist alles flach und was auch immer, dann hast du eben als Designer eines Browser-Buttons mit den User Agent-Style-Sheets auch eben die Möglichkeit, wenn jetzt von was auch immer, iOS 18 zu Liquid Glass sich komplett alles ändert, dass du dann eben deinen Default-Button auch entsprechend anpasst und ja, dass dann eben mitgeht mit dem Betriebssystem.

42:54Oder wir machen es hier wie bei mir auf Linux, wo es in zwei Browsern komplett unterschiedlich aussieht. Ja. Und dann hast du natürlich auf Linux immer noch irgendwelche Legacy-Apps, die dann auf was auch immer TCL oder was auch immer Frameworks aufbauen und da wendest du eine Gnome-App in KDI und dann sieht es sowieso wieder anders aus und keine Ahnung. Also spannendes Thema. Aber viele wollen eigentlich als Entwickler natürlich die Design-Sprache, die über die Gritsche, überall umsetzen.

43:23Und da haben wir Design-Tokens, Design-Elemente. Und ja, da erreicht man dann natürlich einigermaßen schnell die Limits von den Styling-Optionen. Also man kann einiges ändern. Man kann den Knopf, zum Beispiel die Farbe ändern. Aber wenn man jetzt eben sagt, okay, unsere Farben sind aus irgendeinem Grund, was auch immer, so, dass der Kontrast nicht ausreichend ist, wenn man den Hintergrundknopf und den Text dann hat und man möchte das durchsetzen, weil halt die Designsprache so ist.

43:53Nicht, dass ich sage, das wäre gut, aber als konstruiertes Beispiel, da würde da die RDI eben dazwischen gehen und sagen, der Kontrast ist nicht gut genug. Und jetzt irgendwie optimistisch, dass ihr das gewinnen könnt, weil, also so, ich bin 100% bei dir, nur dass wir uns da nicht falsch verstehen. Alles daran finde ich gut, aber wenn ich halt eben so irgendwo beliebig mal Rechtsklick mache und mir die Source angucke. Da ist kein Button, das sind alles Diffs. Da ist kein Videoplayer mit Controls drin, das sind alles Diffs.

44:22Weil halt, obwohl du mit allem, was du sagst, recht hast, die ganzen Constraints von was halt eben die Company will, was das Designsystem will, hast du nicht gesehen, bringen die Leute dann doch immer dazu, dass du dieser erste Eindruck, dass man da, dass es auf dem ersten Eindruck kohärent sein muss mit dem Rest der Designsprache, dass das ja vieles andere überwiegt, dass da ja gewaltiger Aufwand betrieben wird, um da einfach auch nur den letzten Pixel richtig zu machen.

44:47Und dass man diesen besseren Flow hinkriegt, sozusagen, dass das so das Zuckerbrot ist, wofür man dann halt das Bittere trinken muss, was da ist. Halte ich für sinnvoll. Würde ich sofort mitgehen mit dem Deal. Aber ich frage mich halt nur, ob so der aktuelle Zustand mit dem, was wir halt so als HTML ausgespuckt kriegen, nicht ein bisschen so Zweifel erwecken kann daran, ob das dann reicht. Für mich reicht es, aber reicht es da draußen für die Diff-Horde?

45:14Das werden wir sehen. Also wie gesagt, das Pattern, das wir sehen, ist, dass man eben das als Last Resort einsetzt, wo das Styling dann ein Stück weit egal ist. Aber klar, also das ist noch sehr, sehr frisch, sehr, sehr jung. Die Restrictions, die man jetzt auf der CSS-Ebene hat, die könnte man vielleicht auch dann, wenn man sieht, entsprechende Patterns, werden sich irgendwie, keine Ahnung, rausbilden, dass man sagt, okay, man lockert da ein bisschen was auf.

45:42Also eine Sache weniger strikt zu machen, das ist immer möglich. Andersrum wird es schwieriger, wenn das Thema WebCompat dann mit dazu kommt. Du hast ein wichtiges Thema erwähnt, nämlich Accessibility. Und es gab vor kurzem diesen Blogpost, der so durch die sozialen Medien geistete, irgendwie die, was hieß irgendwas mit, die incredible complexity of the chat CDM. Sogar der Peter gepostet. Ja, da machst du dir den ganzen Tag Mühe irgendwie tolle Texte zu schreiben und schöne Sachen zu dingsen und dann kopierst du nachts irgendwie im Suff einen Link von Hacker News in Mastodon rein und plötzlich geht das Ding ab wie nichts Gutes. Ja.

46:25Also gegen den Check werden viral und ja, klar, also mir ist es auch unverständlich, was da passiert ist und warum wir Entwickler uns da, keine Ahnung, reinlocken lassen haben in diese Falle. Aber klar, das moderne Web, bin ich voll bei dir, ist leider weniger semantisch als HTML und mehr Diff-Suppe. Aber, und da komme ich da zurück zum Thema Permission oder Element, beziehungsweise Geolocation Element, wenn man eben genau dieses Element hat, dann kann das eben auch entsprechend exponiert werden auf der Accessibility-Leben.

46:59Also, da kann dann jemand, der Assistive Tag verwendet, eben ganz genau sehen, okay, das ist ein Button, der hat vielleicht mehr Power als der reguläre Button, der vielleicht einfach nur als Link gestylt ist. Das ist ein Button, der hat eine Geovocation Permission dahinter. Ich sage nicht, dass Assistive Tech das heute schon verwendet, diese Informationen, also im Accessibility Tree kann das natürlich exponiert werden als Button mit spezieller Superpower, aber ja, das ist eben eine Möglichkeit, dass man das dann auch für Leute von dieser Zielgruppe entsprechend einfach deutlicher macht, was denn da passieren kann, wenn man diesen Knopf drückt. Mhm.

47:39Aber am Ende des Tages hat man doch trotzdem so ein Disconnect zwischen dem, was dann der Flow für Permissions von einer Web-App ist versus eine Airquotes-native App, oder? Weil sozusagen geht ja dann der Browser hin innerhalb einer gewissen Grenze. Ich scrolle hier gerade schon die ganze Zeit durch die Spezifikationen. Gestaltet der halt aus, wie dieser Button sich darstellt und wie der Dialog halt so aussieht und was halt so der Flow ist. Und das ist doch wahrscheinlich in jedem Fall dann ein anderer, als der, den man halt tatsächlich von so einer nativen App gewohnt ist.

48:13Wäre das nicht eigentlich viel cooler, wenn man irgendwie sowas hinkriegen könnte, wie so irgendwie sich in die nativen Permissions-Konstruktionen reinzuklinken aus dem Web heraus und das dann irgendwie so zu adaptieren, dass man so eine Bridge macht, statt das sozusagen einfach zu abstrahieren, was ja letztlich das ist, was dann der Browser macht. Und man hat halt dann pro Browser eine Abstraktion. und das ist irgendwie dann auf meinem iPhone komplett anders als auf meinem Firefox zu Hause auf dem Laptop.

48:38Ja, interessantes Thema. Da ist Apple tatsächlich ziemlich weit, weil die sagen für ihre Homescreen-Web-Apps, also sprich Applikationen, die man zum Home-Bildschirm hinzufügt oder zum Dock hinzufügt auf Desktop, dass eben genau diese Integration erfolgt. Und bei Mac bist du, ja, gewohnt, wenn du eine Notification von irgendeiner App revoken möchtest, dass du in die Permissions gehst und dann suchst du den Privacy und Notifications und was auch immer und dafür bist du dann alle Apps aufgelistet.

49:10Und da erscheinen eben auch installierte Apps, die du auf deinem Dock, auf den Homescreen hinzugefügt hast. Windows macht das, glaube ich, auch ein Stück weit schon mit den installierten Apps. Aber schwierig wird es natürlich bei, was wir das Drive-By-Web nennen. Also sprich, wenn du jetzt einmal auf CNN warst und CNN fragt dich, möchtest du Push-Notifications anzeigen und du sagst ja, dann ist wahrscheinlich die Erwartung weniger, dass das in den Betriebssystem-Settings erscheint, als vielmehr, dass das irgendwo in den Browser-Settings erscheint.

49:42Und ja, also da ist dann natürlich die Frage, inwieweit kann man da integrieren, inwieweit sollte man da integrieren. Und ich glaube, was derzeit die, also wie gesagt, Microsoft auf Edge und auf Windows und Safari auf sowohl Mac OS als auch auf iOS machen, das ist schon ziemlich cool. Aber ja, es ist natürlich dann ein Stück weit schon ein Paradigm-Shift, weil das ist dann eine echte App im Sinne von, die Leute denken drüber als eine App und suchen entsprechende Settings.

50:16Und dahin möchte Apple natürlich auch die Leute erziehen, wenn sie das machen. Aber, ja, die sagen immer auch ganz klar, und das ist dann wiederum der interessante Kontrast, jede Webseite soll installierbar sein, im Sinne von, ich möchte example.com zum Doc hinzufügen, dann darf ich das auf Safari machen, einfach so. Und natürlich hat example.com keine Permissions oder sowas. Aber, ja, es gibt da keine, ja, quasi Schwelle, die man überschreiten muss, im Sinne von, example.com braucht kein Web-Web-Manifest, Die brauchen keinen Service Worker, die müssen nicht offline fähig sein.

50:54Safari sagt da einfach ganz klar hart, du solltest das Recht haben. Das haben sie übrigens schon immer so gemacht, das ist keine neue Entwicklung. Aber dann sind sie andererseits auch wieder abgeneigt, dir zu erzählen, als Webentwickler bist du denn jetzt installiert oder nicht. Also es gibt ein Navigator-Standalone, also Safari-Ding, das dann quasi sagt, ich bin jetzt installiert oder nicht. Das ist aber kooperativ und ja, die anderen Vendoren haben verschiedene Zwischenelemente quasi.

51:24Also du kannst über das Verbband-Manifest ja sagen, ich möchte installierbar sein, aber zum Beispiel im Minimal-UI-Mode, also dass du nicht komplett das Browser-UI wegkommst. Sondern dass du halt Eck, Vorwörtel und so weiter als Buttons noch beletzt und dadurch keine eigene Navigation bauen musst. Und das ist natürlich dann so ein Konzept, ja, soll da Navigate-Stand-Ownung ja sagen oder nein sagen? Und da wird es dann sehr, sehr schwierig. Das ist nämlich so ein bisschen abgewichtigt vom Thema, aber Permissions kommen eben da auch mit rein.

51:55Gerade bei sowas. Also was ist denn jetzt eine wirklich installierte App und was ist eine Webseite, die du zum Doc hinzugefügt hast? Und ich würde es halt auch auf dasselbe Grundproblem hinzufügen, als dass man jetzt hier ja versuchen muss sozusagen aufzulisten, was gibt es alles in der Welt an Permissions und an Failure-Modes und was nicht allem, ist dann ja bei diesem Progressive Web-App-Ansatz ähnlich. Es gibt halt da in der Definition halt installiert oder nicht installiert, aber es gibt halt dann eben auch so Dinge dazwischen, wie halt eben mit dem Minimal-UI.

52:25Und das ist halt eben das Schwierige, da irgendwann zu sagen. Wir machen jetzt sozusagen eine Bibliothek auf von Dingen, die existieren, Und das erinnert mich halt immer so ein bisschen an so alte CSS-Media-Types hier. Print TV hast du nicht gesehen, wo man ja irgendwie auch die Idee hatte, es gibt halt so ein endliches Set an Geräten oder Betriebsmodi und die haben halt inhärent irgendwelche Fähigkeiten. Und das ist dann halt einfach irgendwann dahin gegangen.

52:52Und da muss man dann, glaube ich, auch gewaltig aufpassen, dass man das richtig macht, weil sonst haben wir halt dann so ein Media-Type-TV und schauen dann in fünf Jahren darauf, so wie wir es heute eben auf diesem Media-Type-TV machen. Das ist halt immer so das Ding, wo bei mir bei sowas immer die Alarmglocke angeht, ob das wirklich durchdacht ist und ob das jetzt wirklich eine gute Idee ist, diese Dinge wirklich so festzuschreiben in so eine Spezifikation, in so einen Webstandard, der ja dann nie wieder weggeht. Und dann hat man das bis in alle Ewigkeiten an der Backe.

53:18Deswegen mache ich hier gerade so ein bisschen das Red-Team mit meinen ganzen Bedenken. Das ist dann natürlich, was du vorher erwähnt hast, mit nativen Apps das Ganze vergleicht, da ist das ganz, ganz anders. Bei Android kannst du einfach sagen, okay, ab was auch immer Android 16 muss dein Mindest-Android-SDK so und so sein. Und das hast du halt im Web einfach nicht. Das heißt, sagst du dann, ja, die allererste Website kannst du heute noch aufmachen und wenn jemand BG-Sound oder Marky oder was heute mal verändert, dann sollte das in den allermeisten Fällen auch heute noch funktionieren.

53:54In ganz, ganz wenigen Fällen rudelt man zurück. Also zum Beispiel Geolocation ist ein gutes Beispiel, wo man gesagt hätte, ursprünglich, als das Web noch naiv war und alles über HTTP lief, da konnte die API einfach so aufgerufen werden. Und jeder, der dann natürlich sich auf ein Leland gesnifft hat, konnte einfach mithören, was ist denn jetzt die aktuelle. Geolocation, wenn das dann irgendwo übers Netzwerk gesandt wurde, ohne Verschlüsselung, Und das ist einer der wenigen Fälle, wo man dann gesagt hat, als wenn du, okay, das ist in einer anderen Zeit entstanden.

54:28Es gibt natürlich heute noch HTTP-Only-Seiten, die die Geolocation API verwendet haben. Aber wir machen das jetzt ganz bewusst kaputt, weil, ja, die Risiken sind einfach so viel höher als der Nutzen. Und, ja, wenn jetzt wirklich jemand diese uralte Experience nochmal heute verwenden möchte, na ja, da muss man halt irgendwie dafür sorgen, dass das, also Browser-Flags kann man das da zum Beispiel ausschalten oder man kann nicht der reguläre Benutzer, aber natürlich als Entwickler, oder dass man dann halt überlegt, vielleicht gibt es jemanden, der sich bereit erklärt, diese alte App irgendwo neu zu hosten, wo dann eben HTTPS-Verschiss aktiv ist.

55:09Ja, und so, spannend ist die war. Aber ihr habt auch, glaube ich, eine Frage auch beantwortet, die ich noch im Kopf hatte und zwar, du hast ja eben beschrieben, wie dieses Fenster, dieser Permission-Dialog sich unterscheidet, je nach Szenario oder je nachdem, also ob man jetzt direkt am Anfang einmal draufdrückt oder beim nächsten Besuch und so weiter. Und da habe ich mich gefragt, ist das jetzt was, was auch Teil des Standards ist, dass ihr eben diesen Flow dann auch im Standard festschreibt oder stark empfiehlt oder ist das nicht der Fall?

55:51Und wenn ich das jetzt so rausgehört habe, dann ist das wieder komplett Entscheidung der Browser-Vendoren, wie sie das dann darstellen, oder? Ist das korrekt? Also das wäre jetzt auf meine erste Reaktion. Peter hatte die Speck-Parallel mal durchgelesen. Vielleicht kann er uns da korrigieren, aber meine Erwartung ist, dass das tatsächlich User-Agent-Specific-Behagier ist, wie das immer so schön heißt in Speck-Language. Aber so im Chrome-Team ergibt das für uns erstmal Sinn und andere Browser, also wie gesagt, Safari erlaubt ihr, der erlaubt ihr ja gar nicht, für immer die Permission zu geben für Geolocation zum Beispiel.

56:36Also ich nehme sehr stark an, dass das eben nicht in der Spec-Vertrate ist, sondern dass das jeder Vendor machen kann, wie er möchte. Ja, also kurzer Bericht aus den Spezifikationen. Wird halt sehr viel gelistet, was man halt eben alles nicht machen kann, welche Properties verwendet werden können, welche nicht. Erinnert mich so ein bisschen irgendwie an hier CSS, Pseudo-Element, First Letter. Da gibt es ja auch eine endliche Menge von Dingen, die man damit anstellen kann.

56:59So sieht das hier aus. Und ansonsten lese ich das auch als weitestgehend den Browsern freigestellt, was ja auch Sinn macht, weil wer weiß, was da morgen für ein Browser erfunden wird, der dann irgendwie ein komplett neues UI-Paradigma erfindet. Keine Ahnung, das Metaverse kommt nochmal um die Ecke und dann hat man da ja ganz andere Bedienmechanismen und dann ist es halt irgendwie schlecht, wenn man da sagt, das muss als Rechteck gerendert werden, wenn man in der 3D-Welt unterwegs ist, um jetzt wirklich das dämlichste Beispiel von allen heranzuziehen, ne?

57:26Das muss man halt eben immer alles mitbedenken. Das sieht erstmal vernünftig aus, auch wenn es spannend ist, hier Importance alle im User-Agent-Stylesheet zu haben, aber meine Güte, jeder Jack ist anders. Ja, ich habe, ich kam nur drauf, weil ja eben auch ein Argument für dieses neue Element ist, dass der ganze Abfrage-Flow halt auch cooler ist für die Benutzenden, aber genau, das ist jetzt im Fall von Chrome so und muss nicht unbedingt bei anderen Browsern so sein, sofern die dieses Element implementieren.

58:03Weißt du, wie da der, also wie der Stand bei den anderen Browser-Herstellern ist? Also sind die da jetzt mit dieser Variante, sind die da an Bord oder also mit der nicht allumfassenden Permission? Genau, also es gab ja die Standard Permissions oder Standard Positions so Standard Positions. Abfragen für das Permissions Element ursprünglich und ja, da waren eigentlich beide eher negativ und jetzt müssen wir natürlich für jedes Element, an dem wir arbeiten, eine eigene Abfrage stellen und der aktuelle Stand ist, Mozilla ist positiv, vermutlich, was jetzt Geovocation angeht.

58:47Ich glaube, das ursprüngliche oder die endgültige Firmen, die endgültige Entscheidung, das noch nicht gefallen, aber es gibt einen Kommentar, wo sie sagen, okay, also Also, sieht so aus, basierend auf der oberen Diskussion. Wir können uns darauf einigen, dass wir positiv sind. WebKit steht, soweit ich weiß, noch aus. Aber, ja, wir können das alles natürlich für die Show Notes. Wer sich dann dafür interessiert, kann auf die Azure sich subscriben und dann natürlich sofort erfahren, wenn es da Neues gibt.

59:16Aber, ja, also mit der Entscheidung im Chrome-Team, das jetzt zu shippen, ist natürlich schon mal ein Stück weit, ja, die Katze aus dem Sack. Wenn es da jetzt irgendwelche, ja, nach dem Ship-Event von Chrome Design-Changes gibt, da wird das Co-Team dann eben sehr schnell sagen, zu spät können wir nicht mehr ändern, wir haben jetzt geschippt. Das ist jetzt halt so und ihr hattet Zeit, euch zu einigen. Das Google Search Team ist sehr am Geolocation Element interessiert, von dem her ist da entsprechend natürlich auch Traffic und Druck dahinter, dass, ja, das rauskommt.

59:56Und die hatten auch einen AB-Test, also wenn man in der entsprechenden Testgruppe gelandet ist, konnte man das auch in the wild tatsächlich schon erleben. Ursprünglich eine Permissions dann mit dem Geolocation Element heute. Und, ja, also ich bin gespannt, was da passiert. Im Prinzip ist das natürlich auch polyfillbar, also ich habe selber das polyfill geschrieben, das gibt dir natürlich keinerlei ja, Benefits im Sinne von du kannst sagen, wenn du dich blockiert hast, was den Permission angeht, kannst du dich nicht entblocken, aber du kannst zumindest das Marker verwenden, also das heißt, wenn du das aktuelle Marker verwendest, dann wird das vom polyfill ersetzt durch ein Custom Element, ja, das dann eben Geo-Dash-Location heißt und das dann intern sich quasi reinhängt in die alte API, also mit den Callbacks und so weiter und dann eben entsprechend sich quasi darstellt und reagiert.

1:00:52Also das hat es so nicht viele Features im Sinne von, es unterstützt zum Beispiel das Leng-Attribut noch nicht. Also ich habe das nicht übersetzt in alle, was auch immer, 180 Sprachen oder was auch immer, die Chrome unterstützt. Sagt mal kurz, welche Sprache nutzt es dann jetzt aktuell? Also es ist dann, gibt es so ein Subset von Sprachen oder ist es dann quasi die Browser-UI-Sprache oder ist es die Webseiten-Sprache, die genutzt wird? Also bisher ist es einfach Englisch. Also da war ich sehr, sehr pragmatisch, was das Polyfill angeht. Dein Polyfill, okay.

1:01:24Das Polyfill, genau. Das native Element, das verwendet alle Sprachen, die Chrome unterstützt. Also ich habe jetzt keine Anzahl, wie viele das sind, kann man sich irgendwo nachlesen, aber da hat sich das Internationalization-Team entsprechend dahinter geklemmt und das dann in alle Sprachen sinnvoll übersetzt. Und da sollte eine API mal dran, dass man das auch rausholen kann. Ach so, ich dachte hier für die Formularfehlermeldung. Das kannst du ja sowieso, das ist ja das Ding, das war genau meine Idee.

1:01:53Du kannst ja zu einem irgendwie invaliden Formularelement gehen und sagen, gib mir die Validation Message und dann ist die halt in der Sprache, wie es auch im nativen UI wäre. Und genauso könnte ja die Beschriftung von so einem Element und die ganzen Sprachdinger ja auch einfach was sein von wegen, gib mir halt eben das, was du da anzeigst. Weil wenn eh schon durchstandardisiert ist, was da so die Bestandteile sind, wenn das UI schon halbwegs fixiert ist, Wäre das ja nicht schlecht. Also eine Art Alternativtext, den man dann da rausholen kann, damit man den selber als einen Alternativtext verwenden kann. Das finde ich gut.

1:02:23Das wäre bestimmt praktisch. Vielleicht irgendwann mal in der Intel-Agei oder so. Wenn man jetzt natürlich denkt, wie kann ich das hacken, denkt man vielleicht sehr, sehr schnell an Foreign Object in der Canvas. Das geht aber leider nicht. Also man kann das nicht screenshotten, weil du könntest dann auf diese Art und Weise dir Informationen holen, die du vielleicht nicht haben möchtest. Sollen dürfte es, also dieses klassische, selbst wenn der Link als besucht dargestellt wird, also sprich in lila, dann wird er trotzdem über Get Computed Style und so weiter, auch wenn du ihn auf der Canvas malst, eben als Grundfarbe hergestellt und ich glaube eine ähnliche Entscheidung wurde dort auch getroffen.

1:03:03Es gibt gerade eine Diskussion zum Thema Canvas in HTML. Ja, andersrum, HTML in Canvas. Natürlich habe ich es genau verdreht. Also HTML in Canvas, wo die Idee eben ist, dass Canvas gerenderte Applikationen trotzdem auf HTML zugreifen können sollen, um dann eben zum Beispiel Accessibility besser zu machen. Und das ist eben auch eine Frage von WebKit zum Beispiel gewesen, wie interagiert denn das Permissions-Element oder das Delocation-Element dann mit diesem HTML in Canvas?

1:03:37Was sollen wir da dürfen, was sollen wir da nicht dürfen? Soll es da Hit-Testing geben? Also sprich, kann ich das dann vielleicht irgendwo tricksen, indem ich das mische und auf die Canvas male und darunter HTML schiege und dann vielleicht doch irgendwie auf den Abuse Case komme, dass der Benutzer irgendwas klickt und dann eigentlich nicht merkt, darunter steckt das Geolocation Element und das wird dann eigentlich geklickt. Also spannende Diskussion. Ich glaube, da sind wir noch nicht zu den Entscheidungen gekommen, aber prinzipiell, die Abuse Cases sollen eben unmöglich gemacht werden.

1:04:11Ja, das ist natürlich auch ein schwieriger Wettstreit mit den Security-Forschenden. Also ich hätte jetzt das formuliert als Challenge accepted, aber okay. Ja, das auch, genau. Also die Hörenden können sich ja gerne mal daran versuchen. Es gab ja letztens jetzt hier diesen Hack, wo mit SVG-Filtern gearbeitet wird. Und man, also das war richtig cool. Also das können wir auch nochmal raussuchen und verlinken. das ist schon krass und sehr schwer irgendwie zu kontern.

1:04:43Aber naja, so ist das halt im Web. Wenn man viel machen kann, kann man auch viel, viel Unsinn treiben. Ja, kann man. Ja, das macht ja auch Spaß, aber naja, manchmal ist es halt dann zum Nachteil. Du hast gerade gesagt, ihr kümmert euch als nächstes um User Media, also ein Element, das das macht, was du ja auch vorhin bezeichnet hast unter semantischen Paketen, glaube ich, oder Permission-Paketen, also dass man in einem Rutsch dann alles, was irgendwie mit Audio-Video-Medien zu tun hat, abfragen kann.

1:05:23Wahrscheinlich, weil das auch eine der antikeren APIs ist und wahrscheinlich, weil auch das Google Meet Team vielleicht sich freuen würde, wenn es das gibt, nehme ich mal an. Was habt ihr dann noch so vor? Da gibt es doch schon so einen Plan, eine Roadmap? Also User Media, das sind wir noch mittendrin. Es gibt aktuell einen Origin-Trial, wo man das schon mal testen kann. Aber in den Standards-Positionen, da wird eben auch diskutiert, Ist das dann gut?

1:05:53Sollte man vielleicht doch ein Kamera-Element haben und ein Microphone-Element haben und das eben nicht bündeln und dann vielleicht irgendwie versuchen, wenn beide gleichzeitig erscheinen und man das eine klickt, dass man dann eben vielleicht so eine Art Heuristik haben kann und sagen kann, okay, dann ist es ja wahrscheinlich, dass beide geklickt werden oder so. Also da gibt es aktuell, glaube ich, in der Mozilla-Standards-Position einen kleinen Unterthread dazu.

1:06:20Aber ja, das ist alles sehr, sehr im Flux, wie man so schön sagt. Wenn du jetzt fragst, was gibt es noch für zukünftige Elemente oder wird es vielleicht geben, da habe ich erstmal konkret nichts, was ich teilen kann. Man könnte sich natürlich alle Dinge vorstellen, für die man Permission erfragt, also angefangen von Notifications bis, keine Ahnung, es gibt in Chrome eine API, die nennt sich Idle Detection API. Die eben feststellt, benutzt du gerade deinen Computer oder nicht?

1:06:52Und der, wo fängt man an, wo hört man auf, ist dann natürlich eine große Frage. Letztendlich bei sowas ist immer natürlich der Grundantrieb, was wollen denn unsere Partner? Wenn jetzt eine große Firma einen guten Use Case hat und motivieren kann, warum man die ABC-Permission als eigenes Element haben sollte, weil eben viele Leute das Problem haben, dass sie sich in diesen geblockten Status navigieren, dann schaut man sich das natürlich an und der, wie auch immer, PM, Product Manager, trifft dann die Entscheidung und sagt, okay, das wollen wir haben.

1:07:28Und dann geht eben der ganze Prozess von vorne los. Und dann sagt, okay, sollte man das als Element haben? Was sagen die anderen Vendoren dazu? Ist das so, wie sich Webnetwick ja das vorstellen? Also bei User Media, ich glaube, der aktuelle Stand ist, anstelle von einem Attribut, das dann JSON zur Konfiguration annimmt, was ja in einem Attribut sehr ästlich ist. Macht man quasi so ein Script-Tag als Kind-Element davon und in dem Script-Tag setzt man dann die Sprache auf oder den Type auf, was auch immer, Application JSON oder sowas, also nicht Text, JavaScript oder so, sondern auf JSON und auf diese Art und Weise kann man das dann eben auch schön darstellen und beautifien und es sieht dann auch vernünftig aus.

1:08:14Ja, das ist auch so ein bisschen im Trench gerade noch. Ja, also im Moment zum Skript. Ich hätte jetzt mehr so etwas in Richtung XML gehofft, dass man halt so irgendwie so, ne, oder so Picture und Source mäßig... Dass man da einfach so Unterelemente hat, die dann sozusagen das konfigurieren und wo es dann irgendwie so einen Selection-Algorithmus gibt, der da durchrattert und so sagt, keine Ahnung, das sind halt jetzt sozusagen die Konfigurationsoptionen für das Parent-Element.

1:08:41Wie gesagt, gibt es ja in XML, aber gibt es ja auch in Form von Picture und Video-Source und ähnlichem in HTML. Ich glaube, das kommt dann so ein bisschen auf die Tiefe der Verschachtelungsmöglichkeiten an. Und irgendwann ist es dann ein bisschen eklig als XML oder als SGML oder wie auch immer Markup Language. Also die Speculation Rules sind ja, glaube ich, so und zusammen mit JSON-LD sind die zwei Vorbilder. Ich glaube, die im Markup, also ich meine, JSON-LD konnte man ja immer schon auch im Markup ausdrücken, aber es ist schon anstrengend.

1:09:16Ja gut, aber mir ist es denn weniger anstrengend, irgendwie zu sagen, okay, es gibt jetzt irgendwie 37 verschiedene Varianten davon, was Script bedeutet. Also wir haben einen HTML-Tag und der macht, lass mal kurz überschlagen, im Standard mindestens drei verschiedene Dinge. Um einen vierten draus zu machen, also vielleicht kann man ja auch was Neues erfinden. Muss ja nicht alles Script sein. Da muss auch, ja. Muss auch rückwärtskompatibel sein, etc. pp.

1:09:40Ja, muss man sich halt mal ein bisschen anstrengen, nicht alles auf Script schieben. Da geht bestimmt was, da bin ich mir sicher. Ja, okay. Naja, also User Media ist zurzeit noch im Design. Also wenn du da einen XHTML2-basierten, keine Ahnung, Vorschlag einbringen wolltest, da könntest du das natürlich tun. Also das ist ja alles, wie Shep schon ganz am Anfang erwähnt hatte, in einer Community Group betrieben. Also da ist ja wirklich die Einstiegshürde sehr, sehr gering.

1:10:09Jeder, jede kann einfach Mitglied werden. Man muss nicht W3C-Mitglied sein mit der Firma, sondern ja, das geht einfach ganz direkt über den persönlichen Draht. Man sagt einfach, okay, ich bin interessiert, an der WICG-Gruppe so und so teilzunehmen. Und man geht durch das Formular und ist dann drin. Und ob man dann aktiv wird oder nicht, bleibt jedem selbst überlassen. Aber ja, also natürlich, der Design-Space ist da sehr, sehr, sehr offen. Natürlich sucht man oder versucht man, dass man das ein Stück weit so einfach wie möglich hält, so benutzerzentriert wie möglich hält.

1:10:46Aber klar, wenn man dann sowas wie GetUserMedia hat, wo eben verschiedene Dinge vielleicht sich ausschließen, wo man dann verschachteln muss, wo man sagt, ich habe vielleicht sogar zwei Konfigurationen für Portrait, was anderes als für Landscape oder was auch immer. Ja, dann muss man sich halt angucken, was ist da die bequemste Art und Weise. Und wenn man dann halt denkt, man macht das vielleicht als XML, HTML, SGML, Elemente, was auch immer, die müssen ja dann auch alle spezifiziert werden und dann in Parse mit reingenommen werden.

1:11:19Also sowas in JSON zu machen, ist dann deutlich einfacher. Aber ja, wenn es Sinne gibt, warum nicht? Also ist dann wahrscheinlich immer den Umständen des Einzelfalls geschuldet, was man da entscheidet. Ja, JSON in Attributen ist halt immer so, du hast ja plötzlich Exceptions in HTML, wo du ja normalerweise eigentlich den HTML-Parser als den ultimativen Müllschlucker hast, der alles nimmt. Aber sobald du da ungültiges JSON reinschreibst, dann bist du halt irgendwie so, was ist das dann?

1:11:46Also klar, funktioniert dann ja noch für bestimmte Werte von Funktionieren. Aber irgendwie so, also ist auch immer die erste Lösung, zu der ich greife, bin ich halt dann meistens auf lange Sicht nicht der Fan von. Du sprichst also aus eigener Erfahrung. Vielleicht ein bisschen. JSON in Attributen, ich glaube, das war mit dem Type-Exit, hat man sehr schnell gemerkt, das ist keine gute Idee. Also der aktuelle Ansatz ist dann immerhin ein Script-Tag mit einem speziellen Typ, der dann das ausweist als, hey, ich bin nicht JavaScript, sondern ich bin halt irgendwas, das keine Bedeutung hat.

1:12:21Außerhalb dem Kontext von jetzt dem User-Media-Element. Und dann kannst du dann natürlich deinen JSON einprügeln und BenPretty drüber drauflusten und das sieht auch schön aus. Aber ja, also ihren Attributen, das will man, glaube ich, wirklich nicht haben. Nee. Nee. Genau, die Einladung, die du gerade Peter oder uns ausgesprochen hast, die gilt natürlich auch für alle Hörenden. Wer das Thema interessant findet und irgendwie jetzt noch gerne seine Meinung kundtun, Einfluss nehmen möchte aus seiner vielleicht implementierenden Perspektive, dann geht Geht dort gerne hin und lest mit und bringt euch rein.

1:13:04Wir werden es auf jeden Fall auch in die Show Notes packen. Genau, beziehungsweise man findet die Links auch in euren Posts zu dem Permissions-Element damals und auch zu dem aktuellen Geolocation-Element. Eine letzte Frage hatte ich noch, und zwar, wo wir das ganze Thema gesprochen haben, kam mir irgendwie der Gedanke, dass wir ja eine ähnliche Problematik auch haben mit so Cookie-Konsents. Und die EU ja, glaube ich, auch daran oder darüber nachdenkt, dieses ganze Cookie-Consent-Desaster so ein bisschen zu beheben, indem sie die Aufgabe den Browsern ein bisschen mehr zuschiebt als zentrale Verwaltungsinstanz, in der man eben einmal konfiguriert, wie man es gern hätte und das dann möglicherweise überall anwendet oder eben auch von Fall zu Fall unterschiedlich.

1:13:56Ist das was, was in irgendeiner Form auch bei euch aufgepoppt ist? Ich kann mir vorstellen, dass es wahrscheinlich doch ein bisschen anderer komplex ist, auch wenn es sehr viele Ähnlichkeiten hat. Also, es ist ein super komplexes Thema natürlich. Ich glaube, der Hoffnungsträger heißt GPC, Global Privacy Control, weil es eben in verschiedenen Legislations, also in Kalifornien zum Beispiel, schon tatsächlich bindend ist. GPC ist ein Header-Bed, den man sendet. Ich glaube, SECGPC heißt das, Global Privacy Control.

1:14:32Und das ist ähnlich wie DumaTrack damals, aber halt ja, Legally Binding, wie das so schön heißt, zumindest in manchen. Rechtsprechungen und ja, natürlich ist das derzeit so, dass man das auf der Browser-Ebene einmal setzt und dann halt sagt in den Settings am Browser, ich will das eben haben oder ich will das nicht haben. Man kann sich natürlich vorstellen, dass man das dann irgendwann auflockert und sagt, man nimmt das vielleicht in die Site-Settings mit rein, wird das irgendwann vielleicht zu einer Permission werden, deren, Ein Cookie-Element oder was auch immer oder GPC-Element auf der Seite dargestellt wird und dann gebrandet wird entsprechend.

1:15:14Da kommen wir dann eben ganz, ganz schnell in das Thema. Ja, in manchen Ländern mag es dann zwingend sein, dass man das anzeigen muss. In anderen Ländern kann man es anzeigen, muss aber nicht. In anderen Ländern hat die Entscheidung dann keinerlei Bedeutung oder vielleicht nur, wenn man ausoptet, aber ein Opt-in ist dann eine No-Op oder was auch immer. Also ja, da kommt das dann eben sehr, sehr schnell ins, genau. Okay, nee, habe ich mich nur gefragt, weil es da doch recht viel Analogien gibt irgendwie zwischen diesen Dingen.

1:15:48Aber genau das eine ist halt auch was, was ihr in den Browsern dann weiterverarbeitet. Und hier ist ja auch dann noch der Unterschied, dass das was ist, was man ja dann an Startpartys irgendwie signalisieren muss. Aber über so einen Header ist das natürlich ein guter Weg auch. Unsere Privatsphäre ist uns sehr wichtig und unseren 791 Partnern auch. Ja, genau. Also Großes Thema. Ja, cool. Mega gut, dass du da warst. Ich fand es total interessant.

1:16:22Leider habe ich keinen Anwendungsfall für das Geolocation-Element, sonst würde ich es natürlich auch direkt irgendwie in meinen Projekten verbauen. Vielleicht bauen wir das einfach auf die Podcast-Seite ein. Das macht dann nichts, aber man kann es benutzen. Aber finde ich total sinnvoll und klingt nach einer guten Sache. Ich bin gespannt, ob sich das dann auch durchsetzt und möglicherweise dann auch den Weg in Peters genannte Framework-Plugins findet, dass die dann eben auch umsatteln auf das Element.

1:16:56Das ist ja so. Der dicke Öltanker des Bestehenden, der ist halt sehr schwer zu wenden. Und da muss man halt immer auch gucken, wie kriegt man die, um in der nautischen Metapher zu bleiben, an Bord mit sowas. Ja, und ich bin auch gespannt, ob KI diese Entwicklung dann auch mit einbezieht. Ah ja, genau, das wollte ich eigentlich fragen hier. Das ist das Einzige, wo ich mich vorbereitet habe. Ich habe mir heute Morgen beim Zähneputzen gedacht. Die Frage wollte ich noch loswerden, weil ich meine, so euer Laden müsste ja eigentlich einen Schlachtplan auch für dieses Problem haben, weil ihr habt ja Dekaden von Bestandscode, die es anders machen.

1:17:30Nicht nur die ganzen React-Entwickler, die ich jetzt von unter dem Bus geworfen habe, sondern halt eben auch die, die jetzt ja die React-Entwickler alle ersetzen. Mit welchem Brecheisen kriegt ihr denn das Ganze in die ganzen KIs rein, damit die in Zukunft das richtig machen und nicht das alte Zeug? Gibt es da einen Plan für? Also, da kann ich nur spekulieren, was ein Plan sein könnte und ich sage nicht, dass das so gemacht wird, aber System Prompt ist natürlich ein sehr, sehr großer Hebel und wenn du sagst in deinem System Prompt, wenn dich jemand fragt nach, mach eine Web App, die so und so macht oder die so und so kann und dein System Prompt hat dann halt verdrahtet bei Default in dem React, bei Default in dem Tailwind, dann könntest du dir vorstellen, also wie gesagt, das ist nichts, was ich sage, machen wir so, sondern könnte man sich vorstellen, als Vendor von sowohl dem LLM als auch Chrome, als auch was auch immer, könnte man dann natürlich sagen, okay, wenn das Geolocation-Thema vorkommt, dann guckt doch mal, dass die Geolocation-Element eine Möglichkeit wäre, das zu lösen.

1:18:31Spannend. Ja, es ist ja auch immer das Problem, dass die ja viel so auf Wahrscheinlichkeiten ihre Antworten aufbauen. Und wenn man dann als, das sind ja so Unknown-Unknowns, das heißt also, wenn ich nicht weiß, dass sich der KI irgendwie im Prompt irgendwas mitgeben sollte, dann sagt die halt, ja, was benutzen die meist? Ja, deswegen müsstest du es ja in den System-Prompt, also wirklich so auf der Produktebene gleichsam einziehen. Ist halt nur das Problem, das skaliert wahrscheinlich nicht, wenn nach dem Geolocation-Element dann demnächst noch was anderes um die Ecke kommt.

1:19:00Ja, das ist ja generell einfach die große Frage, wie, also können sich neue Dinge etablieren, wenn immer mehr solche Tools zurate gezogen werden. Aber das ist natürlich wieder ein komplett eigenes, neues Fass, das man da aufmacht. Das betrifft ja alles im Grunde. Ja gut, aber ich meine, wenn man irgendwie einer von denen ist, die in diese Richtung schieben, sollte man da ja vielleicht einen Plan für haben. Das Gute ist, auch die bösen Attacken, wenn die alle nur noch KI benutzen, um sich Cross-Set-Scripting-Hacks geben zu lassen, dann ist man ja dann auch geschützt.

1:19:32Wenn es da keine Weiterentwicklung mehr gibt, dann macht man nur noch diese Security-Holes zu. Na nee, Security-Holes zu machen ist jetzt ja auch nicht mehr. Hast du nicht gesehen, was mit Call passiert ist? Ja, die sind mittlerweile, die haben mittlerweile wirklich keinen Bock mehr. Die haben wirklich keinen Bock mehr. Die sind sehr deutlich geworden. Also normalerweise hätte ich gedacht, das sind irgendwie alles irgendwie wohlerzogene Herren, die sich da irgendwie gewählt ausdrücken.

1:19:55Aber wenn die jetzt wirklich sagen, komm mit dem Scheiß auf, oder ich stell dich öffentlich zur Schau, das schreiben die so. Nö, nö, ich dachte nur. Ja. Aber gut. Da können wir ja mal den Vortrag von der Frostcon, von dem Daniel Stenberg noch verlinken. Also LLMs und neue Webstandards, das wäre auf jeden Fall eine eigene Episode. Ich bin mir 100% sicher, da gibt es mehr als eine Person in dieser Firma, die sich darüber Gedanken macht, wie man das denn beibringen könnte.

1:20:26Also, meiner eigenen Erfahrung nach ist, ja, derzeit einfach das, was man im Web sieht, was auf Getab so publiziert wird, deutlich stärker als die Sister Prompts. Aber klar, letztendlich ist natürlich alles eine Schraube, die man drehen kann. Selbst wenn dich jemand nach Tailwind fragt, gib es ihm einfach nicht. Könnte man sich vorstellen. Ja, ist auch für Tailwind besser, haben wir gelernt. Aber man hat ja gelernt, bei Co-Pilot kann man einfach zweimal fragen, dann kriegt man es trotzdem.

1:20:56Ja. Wenn Mama Ja sagt, frage ich, äh, gar andersrum. Wenn Mama Nein sagt, frage ich Papa. So, so macht man das. Das, äh. Der erste Exploit, den man, auch wenn man hinterher nie wieder einen Computer anfasst, den lernt man. Ja, den lernt man auch sehr jung schon. Ja, super. Danke, dass du da warst. Hat mir super viel Spaß gemacht, war sehr interessant. Sehr erkenntnisverantwortlich. Genau. Vielen Dank für die Einladung. Ja, genau. Wenn es Feedback gibt an dich oder an uns, gerne.

1:21:27Ihr findet uns auf diversen und auch den Thomas auf verschiedenen sozialen Kanälen. Die werden dich auch entsprechend verlinken. Und genau, ihr seid auch immer eingeladen, in unserem Community-Slack zu diskutieren über eine Folge oder ein Thema. Macht das gerne. Und ansonsten würde ich sagen, hören wir uns nächste Woche wieder. Und da geht es vielleicht um ein Web-Component-basiertes in der UI-Library. Vom Bund benutzt wird beim Government Site Building Projekt vielleicht.

1:22:06Das werden wir dann rausfinden. Oder Streams und machen wir Streams. Streams? Ah ja, genau. Streams haben wir auch noch in Petro. Genau, wir wollten auch über Streams sprechen. Nicht wahr? Das Bundes-Schatz-IDN und seine Input Komponent. Das wäre auch toll. Oder, Peter? Also ich habe tatsächlich vor, demnächst mal wieder mit Kiki und Stefan einen React-Type-Script-Glücksrat zu machen. Das schlägt ja in die gleiche Kerbe. Da kann ja der Makiki sich als Repräsentant der React-Welt sich verantworten für das, was halt eben seine spezifische Zivilisation da heraufbesporen hat.

1:22:44Okay. Naja, es ist immer amüsant auf jeden Fall, wenn ihr euch trefft. Alles klar. Dann wünsche ich euch einen schönen restlichen Tag, schönes Wochenende und wir lesen und sehen uns. Tschüssi. Bis dann. Tschüss. Ciao, ciao.