Working Draft

In dieser Revision drehen wir nochmal das Glücksrad – allerdings zum Themenbereich TypeScript und React. Gemeinsam mit unserem Gast Kiki (Hans-Christian Otto), seines Zeichens Paramount Leader von Suora, picken wir zufällige React- und TypeScript-Themen und arbeiten uns von dort aus tief in Parallelwelten, Typsysteme, Debugging-Philosophie und die Grenzen statischer Analyse vor. Es geht um React DevTools, Web Components, any vs. unknown, TypeScript-Overloads, Decorators und die Frage, warum HTML kaputt sein darf – und vermutlich immer bleiben wird.

[00:03:37] React useDebugValue

useDebugValue ist ein React-Hook, mit dem sich Zusatzinformationen in den React DevTools anzeigen lassen. Im Kern eine Art strukturierter Debug-Output, der besonders hilft, wenn dieselbe Komponente mehrfach im Tree auftaucht.

[00:27:28] Debugging in React & DevTools

Wir vergleichen klassisches Browser-Debugging mit React-Debugging und diskutieren, warum React eigene DevTools braucht: synthetische Events, virtueller DOM und eine parallele Realität zur Web-Plattform.

[00:39:00] Web Components & Custom Elements

Exkurs in die Welt der Web Components: Warum Debugging dort oft einfacher ist, weil es keine virtuelle Abstraktion gibt – und was passiert, wenn ein Custom Element nie registriert wird. Spoiler: Der Browser bleibt erstaunlich gelassen.

[00:00:00] Kaputtes HTML & Browser-Parsing

Wir diskutieren, warum Browser kaputtes HTML akzeptieren müssen, weshalb XHTML sich nie durchgesetzt hat und warum ein strikt validierender Browser automatisch ein schlechter Browser wäre.

[00:00:00] React isValidElement()

Ein eher unbekanntes React-API zur Laufzeitprüfung von React-Elementen. Wir schauen unter die Haube, stolpern über interne Marker wie $$typeof und landen bei Cross-Realm-Problemen.

[00:46:26] TypeScript any vs. unknown

Ein zentrales Thema der Folge: any als kompletter Opt-out aus dem Typsystem versus unknown als sichere Grenze. Wir erklären Typ-Hierarchien und warum unknown fast immer die bessere Wahl ist.

[00:00:00] TypeScript: unknown als Sicherheitsgrenze

Wir sprechen über reale Einsatzszenarien, etwa bei fetch(), und warum ein sauberer Typ-Reset oft sinnvoller ist als das blinde Akzeptieren von any.

[00:48:56] TS-Reset & Fetch-Typen

Ein Community-Projekt, das TypeScript-Defaults bewusst verschärft. Wir diskutieren Chancen, Risiken und warum solche Tools sowohl helfen als auch schaden können.

[00:00:00] TypeScript Function Overloads

Ein Pattern für robuste APIs: nach außen präzise Typen für gute Autocompletion, nach innen unknown für saubere Validierung. Besonders relevant für Library-Autor:innen.

[01:23:42] TypeScript Decorators

Wir sprechen über Legacy-Decorators, Standard-Decorators und warum "experimentalDecorators" oft mehr Probleme schafft als löst.

[01:33:17] Symbol.hasInstance & instanceof

Ein tiefer Abstecher in Runtime-Typprüfungen, mehrfach gebundelte Klassen und warum instanceof in größeren Codebases schnell trügerisch wird.

Standard Podcast [ 1:43:36 ] Jetzt abspielen | Play in Popup | Download

Wir drehen wieder am „Glücksrad“ – diesmal strikt mit HTML-Vokabular. Schepp hat sich Jens Oliver Meiert eingeladen (Frontend Dogma, Web Glossary, Revision 687). MDN-Daten liefern die Zufalls-Themen; wir sezieren Einsatzfälle, Historie, Stolpersteine und moderne Patterns – von id über contenteditable bis hin zu <option>, <datalist> und dem noch jungen Global-Attribut writingsuggestions. Außerdem streifen wir HTML-Geschichte (HTML 2, XHTML 2), IE-Altlasten (designMode, Drag and Drop), XSLT-Rückbau, AJAX-Begriffsgeschichte und aktuelle Bildformate.

