Working Draft

In dieser Revision sprechen wir mit Leo Reuter von Vercel (LinkedIn / E-Mail) über den Wandel von Deployment- und Hosting-Plattformen hin zu AI-gestützten Entwicklungswerkzeugen. Unser Sponsor Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints. Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft Ausgangspunkt ist dabei unsere bisherige Beschäftigung mit Vibe Coding und der Frage, wie sich solche Werkzeuge in reale Entwicklungsprozesse einfügen, statt nur schnelle Demos und Prototypen zu erzeugen. Gemeinsam schauen wir uns an, wo v0 heute steht, wie sich das Tool von einem Generator für einzelne React-Komponenten zu einem System für komplette Anwendungen entwickelt hat und warum Themen wie bestehende Codebasen, Designsysteme, Branch-Workflows und Skills inzwischen wichtiger sind als das bloße Erzeugen von UI aus natürlicher Sprache. [00:02:48] v0 und Vercel Leo stellt zunächst seinen Weg vom Frontend-Engineering über langfristige Projektarbeit bis zu seiner Rolle als Solution Architect bei Vercel vor. Von dort aus steigen wir in die Geschichte von Next.js und Vercel ein: Ausgangspunkt war der Wunsch nach mehr Guardrails im React-Ökosystem, etwa für Routing und Framework-Konventionen, und später die Frage, wie sich solche Anwendungen ohne den üblichen DevOps-Aufwand produktionsreif deployen lassen. Wir sprechen darüber, wie Vercel genau diese Lücke gegenüber klassischen Hyperscalern geschlossen hat und warum schnelle Rollbacks, Preview-Deployments und einfache Infrastruktur bis heute ein wichtiges Argument sind. [00:09:12] Von Komponenten zu kompletten Anwendungen Danach geht es um die AI-Produkte rund um Vercel und vor allem um v0. Leo beschreibt, wie intern zunächst mit frühen GPT-Modellen experimentiert wurde, um einzelne Komponenten zu erzeugen, und wie daraus Schritt für Schritt ein Tool entstand, das heute komplette Full-Stack-Anwendungen aus natürlicher Sprache erzeugen kann. Wir diskutieren, was inzwischen alles möglich ist, von Rapid Prototyping über Datenbank- und Payment-Anbindungen bis hin zu realistischen Produktideen, und wo die Grenze zwischen schneller Visualisierung und belastbarer Software verläuft. [00:12:50] Vom Prototyp zur produktiven Anwendung Ein Schwerpunkt der Folge ist die Frage, was „production-ready“ in diesem Kontext überhaupt bedeutet. Leo erklärt, dass v0 lange vor allem für schnelles Prototyping genutzt wurde, der Übergang in produktive Systeme aber oft daran scheiterte, dass Designsysteme, Komponenten oder der eigentliche Tech-Stack nicht übereinstimmten. Genau deshalb spielt der Git-Import inzwischen eine so große Rolle: Bestehende Projekte lassen sich in v0 laden, dort bearbeiten und über Branches und Pull Requests wieder in den normalen Entwicklungsprozess zurückführen. Wir vergleichen diesen Browser-zentrierten Ansatz mit lokalen AI-Coding-Tools und arbeiten heraus, warum v0 gerade für weniger technische Rollen interessant ist, die nicht erst lokale Entwicklungsumgebungen, Environment-Variablen und Build-Prozesse aufsetzen wollen. [00:17:31] Architektur, Laufzeit und Tech-Stack-Fragen Im weiteren Verlauf sprechen wir über die technische Architektur hinter v0. Leo beschreibt den Wechsel von einer browserbasierten Laufzeit hin zu Micro-VMs mit vollständiger Entwicklungsumgebung in einer Sandbox, was mehr Stabilität und vor allem mehr Offenheit gegenüber verschiedenen Frameworks ermöglichen soll. Damit wird v0 nicht nur für bestimmte Standard-Setups, sondern perspektivisch auch für andere bestehende Projekte interessanter. In diesem Zusammenhang reden wir auch darüber, warum sich im AI-Umfeld ein Stack aus TypeScript, React, Next.js und Tailwind CSS so stark durchgesetzt hat: Einerseits, weil Modelle mit Utility-Klassen direkt im Markup besser zurechtkommen, andererseits, weil genau dieser Stack in den öffentlichen Trainingsdaten besonders stark vertreten ist. [00:25:52] Composite Models, Planning und Designsy steme Außerdem werfen wir einen Blick darauf, wie v0 intern arbeitet. Leo erklärt, dass hinter v0 kein eigenes Foundation Model steckt, sondern ein Composite-Ansatz, bei dem verschiedene Modellteile zusammenspielen, darunter auch ein eigener Auto-Fixer für Korrekturen. Wir sprechen über agentisches Arbeiten, über Planning Modes und darüber, warum es gerade bei größeren Brownfield-Projekten sinnvoll ist, Features erst gemeinsam mit dem Tool zu planen, bevor Code erzeugt wird. Von dort aus landen wir fast zwangsläufig bei Designsystemen: Heute lassen sich in v0 bereits Themes und Tokens hinterlegen, künftig soll aber vor allem die Wiederverwendung echter Unternehmens-Komponenten deutlich besser werden. Genau das ist für größere Organisationen spannend, die bestehende Component Libraries zusammenbringen müssen und vermeiden wollen, dass AI-generierter Code zwar ähnlich aussieht, aber nicht auf den tatsächlich verwendeten UI-Bausteinen basiert. [00:49:16] Skills, Demokratisierung und die Rolle von Entwicklerinnen und Entwicklern Zum Ende der Folge geht es um Skills als wiederverwendbares Wissen für Agenten. Leo erklärt, wie Markdown-basierte Skills zusätzlichen Kontext bereitstellen können, ohne dauerhaft das gesamte Kontextfenster zu belegen, und wie sich damit Best Practices oder domänenspezifisches Wissen in Tools einspeisen lassen. Von dort aus diskutieren wir die größere Frage, was solche Werkzeuge für den Beruf bedeuten. Unsere gemeinsame Stoßrichtung ist dabei klar: Nur weil mehr Menschen Software erzeugen können, verschwindet Softwareentwicklung nicht. Vielmehr verschieben sich Anforderungen und Werkzeuge, ähnlich wie früher bei Browser-Hacks, Test-Setups oder Designsystemen. Wer sich mit den neuen Möglichkeiten auseinandersetzt, hat eher Vorteile, während Verweigerung gegenüber diesen Veränderungen langfristig problematischer sein dürfte als der Einstieg von Junior-Entwicklerinnen und -Entwicklern in eine AI-geprägte Arbeitswelt.

