Tema: html
-
Responsive images with srcset, sizes and picture
srcset with width descriptors plus a sizes attribute lets the browser pick the smallest image file that fills the slot at the current viewport and pixel density; x descriptors serve fixed-size images at several densities; picture with source elements handles art direction and format fallback. Always keep width and height so the layout does not shift while the image loads.
-
Native HTML form validation: required, pattern, type and the Constraint Validation API
HTML validates form controls before submission with no script: required, minlength, min/max, pattern and typed inputs define constraints, the browser blocks submission and shows a message, CSS can style :user-invalid, and the Constraint Validation API exposes the same state to scripts. It is a usability layer, not a security layer; the server validates again.
-
Web components: custom elements, shadow DOM and where the encapsulation ends
Custom elements register a class under a hyphenated tag name with lifecycle callbacks; shadow DOM gives it a scoped subtree whose styles do not leak either way; templates and declarative shadow roots supply markup. Every cross-boundary concern, from styling through parts and custom properties to form participation via ElementInternals and label association, must be opened deliberately.
-
Forms that declare native HTML constraints produce fewer server-side validation rejections per submission than forms validated only in custom JavaScript
Hypothesis: the browser blocks interactive submission of a form whose native constraints (required, pattern, type, min and max) fail, while MDN notes that calling submit() bypasses this and novalidate disables it; the proposal is that forms carrying native constraints that mirror the server rules reach the server with fewer rejections per submission than forms whose checks live only in custom scripts, because the native checks keep working when the script fails to load or errors; a proposed A/B test, with no result claimed.
-
Favicons and the web app manifest: the files to ship and how to declare them
Browsers fall back to /favicon.ico when no link rel=icon is declared, so keep that file in place; declare a scalable SVG or a sized PNG with link rel=icon, an apple-touch-icon, and a manifest whose icons carry sizes and a purpose (any, maskable, monochrome). Search engines want one stable, square favicon per hostname.
-
Accessible forms: labels, error messages and autocomplete
Give every control a label associated by for and id, mark required fields in text and with the attribute, use autocomplete tokens so browsers and assistive technology know a field's purpose, and report errors in a summary plus per-field messages linked with aria-describedby.
-
dialog versus popover: modal behaviour, the top layer and light dismiss
dialog with showModal() is modal: top layer, inert page, ::backdrop, Escape, closedby and form method=dialog; the popover attribute makes any element a non-modal top-layer overlay that a button toggles without script, light-dismissed in auto state. Use dialog for blocking prompts and forms, popover for menus, tooltips and toasts.
-
ARIA roles: why a native HTML element beats a div with a role
The W3C's first rule of ARIA use is to prefer a native HTML element or attribute that already has the semantics and behaviour required; ARIA only changes what assistive technology is told, never what the element does. A div with role=button still needs focusability, key handling and states added by hand, and every mistake is invisible in visual testing.
-
Focus management in single-page interactions: dialogs, route changes and removed elements
When a page changes without a full load, keyboard focus must be moved on purpose: into a dialog when it opens and back to its trigger when it closes, to the new view's heading after a client-side route change, and to a sensible neighbour when the focused element is deleted. Otherwise focus falls to the document body and screen-reader users are sent back to the top.
-
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 and summary: native disclosure widgets, exclusive accordions and hidden until-found
details/summary is a disclosure widget with no script: the open attribute shows the content, a shared name attribute makes a group exclusive so opening one closes the others, the toggle event reports changes, and summary is styled as display: list-item. For collapsed content that must stay searchable, hidden=until-found reveals it on find-in-page or fragment navigation.
-
Image delivery: AVIF and WebP with fallbacks, lazy loading and fetch priority
Serve modern formats through picture sources with a type attribute and a JPEG or PNG img as the fallback (or negotiate on Accept with Vary), lazy-load only images below the first viewport with width and height set, and mark the largest above-the-fold image fetchpriority=high instead of lazy.
Legible por máquina: JSON