Schaunotizen

[00:03:27] id (MDN) & Spec: The id attribute

Historischer Abriss von name-Sprungmarken zu id; warum id als CSS-Selektor teils verpönt wurde (Spezifität), und wann er weiterhin sinnvoll ist (einzigartige Ziele, Relation über for/aria-*). Praktische Kniffe: Attribute-Selektoren, Spezifitäts-Dämpfung via :where(); bei Komponenten Duplikate durch generierte Suffixe/UUIDs vermeiden.

[00:15:39] contenteditable, designMode & Rich-Text

Use-Cases von Inline-Eingaben bis Comboboxen. Placeholder-Pattern: [contenteditable]:empty::before für Pseudo-Placeholder. contenteditable="plaintext-only" verhindert Stil-Paste. Historische Wurzeln: IE-designMode, vieles später standardisiert. Schepps Blog-Nugget zur IE-Ära: Today the Trident Era ends. Und die Liste an historischen CSS Fehlern.

[00:24:36] <b> und <i> (sowie <strong>/<em>)

Warum <b> (Aufmerksamkeitsmarkierung) und <i> (idiomatische/andere Stimme) legitime Semantik haben und nicht bloß „Präsentation“ sind. Wir sprechen über historischen Kontext aus frühen HTML-Spezifikationen; Blick in die alten Spec-Dokumente: W3C HTML Spec (Archiv).

[00:35:53] <option>, <optgroup> & <datalist>

Arbeitspferd im Formular: Gruppenbildung via <optgroup>, deaktivierbare Optionen, label-Attribut (ersetzt sichtbaren Inhalt). <datalist> als unterschätztes Type-Ahead für viele <input>-Typen (Range, Date etc.) – aber Achtung bei tausenden Einträgen (Performance, Match-Heuristiken variieren je nach Browser). Inspiration: „Retropolis“ bei unseren Freunden von Wo wir sind ist vorne.

[00:43:40] writingsuggestions

Noch jung und teils experimentell: steuert Schreibvorschläge („ghost text“) in editierbaren Feldern. Support-Lage: Chromium/WebKit ja, Firefox noch nicht – sinnvoll dort, wo Inline-Completion UX-Gewinn bringt.

[00:47:48] XSLT-Rückbau in Browsern

Ökosystem-Abhängigkeiten, Wartbarkeit und Security als Gründe; nostalgischer Blick auf XSLT-basierte Transformations-Pipelines („Sliding Doors“, frühe „Transpile“-Ansätze), warum der Rückbau für die meisten Web-Apps heute verkraftbar ist. Mehr dazu in dieser Folge der Igalia Chats

[00:52:13] AJAX, XML HttpRequest & Naming

Der Begriff „AJAX“ (populär geworden durch Jesse James Garrett 2005) als Zündfunke für „app-iges“ Web – plus Seitenblick auf noch frühere Publikationen. Für Geschichtsnerds: Internet History Podcast.

[00:55:37] Bildformate heute: JPEG XL, WebP, AVIF

Trade-offs zwischen Decoder-Sicherheit, Multithreading-Decoding, Migrationspfaden (aus JPEG ableitbar) und Browser-Adoption; warum selbst „alte“ Formate wie PNG noch Updates/Use-Cases haben (APNG, Transparenz). Jake Archibald hat zum Thema „progressive Image Rendering“ ein tolles Blogpost verfasst, in dem auch JPEG XL vorkommt.

Standard Podcast [ 1:02:54 ] Jetzt abspielen | Play in Popup | Download

In dieser Revision sprechen wir mit unserem Gast Manuel Matuzović über moderne HTML-Praktiken, alte Muster, die sich hartnäckig halten, und darüber, warum manche Links eigentlich Buttons sein sollten. Dabei tauchen wir tief in Semantik, Barrierefreiheit und die Frage ein, warum bestimmte Patterns – trotz aller Probleme – immer wieder im Web auftauchen.

Schaunotizen

[00:01:45] javascript:void(0)

Aufhänger dieser Revision ist ein Muster, das uns seit Jahren immer wieder begegnet: Die verbreitete Nutzung von href="javascript:void(0)" und verwandten Dingen in Links. Wir beklagen, dass dieses Pattern nicht nur technisch fragwürdig ist, sondern auch aus Sicht von Barrierefreiheit, Nutzererwartungen und allgemeiner HTML-Semantik massive Probleme nach sich zieht.

