Validación nativa de formularios HTML: required, pattern, type y la Constraint Validation API

Qué es

HTML comprueba los controles de formulario antes de enviarlo, sin necesidad de ningún script. required, minlength y maxlength, min, max y step, pattern, y los tipos de entrada email, url, number y date declaran cada uno una restricción. Cuando un control incumple alguna, el navegador se niega a enviar el formulario y muestra su propio mensaje en el primer control inválido. La guía de MDN describe el lado CSS: un control inválido coincide con :invalid, y, una vez que el usuario ha interactuado con él, también con :user-invalid. La Constraint Validation API (checkValidity(), reportValidity(), setCustomValidity(), el objeto validity) expone el mismo estado a los scripts; novalidate en el formulario desactiva los globos del navegador, pero la API sigue funcionando.

Por qué importa

La validación nativa funciona antes de que haya llegado, se haya ejecutado o haya fallado cualquier JavaScript; sus mensajes aparecen en el idioma propio del navegador sin necesidad de trabajo de traducción; y las restricciones viven una sola vez, en el marcado, donde los scripts, las pruebas y los rastreadores pueden leerlas. No es una medida de seguridad: la guía de MDN es explícita en que el servidor debe validar igualmente cada envío.

Cómo aplicarlo

• Elegir primero el type: email, url y number traen su propia restricción y su propio teclado. Usar inputmode para texto libre que solo necesita un teclado numérico.
• Añadir required, minlength, min/max y pattern para las reglas de formato. El patrón se compila como una expresión regular de JavaScript y debe coincidir con el valor completo. Describir el formato esperado en texto visible y en un atributo title; la página citada señala que los navegadores pueden usar el title en el mensaje de validación.
• Aplicar estilos a :user-invalid en lugar de a :invalid, para que los campos obligatorios vacíos no se marquen en rojo antes de que el usuario los haya tocado.
• Usar setCustomValidity() para las reglas que cruzan varios campos, como la confirmación de contraseña, y restablecerla con una cadena vacía, porque de lo contrario el control queda inválido de forma permanente.
• Si se renderiza una lista de errores propia bajo novalidate, conviene igualmente llamar a reportValidity() para que los usuarios de teclado y de lector de pantalla sean dirigidos al primer error.
• Probar la ruta del servidor enviando con novalidate o con curl; las comprobaciones del navegador son una cortesía, no un contrato.

Trampas

Los globos de error nativos no se pueden personalizar con estilos, desaparecen cuando cambia el foco y muestran un error a la vez. Un pattern en type="email" se combina con la comprobación incorporada, así que ambos deben superarse. Los controles deshabilitados nunca se validan. Un control obligatorio oculto con display: none sigue bloqueando el envío, pero el navegador no tiene dónde mostrar el mensaje, lo cual se reporta comúnmente como un fallo de «el formulario no hace nada». Los campos de fecha y número renderizan widgets dependientes del idioma que son difíciles de restilizar.