Nach rund 20 Wochen Pause haben wir uns mal wieder zusammengesetzt und durch die aktuellen Browser-Releases gewühlt. Diesmal haben uns vor allem Firefox und Safari angeschaut, während Chrome eher im Hintergrund mitlief. Event-Tipp Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen! Dabei sind wir über eine ganze Reihe spannender Neuerungen gestolpert – von großen CSS-Features über neue APIs bis hin zu kleineren, aber wichtigen Verbesserungen im Detail. Wir gehen die Highlights durch und diskutieren, was davon wirklich relevant ist und wo noch Fragen offen bleiben. Schaunotizen [00:03:39] Anchor Positioning wird interoperabel Mit Anchor Positioning ist ein lange erwartetes CSS-Feature jetzt in allen Browsern angekommen. Es erlaubt, Elemente direkt relativ zu anderen Elementen zu positionieren – etwa für Popovers, Tooltips oder Dropdowns – ohne Wrapper-Hacks oder komplexes JavaScript. Der Browser übernimmt dabei auch das Umschalten von Positionen, wenn Inhalte am Viewport-Rand abgeschnitten würden. Besonders hilfreich ist der Artikel von Temani Afif, der typische Edge Cases beschreibt. Ergänzend verweisen wir auf einen Talk von Bramus van Damme, der sich ausführlich mit dem Feature beschäftigt. [00:30:27] CSS Module Scripts in Firefox Firefox unterstützt nun ebenfalls CSS Module Scripts, sodass Styles direkt über ECMAScript-Module importiert werden können. Das ermöglicht neue Patterns für komponentenbasiertes Arbeiten, etwa in Kombination mit adoptedStyleSheets. Gleichzeitig diskutieren wir die Auswirkungen auf Performance und Architektur, insbesondere bei hybriden Ansätzen wie „Islands of Reactivity“, wo klassische Stylesheets und modulbasierte Styles zusammenkommen. [00:47:09] Navigation API und URL Pattern API Die Navigation API ist jetzt auch in Firefox verfügbar und ersetzt die alte History API durch ein moderneres, eventbasiertes Modell. Navigationen können abgefangen, kontrolliert und mit eigenen Logiken versehen werden. Zusammen mit URL Pattern Matching entsteht so eine solide Grundlage für clientseitiges Routing ohne Frameworks. Die API ist Teil der Interop-Bemühungen, wie sie etwa im Interop 2026-Programm definiert sind. [00:51:49] Customizable Select und neue Form Controls Safari bringt Fortschritte bei anpassbaren Form-Controls. Das <select>-Element lässt sich künftig über appearance: base-select komplett stylen. Ziel ist es, native Controls flexibler zu machen, ohne sie vollständig neu implementieren zu müssen. Dabei stellt sich auch die Frage, wie sich solche Anpassungen auf mobile Plattformen auswirken, wo bisher systemeigene UI-Komponenten dominieren. [00:59:08] Iterator Helpers und neue JavaScript-APIs Firefox implementiert neue Iterator-Methoden wie Iterator.zip() und Iterator.zipKeyed(). Diese arbeiten auf der Ebene von Iterables und Iterators und erlauben das Kombinieren unterschiedlicher Datenstrukturen wie Arrays, Sets oder NodeLists. Dabei wird deutlich, dass viele dieser APIs lazy arbeiten und andere Rückgabetypen liefern als klassische Array-Methoden, was ein Umdenken beim Umgang mit Daten erfordert. [01:11:35] Streams, Transferables und Worker-Kommunikation Safari erweitert seine Unterstützung für Streams deutlich: ReadableStreams sind jetzt asynchron iterierbar (for await...of), können mit Readable.from() erzeugt werden und sind als transferable Objekte nutzbar. Dadurch lassen sich Datenströme direkt an Web Worker übergeben, ohne komplexe postMessage-Protokolle bauen zu müssen. [01:16:50] Popover, CloseWatcher und Dialog-Verhalten Firefox ergänzt die Popover API um sogenannte Hints, die automatisch auf Basis von Nutzerverhalten erscheinen können. Zusätzlich gibt es mit dem CloseWatcher eine API, die plattformabhängige „Schließen“-Gesten abstrahiert. Ergänzend dazu erlaubt das closeby-Attribut bei Dialogen ein einheitliches Light-Dismiss-Verhalten. [01:21:31] Neue CSS-Pseudo-Klassen und Units Es gibt eine Reihe weiterer CSS-Erweiterungen: Die :heading-Pseudo-Klasse selektiert alle Heading-Elemente, während :open geöffnete Elemente anspricht. Zusätzlich unterstützt Firefox jetzt Root-Varianten klassischer Längeneinheiten wie rcap, rch, rex und ric. [01:22:25] Weitere Verbesserungen und Fixes Firefox behebt einen langjährigen Quirk rund um about:blank-Load-Events in iframes. Safari unterstützt jetzt Scroll Anchoring und bringt mit Zstandard-Kompression sowie Verbesserungen bei Streams und Kompression zusätzliche Performance-Features. Außerdem ist die Sanitizer API nun auch in Firefox verfügbar, die wir bereits in Revision 695 besprochen haben. [01:30:27] WebGPU als moderner WebGL-Nachfolger Mit WebGPU ist eine moderne API für GPU-Berechnungen jetzt auch in Safari angekommen. Im Gegensatz zu WebGL ist sie besser erweiterbar, unterstützt Multithreading und erlaubt neben Grafik auch allgemeine Berechnungen auf der GPU, etwa für Simulationen oder KI-Anwendungen. Links CSS Carousel als Theme Switcher Experiment von Schepp, das moderne CSS-Features unorthodox kombiniert. The Web We Want Event rund um die Frage, wie wir das Web in Zukunft gestalten wollen. CSS Articles Sammlung von Artikeln von Temani Afif zu modernen CSS-Techniken.