Dafür arbeiten wir uns zunächst Schritt für Schritt daran entlang, was einen echten, barrierefreien Link überhaupt ausmacht. Dazu gehören ein <a>-Element, ein gültiges href-Attribut und ein klarer Accessible Name. Erst dadurch entstehen Fokussierbarkeit, Tastaturaktivierung, sinnvolle Screenreader-Ausgaben, das korrekte Verhalten in Linklisten, die bekannten Linkzustände und das erwartete Interaktionsmodell. Alles, was davon abweicht, bricht die Erwartungen der Nutzenden – besonders sichtbar wird das bei Links, die eigentlich Buttons darstellen sollen.

javascript:void(0) sehen wir zudem als ein typisches Beispiel für Cargo-Kult: Ein historisches Muster, das weiterlebt, obwohl kaum jemand noch weiß, wozu es ursprünglich gedacht war. Technisch betrachtet evaluiert eine solche URL einfach JavaScript – im Fall von void wird allerdings bewusst undefined zurückgegeben, also „nichts“.

Wir benennen die vielen praktischen Probleme, die solcher Code hervorruft: Kontextmenüs bieten unsinnige Optionen an, Mittelklicks öffnen leere Tabs, Screenreader kündigen Elemente als Links an, die sich gar nicht wie Links verhalten, Tastaturnutzende stoßen auf widersprüchliche Aktivierungsmuster und in Listen assistiver Technologien erscheint „Navigierbares“, das kein Ziel hat. Wir diskutieren, wie solche Muster häufig entstehen – sei es aus historisch schwer zu stylenden Buttons, aus Einschränkungen in Component-Libraries, aus unglücklichen Framework-Abstraktionen oder schlicht aus fehlendem Basiswissen über HTML.

Aus dieser Perspektive wird klar: In den allermeisten Fällen wäre ein echtes <button>-Element die richtige Wahl. Moderne Browser machen das Styling per all: unset; und wenigen Ergänzungen längst unkompliziert. Wir sprechen darüber, wie hybride Komponenten sinnvoll funktionieren können, warum überflüssige Rollen, Tabindex-Werte oder ARIA-Attribute eher schaden als helfen, und wie man mit einfachen Debug-Strategien – etwa Selektoren wie a[href^="javascript:"] oder Werkzeugen wie a11y.css – problematische Stellen sichtbar machen kann.

Im weiteren Verlauf streifen wir verwandte Themen, etwa die alte Debatte um Cursor-Darstellungen bei Buttons, Überlegungen rund um target="_blank" und seine UX-Probleme (Warum target=“_blank“ nervt), sowie die Frage, welche Rollen historische Mechanismen wie <area>-Elemente heute noch spielen können (MDN). Wir stellen fest, dass viele Entwickler*innen HTML fast nur noch durch die Framework-Brille wahrnehmen– und dass genau diese Abstraktionsschichten es erschweren, zu verstehen, was die Basiselemente der Plattform eigentlich können.

Eine zentrale Erkenntnis des Gesprächs lautet: Gute HTML-Entscheidungen entstehen nicht dadurch, dass man Muster auswendig lernt, sondern indem man versteht, welche Fähigkeiten jedes Element mitbringt und wie es sich im Browser verhält. Wer entscheidet, „was bringt mir dieses Element?“, trifft fast automatisch die richtigen semantischen und barrierefreien Entscheidungen.

Links

Der HTM Hell Adventskalender

veröffentlicht jedes Jahr vom 1. bis 24. Dezember (und manchmal auch länger) täglich einen neuen Artikel rund um HTML, Barrierefreiheit, Semantik, Best Practices und typische Stolperfallen der Webentwicklung.

Standard Podcast [ 1:04:14 ] Jetzt abspielen | Play in Popup | Download

In dieser Revision sprechen wir mit Dr. Torsten Beyer, Chemiker und Experte für digitale Nachhaltigkeit, über seinen Weg vom Labor zum grünen Web, die oft übersehenen Umweltkosten des Internets und darüber, wie wir als Webentwickler:innen konkret zur CO₂-Reduktion beitragen können.

