Tema: html
-
Imágenes responsivas con srcset, sizes y picture
srcset con descriptores de ancho junto con un atributo sizes permite que el navegador elija el archivo de imagen más pequeño que llena el espacio disponible según el viewport y la densidad de píxeles actuales; los descriptores x sirven imágenes de tamaño fijo a varias densidades; picture con elementos source gestiona la dirección de arte y el respaldo de formato. Conviene mantener siempre width y height para que el diseño no se desplace mientras carga la imagen.
-
Validación nativa de formularios HTML: required, pattern, type y la Constraint Validation API
HTML valida los controles de formulario antes del envío sin necesidad de script: required, minlength, min/max, pattern y los tipos de entrada definen restricciones, el navegador bloquea el envío y muestra un mensaje, CSS puede aplicar estilos a :user-invalid, y la Constraint Validation API expone el mismo estado a los scripts. Es una capa de usabilidad, no una capa de seguridad; el servidor vuelve a validar.
-
Componentes web: elementos personalizados, shadow DOM y dónde termina el encapsulamiento
Los elementos personalizados registran una clase bajo un nombre de etiqueta con guion y con callbacks de ciclo de vida; el shadow DOM le otorga un subárbol acotado cuyos estilos no se filtran en ningún sentido; las plantillas y los shadow roots declarativos aportan el marcado. Cada aspecto que cruza el límite, desde el estilo mediante parts y propiedades personalizadas hasta la participación en formularios vía ElementInternals y la asociación de etiquetas, debe abrirse de forma deliberada.
-
Los formularios que declaran restricciones nativas de HTML producen menos rechazos de validación en el servidor por envío que los formularios validados solo con JavaScript personalizado
Hipótesis: el navegador bloquea el envío interactivo de un formulario cuyas restricciones nativas (required, pattern, type, min y max) no se cumplen, mientras que MDN señala que llamar a submit() evita esto y que novalidate lo desactiva; la propuesta es que los formularios que incorporan restricciones nativas que reflejan las reglas del servidor llegan al servidor con menos rechazos por envío que los formularios cuyas comprobaciones residen solo en scripts personalizados, porque las comprobaciones nativas siguen funcionando cuando el script no se carga o falla; se propone una prueba A/B, sin que se afirme ningún resultado.
-
Favicons y el manifiesto de aplicación web: los archivos que hay que incluir y cómo declararlos
Los navegadores recurren a /favicon.ico cuando no se declara ningún link rel=icon, así que ese archivo debe mantenerse en su lugar; hay que declarar un SVG escalable o un PNG con tamaño mediante link rel=icon, un apple-touch-icon y un manifiesto cuyos iconos incluyan tamaños y un propósito (any, maskable, monochrome). Los motores de búsqueda quieren un único favicon estable y cuadrado por nombre de host.
-
Formularios accesibles: etiquetas, mensajes de error y autocompletado
Asociar cada control con una etiqueta mediante for e id, marcar los campos obligatorios en el texto y con el atributo, usar tokens de autocompletado para que los navegadores y la tecnología de asistencia conozcan el propósito de un campo, e informar los errores en un resumen más mensajes por campo enlazados con aria-describedby.
-
dialog frente a popover: comportamiento modal, la capa superior y el descarte ligero
dialog con showModal() es modal: capa superior, página inerte, ::backdrop, Escape, closedby y form method=dialog; el atributo popover convierte cualquier elemento en una superposición de capa superior no modal que un botón alterna sin script, y que se descarta ligeramente en el estado auto. Usar dialog para prompts bloqueantes y formularios, popover para menús, tooltips y toasts.
-
Roles ARIA: por qué un elemento HTML nativo supera a un div con un rol
La primera regla del W3C sobre el uso de ARIA es preferir un elemento o atributo HTML nativo que ya tenga la semántica y el comportamiento requeridos; ARIA solo cambia lo que se comunica a la tecnología de asistencia, nunca lo que hace el elemento. Un div con role=button sigue necesitando que se le añadan a mano la capacidad de recibir foco, el manejo de teclas y los estados, y cada error de este tipo resulta invisible en las pruebas visuales.
-
Gestión del foco en interacciones de página única: diálogos, cambios de ruta y elementos eliminados
Cuando una página cambia sin una carga completa, el foco del teclado debe moverse de manera deliberada: hacia un diálogo cuando se abre y de vuelta a su disparador cuando se cierra, hacia el encabezado de la nueva vista después de un cambio de ruta del lado del cliente, y hacia un vecino razonable cuando se elimina el elemento enfocado. De lo contrario, el foco recae en el body del documento y las personas que usan lector de pantalla vuelven al principio.
-
Accesibilidad: los cuatro principios de las WCAG aplicados en la práctica
Las WCAG 2.2 agrupan todos los criterios de conformidad en cuatro principios: perceptible, operable, comprensible y robusto. Conocer los fallos más habituales de cada uno (falta de alternativas textuales, trampas de teclado, contraste insuficiente, campos sin etiqueta, objetivos demasiado pequeños) permite detectar muchas barreras sin herramientas especiales; el nivel AA es el objetivo habitual.
-
details y summary: widgets de divulgación nativos, acordeones exclusivos y hidden=until-found
details/summary es un widget de divulgación sin script: el atributo open muestra el contenido, un atributo name compartido hace exclusivo un grupo (al abrir un elemento se cierran los demás), el evento toggle informa de los cambios y summary se estiliza como display: list-item. Para contenido contraído que debe seguir siendo localizable, hidden=until-found lo revela al buscar en la página o al navegar a un fragmento.
-
Entrega de imágenes: AVIF y WebP con alternativas, carga diferida y prioridad de descarga
Sirve formatos modernos mediante elementos source de picture con el atributo type y un img en JPEG o PNG como alternativa (o negocia con Accept y Vary). Aplica carga diferida solo a las imágenes situadas bajo el primer viewport, con width y height definidos, y marca con fetchpriority=high la imagen más grande visible sin hacer scroll, en lugar de lazy.
Legible por máquina: JSON