Christoph Wolff, IT-Spezialist für Web-Anwendungen beim NABU, und Eleonora Heiden, Referentin für digitale Verbandskommunikation, erklären den Aufbau des NABU‑Netzes. Sie sprechen über das Webbaukasten‑Problem nach Jimdo, die Auswahl einer neuen CMS‑Lösung und Authentifizierung mit Keycloak. Themen sind Migration, Barrierefreiheit, Support für Ehrenamtliche und Hosting‑/Wartbarkeitsfragen.

In dieser Revision beantworten wir Fragen aus der Hörerschaft. Wir, Peter und Schepp, haben uns einige Themen aus einer längeren Liste herausgepickt und diskutieren darüber, warum bestimmte Web-Techniken sich in der Praxis manchmal schwerer durchsetzen als man erwarten würde. Event-Tipp Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen! Dabei sprechen wir unter anderem über Progressive Enhancement, den aktuellen Stand moderner Bildformate im Web sowie eine neue JavaScript-Funktion für explizites Ressourcen-Management. Wie üblich schweifen wir dabei gelegentlich ab, schauen uns Implementation-Details an und versuchen herauszufinden, was davon im Alltag von Webentwickler:innen wirklich relevant ist. Schaunotizen [00:10:26] Warum wird Progressive Enhancement so selten genutzt? Ausgangspunkt ist eine Frage von Tom: Wenn Progressive Enhancement theoretisch so sinnvoll ist, warum setzen viele Entwickler:innen neue Web-Features trotzdem erst ein, wenn sie in allen Browsern vollständig unterstützt werden? Wir diskutieren mögliche Gründe dafür. Ein Punkt ist sicherlich, dass viele Entwickler:innen neue Plattform-Features schlicht nicht wahrnehmen oder sie in ihrem Alltag keine große Rolle spielen. Wer hauptsächlich mit Frameworks arbeitet, wartet oft darauf, dass neue Features dort integriert werden, statt sie direkt zu nutzen.Ein anderer Faktor ist die Komplexität beim Testen: Progressive Enhancement bedeutet letztlich, mehrere mögliche Laufzeitumgebungen zu berücksichtigen. Man müsste also systematisch testen, wie sich eine Anwendung verhält, wenn einzelne Features fehlen – etwa in unterschiedlichen Browsern, auf verschiedenen Geräten oder unter speziellen Bedingungen wie deaktiviertem JavaScript. In der Praxis passiert das jedoch selten. Wir sprechen außerdem über mögliche Tools und Ideen, die solche Tests vereinfachen könnten. [00:26:35] Welche Bildformate sollte man heute im Web verwenden? Anschließend beschäftigen wir uns mit einer praktischen Performance-Frage: Welche Bildformate sind heute sinnvoll im Web? Klassische Formate wie JPEG oder PNG werden zunehmend von moderneren Alternativen abgelöst. Besonders relevant sind hier WebP und AVIF, die beide aus Videocodecs entstanden sind (VP- und AV1-Familie) und deutlich bessere Kompressionsraten bieten.Wir sprechen über Unterschiede bei Kompression, Decoding-Geschwindigkeit und praktischen Einsatzszenarien. Während AVIF häufig die bessere Kompression liefert, kann das Encoding deutlich rechenintensiver sein – insbesondere bei On-Demand-Bildgenerierung auf Servern. WebP ist in solchen Szenarien oft pragmatischer. Außerdem diskutieren wir progressive Bilddarstellung bei JPEG, Tricks für progressive Wahrnehmung sowie zukünftige Entwicklungen wie JPEG XL oder kommende Codecs wie AV2. [00:58:56] Explicit Resource Management und using in JavaScript Zum Abschluss schauen wir uns ein relativ neues Feature im JavaScript-Ökosystem an: explizites Ressourcen-Management über das using-Keyword. Dabei geht es darum, Objekte mit einer deterministischen Aufräumlogik zu versehen. Statt sich darauf zu verlassen, dass die Garbage Collection irgendwann Ressourcen freigibt, kann ein Objekt über Symbol.dispose oder Symbol.asyncDispose definieren, wie es aufgeräumt werden soll, sobald eine using-Variable ihren Scope verlässt.Das ist besonders interessant für Szenarien, in denen JavaScript-Objekte externe Ressourcen repräsentieren – etwa offene Dateien, Netzwerkverbindungen oder temporäre Dateien in Node.js. Wir sprechen außerdem über mögliche Edge Cases, darunter klassische „Use-after-free“-Probleme und darüber, wie man solche Situationen mit Proxies oder zusätzlicher Logik verhindern könnte. Links Progressive Enhancement Grundprinzip der Webentwicklung, bei dem Anwendungen auch ohne neue Features funktionieren und zusätzliche Fähigkeiten nur dort genutzt werden, wo sie verfügbar sind. HTML <picture>-Element Ermöglicht es, unterschiedliche Bildformate oder Auflösungen abhängig vom Browser oder Device auszuliefern. AVIF Modernes Bildformat basierend auf dem AV1-Videocodec, das besonders gute Kompressionsraten für Webbilder bietet. WebP Von Google entwickeltes Bildformat mit Unterstützung für Transparenz und Animation sowie deutlich besserer Kompression als JPEG. JPEG XL Modernes JPEG-Nachfolgeformat mit besserer Kompression, Multithreading-Support und Kompatibilität zu klassischen JPEG-Bildern. Explicit Resource Management Proposal JavaScript-Proposal, das das using-Keyword sowie Symbol.dispose und Symbol.asyncDispose für deterministisches Ressourcen-Management einführt. Squoosh Web-App zum Vergleichen und Konvertieren von Bildformaten direkt im Browser, inklusive verschiedener Encoder und Qualitätsvergleiche.

