HTML
Cómo funciona la validación nativa de formularios con required, type, pattern, min, max y Constraint Validation API, sin sustituir la validación del servidor.
La permite que el navegador compruebe reglas declaradas en los controles antes de enviar el formulario.
<input
name="email"
type="email"
required
maxlength="120"
>required.type especializado.minlength y maxlength.min y max.step.pattern.Un control puede ser inválido por varias razones.
JavaScript expone estados como:
valueMissing
typeMismatch
patternMismatch
tooLong
tooShort
rangeUnderflow
rangeOverflow
stepMismatch
badInput
customError
validemail.validity.typeMismatch;No necesitas comprobar cada propiedad manualmente si solo quieres activar el flujo nativo.
form.checkValidity();Devuelve un booleano y dispara eventos invalid en controles que fallan, sin mostrar necesariamente toda la UI nativa como una activación de submit.
form.reportValidity();Comprueba y solicita al navegador mostrar mensajes/indicadores nativos.
<form novalidate>...</form>Desactiva la validación interactiva del formulario. Los constraints y APIs siguen existiendo.
Úsalo solo si implementas una experiencia alternativa completa.
<button type="submit" formnovalidate>
Guardar borrador
</button>Desactiva validación para ese submitter. Es útil cuando un borrador puede estar incompleto.
form.addEventListener("invalid", handleInvalid, true);No burbujea de forma normal, por lo que se usa captura o listeners por control.
No muestres el mismo mensaje varias veces mediante UI nativa, toast y texto inline sin coordinar.
passwordConfirmation.setCustomValidity(
passwordConfirmation.value === password.value
? ""
: "Las contraseñas no coinciden."
);Un string no vacío mantiene el control inválido. Debes limpiarlo cuando la condición se resuelva.
<label for="username">Usuario</label>
<input
id="username"
name="username"
required
pattern="[a-z0-9_]{3,20}"
aria-describedby="username-help username-error"
>
<p id="username-help">
Entre 3 y 20 caracteres: minúsculas, números o guion bajo.
</p>
<p id="username-error" hidden></p>Las reglas deben conocerse antes del error. Al fallar:
aria-invalid="true" cuando corresponda.En formularios largos puede añadirse un resumen al inicio:
<div id="error-summary" tabindex="-1" role="alert">
<h2>Corrige los siguientes campos</h2>
<ul>
<li><a href="#email">Ingresa un correo válido.</a></li>
</ul>
</div>Mueve foco al resumen después de un envío fallido cuando ayuda a comprender el resultado. Los links llevan a cada campo.
No uses role="alert" en contenido presente desde carga; resérvalo para cambios importantes dinámicos.
input:invalid { ... }
input:user-invalid { ... }:invalid puede aplicar desde la carga antes de interacción. Pseudoclases orientadas a interacción, cuando tienen soporte suficiente, evitan mostrar todo como error inmediatamente.
No dependas solo de color o bordes.
pattern utiliza una expresión regular bajo reglas del navegador y debe coincidir con todo el valor.
No escribas patterns demasiado complejos para datos como nombres, emails internacionales o direcciones. La validación restrictiva puede rechazar usuarios reales.
El servidor puede descubrir:
Devuelve mensajes relacionados con los campos o con el formulario completo. No borres datos válidos al volver a renderizar.
Cualquiera puede:
La validación del servidor es la autoridad.
<form action="/contact" method="post">
<div>
<label for="email">Correo</label>
<input
id="email"
name="email"
type="email"
required
aria-describedby="email-error"
>
<p id="email-error" hidden></p>
</div>
<button type="submit">Enviar</button>
</form>¿Por qué un control sigue inválido después de corregirlo si no limpias setCustomValidity?
Porque cualquier mensaje personalizado no vacío mantiene customError activo, aunque los demás constraints ya se cumplan.
Envío, action, method y enctype explica cómo se construye y transporta el formulario.