Wen das Thema weiter interessiert, sollte sich auch die Revision 675: Green Web geben.

Schaunotizen

[00:01:55] Vom Chemiker zum Experten für digitale Nachhaltigkeit

Torsten kam als Chemiker zur digitalen Nachhaltigkeit. Geboren 1968 bei 323 ppm CO₂ – circa als das Internet beim Militär erfunden wurde – beobachtet er seitdem beide Kurven steigen.

Wir sprechen darüber, wie Flatrates und „unbegrenzter“ Traffic seit 1969 ein falsches Bewusstsein für Daten schufen. Dazu das Jevons-Paradoxon: Speicher wurde drastisch günstiger (vom Commodore 64 zur Mini-SD), aber statt zu sparen, führt das zu Mehrnutzung, die die Einsparungen auffrisst.

[00:29:42] Bewusstsein schaffen durch Analyse

Torsten gibt einen Überblick über Methoden zur Analyse des CO₂ Fußabdrucks von Websites:

• The Green Web Foundation – Verzeichnis grüner Hoster, freiwillig. Wenn kein Eintrag: Hoster kontaktieren!
• Website Carbon – nicht empfehlenswert, fragwürdige Methodik.
• Digital Beacon – besser, aber Tests nur bis Cookie-Banner. Guter Einstieg.
• Log-Analyse – beste Methode für echten Traffic-Impact.

Unterschätzt: Laut Imperva Bot Report sind 51% des Traffics Bots – steigend durch KI. SEO Soon zeigt, ob KI-Bots gesperrt sind.

[00:47:22] Webseiten-Siegel und ihre Problematik

Torsten kritisiert käufliche Siegel, die „Klimaneutrale Website“ propagieren, aber eigentlich nur Bäume pflanzen und eine echte Optimierung und Beurteilung vornehmen. Sein Projekt Web4Nature setzt auf messbare Kriterien: nur Websites unter 1 MB erhalten das Siegel.

Sogar die allererste Website von 1991 ließe sich um 30% optimieren. Es geht immer besser.

[01:05:40] Nachhaltiges Podcasten

Auch Podcasts haben einen CO₂-Fußabdruck. Torsten spricht über seinen Podcast Web, But Green! und sein Buch.

Keine Schaunotizen

Beispiel für gute Nachhaltigkeitskommunikation großer Unternehmen: Unilever Sustainability Notice
Torstens Artikel: [1], [2], [3], [4]

Standard Podcast [ 1:14:46 ] Jetzt abspielen | Play in Popup | Download

Hans und Schepp sprechen darüber, wie weit „Vibe-Coding“ im Vergleich zu AI-Assist in der IDE wirklich trägt. Hans bringt sein Experiment mit, dokumentiert im Blogpost, und wir ordnen ein, wo AI uns Tempo schenkt, wo wir kontrollieren und nachschärfen müssen und warum die Dead Framework Theory im Code-Output der Generatoren so sichtbar wird.

Schaunotizen

[00:01:42] AI Code Generators Frontend Comparison

Als Testbett nutzt Hans wir eine kleine Reader-Web-App („Speak it“), die Webseiten- und PDF-Texte per Web-Speech-API vorliest. Dabei startet er jeweils mit einer kompakten Markdown-Featureliste und lässt daraus ein MVP bauen. Wir vergleichen anschließend, wie gut sich die Apps ausrollen lassen, wie sauber der Code ist und wie viel Nacharbeit bei Accessibility, Security, State-Management und Architektur nötig bleibt. Parallel diskutieren wir „AI-infused Coding“ in der IDE: Da hilft die AI beim Refactoring, beim Verstehen von Brownfield-Code und bei Fleißarbeit, während Vibe-Coding komplette Gerüste hinstellt – die Qualität steht und fällt aber mit Specs, Review und Tests.