In dieser Revision sprechen wir mit Thomas Steiner von Google über einen lange offenen Schmerzpunkt im Web: Permission-Dialoge. Ausgangspunkt ist das neue <geolocation>-Element, das Chrome eingeführt hat und das Permissions kontextueller, deklarativer und weniger fehleranfällig machen soll. Event-Tipp Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €. Alle Infos gibt’s auf beyondtellerrand.com Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen! Dabei schauen wir zurück auf die Geschichte der Geolocation API, diskutieren Permission-Spam, Browser-Mitigations wie den „Blue Chip“ und werfen einen Blick auf PEPC (Page Embedded Permission Control) als ursprünglichen Ansatz. Außerdem geht es um UX, Security, Styling-Grenzen und die Frage, wie neue Webstandards sich in einer Welt voller Frameworks und KI-Generatoren durchsetzen können. Schaunotizen [00:01:42] Das <geolocation>-Element Permissions im Web waren lange implizit oder API-getrieben: Wer etwa navigator.geolocation.getCurrentPosition() aufruft, triggert einen Browser-Dialog. Alternativ gibt es explizite Anfragen wie Notification.requestPermission(). Beide Varianten haben über die Jahre zu Permission-Spam, „Permission Fatigue“ und UX-Problemen geführt. Ein früher Versuch zur Vereinheitlichung war navigator.permissions.request(), der jedoch nach Diskussionen im W3C Permissions Repository (Issue #83) wieder verworfen wurde. Stattdessen entstand bei der TPAC 2023 die Idee der Page Embedded Permission Control (PEPC): ein deklaratives <permission>-Element mit type-Attribut und optionalem type-ext für Details wie Präzision oder Constraints. Daraus wurde schließlich ein spezialisierter Ansatz: Statt eines generischen Elements gibt es nun dedizierte Elemente wie <geolocation>. Chrome hat dieses Element mittlerweile geshipped (siehe Blogpost, Feature-Status auf ChromeStatus). Es kapselt nicht nur die Permission-Abfrage, sondern liefert direkt Positionsdaten – deklarativ und mit Events statt Callback-basierter Legacy-API. UX-seitig bringt das neue Modell einige Änderungen: Der Dialog wird zentriert angezeigt, der Hintergrund kann abgedunkelt werden, und es gibt differenzierte Zustände („Allow on every visit“, „Allow this time“, „Continue not allowing“). Damit soll „Permission Regret“ reduziert werden – also das nachträgliche Bereuen einer Entscheidung. Es gibt außerdem Styling-Regeln: Bestimmte CSS-Eigenschaften sind eingeschränkt, um Clickjacking oder visuelle Täuschung zu verhindern. Pseudo-Klassen wie :granted oder :invalid sowie Events wie onvalidationstatuschange, onpromptaction und onpromptdismiss ermöglichen dennoch eine Integration ins UI. In der Standardisierungsdiskussion gab es unterschiedliche Positionen: WebKit und Mozilla äußerten zunächst Vorbehalte gegenüber dem generischen Permissions-Element. Mit dem fokussierten <geolocation>-Ansatz scheint sich die Lage zu entspannen; Mozilla signalisiert vorsichtige Zustimmung, während WebKit noch prüft. Weitere Stichworte unseres Gesprächs sind die „Line of Death“ (Abgrenzung zwischen Web-Content und Browser-UI), User Activation (siehe User Activation in Chrome) sowie Browser-Mitigations gegen Spam, etwa ML-gestützte Heuristiken und der nicht-modale „Blue Chip“ bei Notification-Prompts (siehe Origin Trial zum Permission-Element und Best Practices). Links The <geolocation> HTML element Vorstellung des neuen deklarativen Geolocation-Elements im Chrome-Entwicklerblog. WICG/PEPC Repository zur ursprünglichen Page Embedded Permission Control-Idee. PEPC Issue #59 Diskussionen zur Weiterentwicklung und Aufsplittung des Permission-Ansatzes. W3C Permissions Issue #83 Debatte zur Entfernung von navigator.permissions.request(). WebKit Standards Position (PEPC) WebKits Einschätzung zum ursprünglichen Permissions-Element. Mozilla Standards Position (PEPC) Mozillas Positionierung zur deklarativen Permission-Kontrolle. WebKit Kommentar zu Permission-Details Diskussion zu UX- und Sicherheitsaspekten rund um Permission-Dialoge. Mozilla Standards Position (Geolocation Element) Aktuelle Diskussion zur Unterstützung des neuen Geolocation-Elements. Permission Element Origin Trial Erfahrungen und Erkenntnisse aus dem Origin Trial des ursprünglichen Permission-Elements. Permissions Best Practices Empfehlungen zum verantwortungsvollen Umgang mit Permissions im Web.

In dieser Folge sprechen wir mit Daniel Fau (CEO der TYPO3 GmbH) über den aktuellen Stand des Government Site Builder (GSB). Event-Tipp Noch nichts vor am 28. Februar? 👀 Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨ 👉 https://2026.stateofthebrowser.com Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers Nachdem wir zuletzt vor allem über fehlende Ansprechpartner, 404-Links und Kommunikationshürden gestolpert sind, wollten wir genauer verstehen, wie GSB 11 technisch und organisatorisch aufgestellt ist. [00:01:09] GSB 11: Standardisiertes TYPO3-CMS für die öffentliche Verwaltung Der Government Site Builder (GSB) existiert seit 2003 und wurde ursprünglich vom Bundesverwaltungsamt (BVA) in Zusammenarbeit mit Materna entwickelt. Später übernahm die „Bundesstelle für Informationstechnik“ (BIT) Betrieb und Hosting, bevor diese Aufgaben 2016 im ITZBund gebündelt wurden. Mit GSB 11 erfolgt nun der strategische Wechsel auf TYPO3 als technische Basis. Frühere Versuche wie GSB 10 setzten zwar auf Open-Source-Komponenten, blieben aber ohne echte Community-Anbindung. GSB 11 wird dagegen explizit als standardisiertes CMS auf TYPO3-Basis entwickelt – mit Fokus auf Sicherheit, Barrierefreiheit, Wartbarkeit und Automatisierung. Daniel verweist in diesem Zusammenhang auch auf Marktdaten wie den CMS Census, der TYPO3 insbesondere im Public-Sector-Umfeld stark positioniert. Technisch liegt die Distribution auf OpenCoDE, der Open-Source-Plattform der öffentlichen Verwaltung. Das Projekt ist über die zugehörige GitLab-Instanz einsehbar; dort finden sich Distribution, Extensions sowie – seit 2025 – auch ein öffentlich verfügbares Default-Frontend. Releases erfolgen in regelmäßigen Zyklen, während die Roadmap transparent im Projekt hinterlegt ist. Organisatorisch wurde GSB 11 in drei Losen ausgeschrieben: Produktentwicklung (Los 1), Betrieb (Los 2) und Migration/Relaunch (Los 3). Die Vergabe erfolgte im Rahmen des deutschen bzw. europäischen Ausschreibungsrechts (Kontext: TED – Tenders Electronic Daily, eVergabe). Das Gesamtvolumen liegt im dreistelligen Millionenbereich über mehrere Jahre – ein erheblicher Open-Source-Invest. Für Bundesbehörden stehen sogenannte Mandantenentwicklungsoptionen (MEO) zur Verfügung: MEO 1 bedeutet weitgehend standardisierte Nutzung inklusive Hosting, Wartung und Sicherheitsprüfung (u. a. mit Bezug auf Prüfmechanismen im Umfeld des BSI), MEO 2 erlaubt weitergehende Anpassungen, bringt aber mehr Eigenverantwortung mit sich. Darüber hinaus bleibt das DIY-Modell möglich: Distribution herunterladen, selbst betreiben – Open Source eben. Zielsetzung ist ein „One-for-All“-Ansatz im Sinne übergreifender Standardisierung (Kontext: IT-Planungsrat) statt individueller Neuentwicklung. Gleichzeitig diskutieren wir die Kommunikationsrealität rund um GSB 11: lange Vergabeprozesse, NDA-Sensibilität, vorsichtige öffentliche Aussagen – und die Frage, wie offen sich Open Source im öffentlichen Sektor anfühlen kann und sollte.

Zum Jubiläum werfen wir einen Blick zurück – ziemlich genau zehn Jahre. Inspiriert von einem Vorschlag aus unserem Community-Slack hören wir noch einmal in unsere Prognosen-Folge von Ende 2015 hinein und prüfen: Was ist aus unseren damaligen Thesen zu HTTP/2, Flexbox, Angular 2, React, Web Components und WebAssembly geworden? Event-Tipp Noch nichts vor am 28. Februar? 👀 Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨ 👉 https://2026.stateofthebrowser.com Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers Zwischen Nostalgie, realistischen Einschätzungen und ein paar veritablen Fehleinschätzungen sprechen wir darüber, wie sich Frontend-Engineering tatsächlich verändert hat – und wo wir heute stehen: weniger Browser-Drama, mehr Tooling, mehr Framework-Vielfalt und ein völlig neues Spannungsfeld durch AI-gestützte Entwicklung. Schaunotizen [00:01:16] Das Web 10 Jahre später: Evolution statt Revolution Wir stellen fest: Viele Entwicklungen sind nicht spektakulär explodiert, sondern langsam gereift. HTTPS ist heute selbstverständlich – befeuert durch Let’s Encrypt und die Einführung von HTTP/2 (inklusive des mittlerweile gescheiterten Server Push) sowie später HTTP/3. Im CSS-Bereich hat sich Grid etabliert, ohne Flexbox zu verdrängen. Beide koexistieren – oft pragmatisch statt dogmatisch eingesetzt. Bei JavaScript hat ES2015 vieles verändert, aber weniger fundamental als gedacht. Wirklich einschneidend war async/await; vieles andere war „syntaktischer Zucker“. Parallel hat sich TypeScript stark verbreitet – ohne JavaScript zu ersetzen. Im Framework-Bereich ist keine Monokultur entstanden: React, Angular, Vue und andere bedienen unterschiedliche Ökosysteme. Statt Konsolidierung sehen wir Fragmentierung. Und dann gibt es die AI-Tools, die bevorzugt mit React/TypeScript arbeiten. Web Components und WebAssembly? Kein Mainstream-Overtake, aber solide Nischen-Erfolge. Sie tun genau das, wofür sie gedacht waren – nicht mehr, nicht weniger. Und schließlich: Browser-Testing ist entspannter geworden. Der Internet Explorer ist Geschichte, Edge-Cases existieren weiterhin (hallo iOS Safari), aber das Drama-Level ist deutlich gesunken. Headless-Browser und CI-Tests haben neue Testrealitäten geschaffen. Links Let’s Encrypt Kostenlose TLS-Zertifikate, die HTTPS massentauglich gemacht haben. Kevin Powell – Flexbox vs. Grid Das Video erklärt anschaulich, wann man in CSS besser zu Flexbox oder Grid greift, und zeigt, dass beide Layout-Methoden unterschiedliche Stärken haben und sich in der Praxis ideal ergänzen, statt miteinander zu konkurrieren. Next.js React-Framework, das als Default-Stack vieler AI-Tools gilt. Vercel Hosting-Plattform, eng mit Next.js verzahnt. Playwright Browser-Automatisierung und Testing-Framework für Headless-Tests. BrowserStack Cloud-Dienst zum Testen in echten Browser-/Device-Kombinationen. Google Trends Grundlage unserer Diskussion zu Suchvolumen von JavaScript, TypeScript, Python & Co. Dead Framework Theory In disem Blogpost beschreibt Paul Kinlan eindrücklich, wie sich durch LLMs und ihre Trainingsdaten eine selbstverstärkende Dynamik zugunsten etablierter Frameworks wie React entwickelt, die es neuen Ansätzen zunehmend schwer macht, überhaupt noch Fuß zu fassen. Web Components (MDN) Überblick über Custom Elements, Shadow DOM & Co. WebAssembly Low-Level-Binaryformat für performante Web-Anwendungen. CSS Houdini Initiative zur Erweiterung von CSS mit Low-Level-APIs. Digital Markets Act EU-Regulierung mit potenziellen Auswirkungen auf Browser-Monopole. European Accessibility Act Europäische Richtlinie zur Barrierefreiheit digitaler Produkte und Dienste.

In dieser Folge setzen wir dort an, wo wir mit der vorherigen ARIA-Glücksrad-Folge aufgehört haben. Denn wir haben nach der Veröffentlichung tolles Feedback bekommen und holen uns deren Absender als Verstärkung rein: Mit Accessibility Engineer Daniela Kubesch (LinkedIn / Bluesky / Mastodon), Frontend/Design-Systems Engineer Marco Bretschneider (Mastodon), Web-Technologie-Consultant und W3C Invited Expert Peter Krautzberger (LinkedIn / Mastodon) und Accessibility Experience Experten Paweł Masarczyk (Mastodon) sprechen wir darüber, was von ARIA-Attributen in der Praxis wirklich ankommt – bei Browsern, im Accessibility Tree und letztlich bei Screenreadern. Unser Sponsor Alle reden von Automation – aber wo betreibst du eigentlich deine Tools? Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints. Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft Wir gehen systematisch die Attribute aus der letzten Glücksrad-Runde durch, ordnen sie technisch ein und ergänzen sie um Perspektiven aus Spezifikation, Implementierung und tatsächlicher Nutzung. Dabei wird klar: Zwischen Spec-Idee, API-Mapping und realer Unterstützung liegen oft Welten. Shownotes [00:05:08] aria-placeholder Wir klären, dass aria-placeholder tatsächlich das ARIA-Pendant zum HTML-placeholder ist – gedacht für selbstgebaute Input-ähnliche Controls. Alle sind sich einig: In freier Wildbahn sieht man es kaum, was vermutlich auch ein gutes Zeichen ist. Spannend ist vor allem, wie Placeholder von Screenreadern angesagt werden und wie sie sich von aria-describedby unterscheiden lassen. [00:11:25] aria-details & ariaDetailsElements (DOM) Peter nutzt die Gelegenheit für einen Deep Dive: aria-details ist kein „längeres Describe-By“, sondern ein eigenes Pattern, entstanden aus echten Use-Cases (z. B. Google Docs mit Kommentaren). Wir sprechen über die neuen Element-APIs, die ohne ID-Listen auskommen, über Popover-Verknüpfungen und darüber, wie vage Specs bewusst Spielraum für Assistive Technologien lassen. [00:21:13] (Core) Accessibility API Mappings (AAM) Ein Abstecher unter die Haube: AAM-Spezifikationen beschreiben, wie DOM und ARIA auf die Accessibility-APIs der Betriebssysteme gemappt werden. Eigentlich für Browser-Hersteller gedacht – aber extrem hilfreich, um zu verstehen, wo Informationen verloren gehen oder ergänzt werden. [00:33:35] aria-posinset & aria-setsize Die Klassiker für große, virtuelle Datenmengen. Wir diskutieren, warum diese Attribute auf Einzelelementen sitzen müssen, wie gut sie tatsächlich unterstützt sind und ob User Agents nicht mehr selbst berechnen sollten. Fazit: theoretisch sinnvoll, praktisch noch eine Baustelle. [00:47:17] aria-errormessage Ein gutes Beispiel für das Dilemma „gute Idee, holprige Unterstützung“. Während NVDA und TalkBack Fortschritte machen, bleibt die Abdeckung lückenhaft. Trotzdem sehen wir den Mehrwert gegenüber reinem aria-describedby – gerade, wenn Fehlermeldungen klar als solche kommuniziert werden sollen. [00:50:31] CSS Speech & Audio-Design Wir diskutieren die Idee, Audio-Ausgabe per CSS zu beeinflussen: von Tonhöhe über Geschwindigkeit bis hin zu Sound-Design. Zwischen Branding-Potenzial und Kontrollverlust für Nutzer:innen entsteht eine Grundsatzfrage, die stark an Debatten rund um Alternativtexte erinnert. [01:05:11] Braille-Properties Sehr spezielle Werkzeuge für sehr spezielle Fälle. Peter erklärt, warum Braille-Attribute existieren, wofür sie gedacht sind (z. B. Bildung, Musik- oder Chemienotation) – und warum man sie in 99,9 % der Fälle besser nicht anfasst. [01:15:15] aria-colcount, aria-colindex & Tabellen Wir landen wieder bei großen Tabellen, Grids und Tree-Grids: Wann machen zusätzliche ARIA-Infos Sinn, wann sind sie redundant? Besonders spannend sind menschenlesbare Index-Texte (z. B. Schachfelder wie „A4“) jenseits reiner Zahlen. [01:23:01] aria-multiselectable Ein eher leises Signal mit großer Wirkung: Es teilt Assistive Technologien mit, dass eine interaktive Liste Mehrfachauswahl erlaubt. Wir ordnen es ein zwischen nativen Desktop-Patterns, Web-Mail-UIs und den WAI-ARIA Authoring Practices. Links A-Tag Wien 2026 Accessibility-Konferenz in Wien, Anmeldung ab 1. Februar. ARIA Actions Vorschlag für ein neues Pattern, um sekundäre Aktionen besser zugänglich zu machen. Core Accessibility API Mapping Spezifikation zum Mapping von ARIA auf Betriebssystem-APIs. ARIA-Issues zu Placeholder, Details & Co. Diskussionen rund um mehrere der besprochenen Attribute. HTML-Support in Screenreadern Überblick zu tatsächlicher Unterstützung von HTML-Features. Deprecation-Diskussion zu aria-errormessage Einblick in die Debatte innerhalb der ARIA Working Group. Léonie Watson: CSS Speech Vortrag zur Motivation und Einordnung von CSS Speech. JAWS Sound Schemes Beispiel für nutzerseitig konfigurierbares Audio-Feedback. Pronunciation Task Force „Gegenseite“ im Diskurs um Aussprache und Audio-Kontrolle. Leonie Watson: Addressing concerns about CSS Speech Einordnung der Kritikpunkte und Gegenargumente. Vasilis van Gemert: Exclusive Design Talk mit spannenden Audio- und Nicht-visuellen Design-Experimenten. WAI-ARIA Authoring Practices: Listbox Referenzmuster für interaktive (auch multiselect-fähige) Listen.

In dieser Folge sprechen wir zu zweit über unsere Eindrücke rund um den Government Site Builder (GSB) – ausgelöst durch unseren Besuch auf der T3CON in Düsseldorf. Eigentlich wollten wir vor Ort ein Interview zum Projekt führen. Herausgekommen ist stattdessen eine kurze, leicht rantige Bestandsaufnahme darüber, wie schwer es ist, überhaupt belastbare Informationen oder Gesprächspartner:innen zum GSB zu finden. Wir sprechen darüber, warum uns das Thema trotz (oder gerade wegen) politischer Rahmenbedingungen interessiert, welche Rolle das Informationstechnikzentrum Bund (ITZ-Bund) spielt, wie Agenturen in sogenannten „Losen“ organisiert sind – und warum ein Projekt, das sich selbst als 100 % Open Source bezeichnet, von außen oft erstaunlich verschlossen wirkt. [00:01:06] Government Site Builder (GSB 11) Der Government Site Builder ist ein von der Bundesverwaltung initiiertes Projekt, das eine standardisierte technische Basis für Webseiten von Bundesbehörden bereitstellt. Die aktuelle Version GSB 11 basiert auf TYPO3 und wird vom ITZ-Bund verantwortet. Ziel ist es, Digitalisierung voranzubringen, Abhängigkeiten von proprietären Systemen zu reduzieren und eine einheitliche, barrierearme Plattform für Behördenwebsites zu schaffen.In der Umsetzung arbeitet das Projekt mit mehreren Vergabelosen: Während das ITZ-Bund den grundlegenden Tech-Stack verantwortet (Los 1), werden Migrationen und Implementierungen von Agenturen übernommen (Los 3). Als Generalunternehmer fungiert dabei eine große Agentur, unter deren Dach zahlreiche weitere Agenturen eingebunden sind. Trotz des Open-Source-Anspruchs stößt man aktuell auf Hürden: Verlinkte Code-Repositorien sind schienen teilweise nicht öffentlich zugänglich, Aussagen zum Projekt müssen offenbar umfangreich abgestimmt werden, und selbst auf Konferenzen fällt es schwer, auskunftsfähige Ansprechpartner:innen zu finden. Das steht in einem spürbaren Kontrast zu früheren Vorbildern wie gov.uk, wo technische Erkenntnisse, Accessibility-Learnings und Architekturentscheidungen offen in die Community zurückgespielt wurden. Genau diese Offenheit vermissen wir aktuell beim GSB – obwohl das Projekt aus öffentlichen Mitteln finanziert wird und explizit Transparenz betont. Update: Nach Hinweisen von Hörenden liegt das Projekt auf Open Code hier und der Sourcecode selbst hier Vielen Dank dafür!. Links bundespolizei.de Beispiel einer Website, die bereits auf Basis von GSB 11 umgesetzt wurde. karriere.bund.de Weitere öffentlich genannte Referenz für einen produktiven Einsatz des Government Site Builders. CoreMedia Kommerzielles, Java-basiertes CMS, auf dem frühere GSB-Versionen (z. B. Version 7) noch weit verbreitet laufen. KoliBri Web-Components-basierte Frontend-Library, die im Kontext des GSB als mögliche UI-Basis erwähnt wird. David Heinemeier Hansson Erwähnt im Kontext der Diskussion, was „Open Source“ eigentlich bedeutet, wenn Code zwar einsehbar, aber kaum offen für externe Beiträge ist.

In dieser Folge sprechen wir mit Frederik Braun (Mastodon) aus dem Firefox-Security-Team bei Mozilla über den langen Weg der Sanitizer API: Von ersten Prototypen vor über fünf Jahren bis zum geplanten Shipping in Firefox und Chrome im Februar 2026. Schaunotizen [00:01:08] Die Sanitizer API Einleitend klären wir, warum Cross-Site-Scripting (XSS) auch 2026 noch eines der größten Web-Security-Probleme ist, weshalb bestehende Lösungen wie DOMPurify, Content Security Policy oder Trusted Types zwar helfen, aber kaum breit eingesetzt werden – und dass die Sanitizer API einen neuen, deutlich praxisnäheren Ansatz verfolgt.Die Sanitizer API ist ein neuer Web-Standard, mit dem sich unsicheres HTML direkt beim Einfügen in den DOM bereinigen lässt – ohne String-Roundtrips und ohne zusätzliche Bibliotheken. Statt Element.innerHTML = html wird künftig Element.setHTML(html) verwendet. Der Browser übernimmt Parsing, Bereinigung und Einfügen in einem Schritt und verhindert zuverlässig Cross-Site-Scripting, DOM-Clobbering und viele Varianten von Mutated-XSS. Links Revision 447: XSS und die HTML Sanitizer API Die eingangs erwähnte, mittlerweile fünfeinhalb Jahre alte Folge mit Frederik, in der XSS und die ursprüngliche Idee der Sanitizer API bereits ausführlich besprochen wurden. Revision 452: CORS, CORP, (C)ORB, COOP und COEP Eine weitere Folge mit Security-Fokus, nämlich zu diversen sicherheitsrelevanten HTTP-Headern, ebenfalls mit Frederik. Revision 514: ASTs, Linter und Security mit Frederik Braun In dieser Revision reden sprechen wir mit Frederik über Abstract Syntax Trees, Lexer und Parser. Und natürlich Security! DOM Clobbering Angriffstechnik, bei der HTML-IDs oder Names bestehende JavaScript-Objekte überschreiben und so Logikfehler oder Sicherheitslücken auslösen. Höre dazu auch Revision 202: Sicherheitslücken – DOM Clobbering, XSS via CSS, ES6 Fallen. Interop-Projekt Browser-übergreifende Initiative zur Angleichung von Web-Plattform-Features, potenziell relevant für Trusted Types in zukünftigen Iterationen.