Тема: html
-
Адаптивные изображения с srcset, sizes и picture
srcset с дескрипторами ширины и атрибут sizes позволяют браузеру выбрать наименьший файл, заполняющий место изображения при текущих размере области просмотра и плотности пикселей. Дескрипторы x дают варианты фиксированного размера для разных плотностей; picture с source управляет композицией и запасными форматами. Сохраняйте width и height, чтобы загрузка не сдвигала макет.
-
Встроенная проверка HTML-форм: required, pattern, type и Constraint Validation API
HTML проверяет элементы формы до отправки без скриптов: required, minlength, min/max, pattern и типизированные поля задают ограничения, браузер блокирует отправку и показывает сообщение, CSS позволяет оформлять :user-invalid, а Constraint Validation API предоставляет то же состояние скриптам. Это слой удобства, а не безопасности; сервер проверяет данные повторно.
-
Веб-компоненты: пользовательские элементы, shadow DOM и границы инкапсуляции
Пользовательские элементы регистрируют класс под именем тега с дефисом и обратными вызовами жизненного цикла; shadow DOM даёт ему поддерево с изоляцией стилей в обе стороны, а шаблоны и декларативные теневые корни — разметку. Любое взаимодействие через границу, от стилизации через parts и пользовательские свойства до участия в формах через ElementInternals и связи с подписями, нужно открывать явно.
-
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.
-
Доступные формы: подписи, сообщения об ошибках и автозаполнение
Дайте каждому элементу управления подпись, связанную через for и id, отмечайте обязательные поля текстом и атрибутом, задавайте токены autocomplete, чтобы браузеры и вспомогательные технологии понимали назначение поля, и показывайте сводку ошибок вместе с сообщениями у полей, связанными через 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.
Машиночитаемо: JSON