Bei den Tools landet v0 vorne, vor allem wegen der sehr nahtlosen Integration in das Vercel-Ökosystem: Prompt rein, Code raus, Previews, Deploy, plus Plug-and-Play-Anbindung von Diensten wie Supabase für Auth und Daten und Stripe für Billing. Lovable wirkt stabil, setzt ebenfalls sinnvoll auf Supabase und punktet mit einem europäischen Setup. Replit überrascht mit einem Design-First-Flow, bei dem wir erst UI und Flows grob abstecken und danach generieren lassen. In der IDE-Ecke ist Cursor aktuell Hans’ Favorit, während GitHub Copilot sich mehr wie ein solider Pair-Programming-Assistent für Funktionen und kleine Refactors anfühlt. Claude Code glänzt im Reasoning, bleibt aber – wie alle – auf gute Prompts, klare Ziele und unseren Code-Review angewiesen. Base44 fällt für uns ab, weil Sichtbarkeit und Versionierung ohne größere Subscription eingeschränkt sind.

Im Code sehen wir überall das gleiche Muster: React beziehungsweise Next.js mit TypeScript und oft Tailwind. Das ist bequem, beschleunigt Onboarding und führt schnell zu ansehnlichen Ergebnissen, zementiert aber die Stack-Monokultur, die die Dead Framework Theory beschreibt. Spannend: v0 erzeugt im Vergleich recht kompakten, fokussierten Output, während andere Generatoren deutlich verboser werden – bei ähnlicher Feature-Abdeckung. Lighthouse-Werte sehen oft gut aus, verleiten aber zur falschen Sicherheit; wir finden typische A11y-Lücken wie fehlende Labels, suboptimale Focus-Flows und zu dezent deklarierte Namen. Unser Fazit bleibt: AI liefert Tempo und Gerüst, aber wir sichern Qualität mit Review, Tests, Monitoring und gezielten Verbesserungen.

Preislich bewegen sich viele Angebote um 20–25 Dollar im Monat. Für uns zählt, was wir dafür praktisch bekommen: gute Exporte, nachvollziehbare Diffs, belastbare Integrationen, EU-Hosting-Optionen und die Möglichkeit, bestehende Designsysteme einzubinden. Gerade im europäischen Kontext achten wir auf Datenstandorte und DSGVO-Konformität; mit Azure-gehosteten OpenAI-Modellen lässt sich beispielsweise vollständig in EU-Regionen arbeiten. Unterm Strich nutzen wir Vibe-Coding wie eine Welle: Wir lassen uns Scaffolding, CRUD-Wege und Settings-Screens generieren, steigen bei komplexen Stellen oder übertriebener Abstraktion selbst ein und wechseln dann wieder zurück zur AI, wenn es um Tempo und Variationen geht.

Zum Weiterlesen und Nachbauen: Hans’ vollständiger Vergleich steht im Blogpost. Die Tools aus der Folge findet ihr unter v0, Replit, Cursor, GitHub Copilot und Supabase; die Hintergründe zur Stack-Monokultur bündelt die Dead Framework Theory. Wir bleiben dran und schauen, wie sich Qualität, Kosten und Integrationen in den nächsten Monaten weiter entwickeln.

Standard Podcast [ 1:25:45 ] Jetzt abspielen | Play in Popup | Download

Um ein für allemal zu klären, ob React die beste oder die schlimmste Erfindung seit geschnitten Brot ist, luden sich Stefan und Peter den bekennenden React-Ultra Hans-Christian Otto ein!

Schaunotizen

[00:01:11] React

Um den eher semibrillianten Artikel React Won by Default entspann sich eine Pro/Contra-React-Diskussion in unserem Community-Slack (schaut gerne vorbei!), die wir in dieser Revision fortführen. Nach einem Definitionsversuch des Begriffs „React“, der entweder nur die Library oder ein ganzes Ökosystem meinen kann, versuchen wir uns am Herausarbeiten der Vor- und Nachteile. Dass man mit React gigantischen Blödsinn anstellen kann (illustriert durch das Next.js-basierte trumpcard.gov), ist ebenso unbestreitbar wie das verunglückte Design mancher APIs (v.A. useEffect()). Unser Gast argumentiert mit Verve, wie man mit React genau so gut auch Nicht-Blödsinn umsetzen kann, in etwa durch die Wahl eines geeigneten Stacks.

Standard Podcast [ 1:48:51 ] Jetzt abspielen | Play in Popup | Download

