Thema: html
-
Responsive Bilder mit srcset, sizes und picture
srcset mit Breitenbeschreibungen zusammen mit einem sizes-Attribut lässt den Browser die kleinste Bilddatei wählen, welche die Fläche beim aktuellen Viewport und der aktuellen Pixeldichte füllt; x-Beschreibungen liefern Bilder fester Grösse in mehreren Dichten; picture mit source-Elementen behandelt Art Direction und Format-Fallback. width und height stets angeben, damit sich das Layout während des Ladens nicht verschiebt.
-
Native HTML-Formularvalidierung: required, pattern, type und die Constraint Validation API
HTML validiert Formularfelder vor dem Absenden ganz ohne Skript: required, minlength, min/max, pattern und typisierte Eingaben definieren Bedingungen, der Browser blockiert das Absenden und zeigt eine Meldung, CSS kann :user-invalid stylen, und die Constraint Validation API macht denselben Zustand für Skripte zugänglich. Das ist eine Usability-Schicht, keine Sicherheitsschicht; der Server validiert erneut.
-
Web Components: Custom Elements, Shadow DOM und wo die Kapselung endet
Custom Elements registrieren eine Klasse unter einem Tag-Namen mit Bindestrich samt Lifecycle-Callbacks; Shadow DOM gibt ihr einen abgegrenzten Teilbaum, dessen Stile in keine Richtung durchsickern; Templates und deklarative Shadow Roots liefern Markup. Jedes grenzüberschreitende Anliegen, vom Styling über Parts und Custom Properties bis zur Formularteilnahme via ElementInternals und Label-Zuordnung, muss bewusst geöffnet werden.
-
Formulare mit nativen HTML-Constraints erzeugen pro Absendung weniger serverseitige Validierungsablehnungen als Formulare, die nur per eigenem JavaScript validiert werden
Hypothese: Der Browser blockiert die interaktive Absendung eines Formulars, dessen native Constraints (required, pattern, type, min und max) nicht erfüllt sind, während MDN festhält, dass ein Aufruf von submit() dies umgeht und novalidate es abschaltet; die These lautet, dass Formulare mit nativen Constraints, die die Serverregeln spiegeln, pro Absendung weniger Ablehnungen beim Server auslösen als Formulare, deren Prüfungen nur in eigenem Skript stecken, weil die nativen Prüfungen weiterlaufen, wenn das Skript nicht lädt oder Fehler wirft; vorgeschlagen wird ein A/B-Test, ohne behauptetes Ergebnis.
-
Favicons und das Web-App-Manifest: welche Dateien ausgeliefert werden müssen und wie sie deklariert werden
Browser greifen auf /favicon.ico zurück, wenn kein link rel=icon deklariert ist, daher diese Datei bereithalten; ein skalierbares SVG oder ein PNG mit fester Grösse per link rel=icon deklarieren, dazu ein apple-touch-icon und ein Manifest, dessen icons mit sizes und einem purpose (any, maskable, monochrome) versehen sind. Suchmaschinen wollen pro Hostname ein stabiles, quadratisches Favicon.
-
Barrierefreie Formulare: Labels, Fehlermeldungen und Autocomplete
Jedem Steuerelement ein über for und id verknüpftes Label geben, Pflichtfelder im Text und über das Attribut kennzeichnen, Autocomplete-Tokens verwenden, damit Browser und assistive Technologien den Zweck eines Feldes kennen, und Fehler in einer Zusammenfassung plus feldbezogenen, über aria-describedby verknüpften Meldungen melden.
-
dialog versus popover: modales Verhalten, der Top Layer und Light Dismiss
dialog mit showModal() ist modal: Top Layer, inerte Seite, ::backdrop, Escape, closedby und form method=dialog; das popover-Attribut macht ein beliebiges Element zu einem nicht-modalen Top-Layer-Overlay, das ein Button ohne Skript umschaltet und das im auto-Zustand per Light Dismiss geschlossen wird. dialog für blockierende Eingabeaufforderungen und Formulare einsetzen, popover für Menüs, Tooltips und Toasts.
-
ARIA-Rollen: warum ein natives HTML-Element einem div mit Rolle überlegen ist
Die erste Regel des W3C für den Einsatz von ARIA lautet, ein natives HTML-Element oder -Attribut zu bevorzugen, das die benötigte Semantik und das Verhalten bereits mitbringt; ARIA ändert nur, was assistiven Technologien mitgeteilt wird, nie, was das Element tatsächlich tut. Ein div mit role=button braucht Fokussierbarkeit, Tastaturbehandlung und Zustände weiterhin von Hand hinzugefügt, und jeder Fehler dabei bleibt im visuellen Test unsichtbar.
-
Fokus-Management bei Single-Page-Interaktionen: Dialoge, Routenwechsel und entfernte Elemente
Ändert sich eine Seite ohne vollständigen Ladevorgang, muss der Tastaturfokus gezielt bewegt werden: in einen Dialog hinein, wenn er sich öffnet, und zurück zu seinem Auslöser, wenn er sich schliesst, zur Überschrift der neuen Ansicht nach einem clientseitigen Routenwechsel, und zu einem sinnvollen Nachbarn, wenn das fokussierte Element gelöscht wird. Andernfalls fällt der Fokus auf den Document Body zurück, und Screenreader-Nutzende werden an den Seitenanfang zurückgeschickt.
-
Barrierefreiheit: die vier WCAG-Grundsätze praktisch angewendet
Die WCAG 2.2 ordnen alle Erfolgskriterien vier Grundsätzen zu: wahrnehmbar, bedienbar, verständlich, robust. Wer pro Grundsatz die häufigsten Verstösse kennt (fehlende Textalternativen, Tastaturfallen, zu wenig Kontrast, unbeschriftete Felder, zu kleine Ziele), findet viele Barrieren ohne Spezialwerkzeug; Stufe AA ist das übliche Ziel.
-
details und summary: native Disclosure-Widgets, exklusive Akkordeons und hidden until-found
details/summary ist ein Disclosure-Widget ohne Skript: Das open-Attribut zeigt den Inhalt, ein gemeinsames name-Attribut macht eine Gruppe exklusiv, sodass das Öffnen eines Elements die anderen schliesst, das toggle-Ereignis meldet Änderungen, und summary wird als display: list-item dargestellt. Für eingeklappten Inhalt, der weiterhin durchsuchbar bleiben muss, macht hidden=until-found ihn bei der Seiten-Suche oder bei Fragment-Navigation sichtbar.
-
Bildauslieferung: AVIF und WebP mit Fallbacks, Lazy Loading und Fetch Priority
Moderne Formate über picture-Quellen mit type-Attribut ausliefern, mit einem JPEG- oder PNG-img als Fallback (oder über Accept mit Vary aushandeln), nur Bilder unterhalb des ersten Viewports mit gesetzten width- und height-Werten per Lazy Loading laden und das grösste Bild oberhalb des sichtbaren Bereichs mit fetchpriority=high statt lazy auszeichnen.
Maschinenlesbar: JSON