Diese Revision greifen wir eine Hörerfrage zu Browser-Engine-Diversity auf und ordnen sie gemeinsam ein: Wie steht es um Vielfalt, Governance und Einfluss großer Konzerne auf Blink, WebKit und Gecko? Wie steht es um die Zukunft von Mozilla? Und wir gehen den praktischen Fragen nach – von Marktanteilen über Contribution-Realität bis hin zu Modellen, wie Features trotzdem in alle Browser kommen.

Schaunotizen

[00:01:11] Browser-Engine-Diversity

In der Folge schildern wir zunächst die Ausgangsfrage: Was passiert, wenn eine Engine ausfällt? Und ist es überhaupt möglich, eine neue Engine „from Scracth“ zu bauen?.

Wir sprechen über die faktische Kontrolle bei Blink, WebKit und Mozilla, vergleichen das Governance-Modell mit dem Linux-Kernel und diskutieren, warum „Open Source“ auf dem Papier nicht automatisch breite Mitbestimmung bedeutet.

Wir beleuchten die Interop-Initiative, den Einfluss von Firmeninteressen auf Prioritäten und warum externe Beiträge in der Praxis selten sind – trotz positiver Beispiele. Dazu zählen Igalia als Dienstleister für Implementierungen quer durch die Engines sowie Yoav Weiss‚ Weg zur Umsetzung des <picture>-Elements in Blink bis hin zu seinen aktuellen Arbeiten an Speculation Rules in WebKit.

Wir schauen auf Marktanteile, reden über iOS-Restriktionen und darüber, warum wir uns eher regulatorische Einbußen bei Apple vorstellen können, als ein „Firefox geht hops“.

Zum Thema neue Engines fallen uns Servo und Ladybird ein: technisch überhaupt erst machbar dank präziser Specs und Tests – „nur sehr viel Arbeit“. Aber die Frage nach dem nachhaltigen Geschäftsmodell bleibt.

Am Ende geben wir konkrete Tipps: Issues schreiben, sich in Standards einbringen, gezielt Implementierungen finanzieren – und dabei die eigene Zeit trotzdem nicht verschenken.

Standard Podcast [ 1:17:31 ] Jetzt abspielen | Play in Popup | Download

In dieser Revision haben wir Webentwickler, Engineering-Manager und Autor Jens Oliver Meiert (Mastodon / Bluesky / LinkedIn) zu Gast und besprechen, weshalb HTML-Konformität die Basis professioneller Frontend-Arbeit ist, wo Validatoren und Tooling heute klemmen, wie optionales Markup und sinnvolle Minifizierung echte Gewinne bringen – und weshalb sauberes HTML die Voraussetzung bleibt, bevor wir über Semantik, Accessibility und DX diskutieren.

Schaunotizen

[00:01:10] 0 of the Global Top 200 Websites Use Valid HTML

Anlass unseres Gesprächs ist Jens´ alljährlich stattfindende Datenerhebung zu der HTML-Konformität der Top 200 Webseiten. Das Ergebnis ist Jahr für Jahr niederschmetternd. In 2025 schafft es keine der getesteten Webseiten keine HTML-Fehler zu haben. Wir vergleichen Beispiele mit wenigen Fehlern à la Wikipedia mit Seiten, die Hunderte Issues auf der Startseite sammeln, und was das als Proxy über Codequalität verrät.

Wir reden über die Tücken von Tools und Validatoren, über False Positives, neue Elemente wie <search> und darüber, wieso die Entfernung des ehemaligen WCAG-Kriteriums „Parsing“ zwar die Zugänglichkeit nicht torpediert, die Disziplin „valide liefern“ aber trotzdem nicht optional macht.

Wir schauen auf HTML-Minifizierung in der Praxis, auf Projekte wie den aktiven Fork von HTML-Minifier, und darauf, wie viel Performance schon dadurch möglich wird, dass wir Defaults nutzen und Überflüssiges streichen. Kurz: Wir plädieren dafür, HTML wieder ernst zu nehmen – als Sprache, die wir prüfen, optimieren und bewusst schreiben, bevor wir über Semantik-Feinschliff, Accessibility und DX diskutieren.

Links

Blog von Jens Oliver Meiert

Seine Essays und Forschungsnotizen zu HTML, CSS, Standards und Professionalität in der Webentwicklung liefern den Tiefgang zur Folge.

Frontend Dogma

Jens’ kuratierte Quelle und Archiv für Frontend-Artikel – ideal, um Trends, Historie und Handwerk im Blick zu behalten.

W3C Markup Validator

Unser Referenzwerkzeug, um HTML-Konformität zu prüfen und Fehler schnell sichtbar zu machen.

WHATWG HTML Standard

Die maßgebliche, lebende Spezifikation für HTML – inklusive Neuerungen wie dem <search>-Element.

Understanding the Removal of 4.1.1 Parsing in WCAG 2.2

Hintergrund, warum die WCAG das alte Kriterium 4.1.1 gestrichen hat und was das für den Zusammenhang zwischen Validität und Zugänglichkeit bedeutet.

WebAIM Million

Jährliche Bestandsaufnahme von Accessibility-Fehlern auf den Top-Websites – gut als Vergleich zu Validierungsbefunden geeignet.

HTML Minifier Next

Aktiv gepflegter Fork des ursprünglichen HTML-Minifiers, mit dem wir optionales Markup und Defaults konsequent in kleinere, schnellere Dokumente übersetzen.

Standard Podcast [ 1:01:27 ] Jetzt abspielen | Play in Popup | Download

Alle paar Monate setzen sich Peter und Schepp für eine neue Runde „Neues in den Browsern“ zusammen: Was hat Chrome gepusht, wo hat Safari nachgezogen, was ist frisch in Firefox – und vor allem: Was davon ist heute schon praxistauglich? Wir sortieren Release Notes, testen Features im Alltag und teilen konkrete Einsatzideen aus echten Projekten. In dieser Ausgabe geht’s u. a. um den IntersectionObserver mit scrollMargin, präziseres Rechnen mit Math.sumPrecise, explizites Ressourcen-Management, Scheduling für bessere INP-Werte, sowie Dialog/Popover-Feinschliff, @starting-style, View Transitions und eine schnelle Lightning-Round am Schluss mit kleinen, feinen Browser-Updates.

Schaunotizen

[00:03:25] IntersectionObserver: scrollMargin in allen Browsern

Endlich auch in Firefox: Beobachtungsbereich in versteckte Scrollzonen erweitern – z.B. für Lazy-Loading in Slidern (früheres Laden vor Sichtbarkeit). Abgrenzung zu rootMargin, graceful Degradation. Use-Cases: Performance-Moderation, Header ein-/ausblenden, lazy Komponenten initialisieren.

[00:15:42] JavaScript: Math.sumPrecise

Verhindert aufgesammelte Floating-Point-Fehler beim Aufsummieren (aktuell in Firefox, Standardisierung läuft). Kontext: 0.1 + 0.2 ≠ 0.3, Reihenfolge-Unterschiede bei Floats. Weiteres: Falsehoods programmers believe about money – Sarah Dayan, Floating Point visually explained.

[00:29:07] Explicit Resource Management (using, Symbol.dispose)

Deterministische Aufräumlogik (z.B. Temp-Dateien/Streams): Klassen implementieren Symbol.dispose/Symbol.asyncDispose, verwendet mit using. Abgrenzung zu GC-/Finalization-Registry; im Frontend selten nötig, im Backend super nützlich.

[00:30:12] WeakRefs/WeakMaps/WeakSets

State an DOM-Knoten hängen, ohne Leaks; nicht iterierbar by Design. Talk-Empfehlung: Dan Shappir – Strength in weakness.

[00:35:57] Partytown & Atomics mit SharedArrayBuffer

Third-party-Skripte in Web-Worker „so tun als ob DOM“ – Synchronisation über Atomics. (Historisch Fallback: synchrone XHR via SW-MitM – bitte nicht mehr.)

[00:39:46] Prioritized Task Scheduling API

await scheduler.yield() setzt freiwillige Sollbruchstellen in heavy Main-Thread-Tasks. Hilft INP („Interaction to Next Paint“), ohne jeden Schritt in Microtasks zu verpacken. Safari hinkt noch; Alternative/Ergänzung: requestIdleCallback.

[00:52:50] navigator.deviceMemory (Chromium) & RUMVision: Device Memory als Proxy

RAM-Buckets (1/2/4/8+ GB) als Proxy für Geräteleistung: Auf schwachen Geräten Third-Party (Analytics/Sentry) später oder gar nicht laden. Hintergrund/Lesetipp: INP-Analyse – RUMVision. SEO-Seitenthema: Scraper-Traffic & „Great Decoupling“ → Analyse von Brodie Clark.

[01:02:29] Dialog & Popover: Invoker-API, Fokus & Feinschliff

Invoker-/Command-Mechanik (commandForElement) für ohne JS-Boilerplate öffnen/schließen; nicht alle DOM-Methoden „automatisch“ als Command. Neues: closedBy (wer schloss den Dialog?) und showPopover({source}) – wichtig fürs Fokus-Return. Fokusmanagement bleibt knifflig.

[01:18:15] @starting-style

Saubere „from-state“ Transitions (z.B. Dialog-Entry) – alle großen Browser dabei. Stolpersteine: Josh W. Comeau: The big gotcha.

[01:19:17] View Transitions API

Nutzen für MPA-Flows (z.B. Button → Dialog „verwandeln“, List-Reorders). Praktisch auch für Exit-Animationen, wo Dialog selbst limitiert ist.

[01:24:43] HTTP: Clear-Site-Data

Gezielt Caches/Storage per Header leeren (Logout, harte Resets).

[01:29:51] CSS random() und tree-counting Funktionen.

Zufall in CSS für Effekte/Variationen; siehe auch Kizu: Tree counting & random.

[01:32:35] URL Pattern API

Bequemes URL-Matching in JS; neu in Firefox 142 & Safari 26.

[01:34:00] CSS :heading (Firefox)

Ein Selektor für alle Überschriften-Level – vereinfachtes Typo-Styling.

[01:35:00] CSS field-sizing

Eingabefeld-Autogröße und positionsgenaue Overlays/Tooltips – feineres UI-Layouting.

[01:35:50] Anchor Positioning

Feineres UI-Layouting für Overlays/Tooltips.

[01:37:35] CSS animation-timeline

Scroll-/View-gekoppelte Timelines – jetzt auch in Safari.

[01:38:10] Interop 2025

Gemeinsam priorisierte Feature-Arbeit der Browser-Teams – Grundlage dafür, dass vieles „überall benutzbar“ wird.

Standard Podcast [ 1:50:37 ] Jetzt abspielen | Play in Popup | Download

Sobald „TypeScript“ im Titel steht, ist das quasi die Lizenz zum Abschweifen. Schnallt euch also an, die Alten Herren nehmen euch mit in den statisch typisierten Mindpalast.

Schaunotizen

[00:01:35] TypeScript 5.9

Da das nächste TS-Release gelandet ist, sinnieren Peter und Stefan mal wieder über Architektur, Fehlermeldungs-Ergonomie und frische TypeScript-Details. Ausgangspunkt: Browser-Errors vs. Rust („FromEntries + Sparse Array“ lässt grüßen) und warum viele DevTools dabei schwächeln.

Danach geht’s in die 5.9-Notes: das verschlankte tsc --init, „Deferred Module Evaluation“ (import defer) als reine Syntax-Durchreiche, sowie der neue Zielwert module: node20 inkl. Import-Attributes (vormals Assertions) für JSON/CSS/WASM & Co. Wir sprechen über Modul-Laden in Browsern vs. Node, warum Bundler zunehmend nach Legacy riechen, ob Import-Maps und ein „print module graph“ aus TSC den Build-Step ablösen könnten – und wieso Lighthouse-Scores dabei wenig helfen.

Auf Editor-Seite freuen wir uns über MDN-Kurzbeschreibungen in DOM-Tooltips, expandierbare Typ-Hovers (endlich beides: kompakt und detailliert) und ein konfigurierbares Hover-Limit. Unter der Haube gibt’s Performance-Gewinne und ein wichtiges Typing-Fix: ArrayBuffer ist nicht länger (fälschlich) Supertyp diverser Typed Arrays. Am Ende blicken wir nach vorn: 6.x als „Glattbügel-Serie“ auf dem Weg zu TS 7 (Go-Rewrite), nebst den unvermeidlichen Ecosystem-Reibungen zwischen Node, Deno, Web-Streams & Freunden.

Standard Podcast [ 1:06:13 ] Jetzt abspielen | Play in Popup | Download