Curso de HTML / Validar formularios con required, longitud y rangos

La validación nativa de HTML puede detectar campos obligatorios vacíos, longitudes inadecuadas, valores fuera de rango y algunos formatos antes de un envío interactivo. Atributos como required, minlength, maxlength, min y max ayudan al usuario a corregir errores. Estas comprobaciones no sustituyen la validación del servidor.

Separar un valor obligatorio de su longitud

El siguiente formulario pide un apodo de 2 a 20 unidades de longitud. Ponlo en el cuerpo de un documento completo para probarlo.

<form method="get">
  <label for="nickname">Nickname (2–20 characters)</label>
  <input id="nickname" name="nickname" type="text"
         required minlength="2" maxlength="20">
  <button type="submit">Check</button>
</form>

Intenta enviar el campo vacío, después con una letra y luego con dos. required exige un valor y minlength aplica una longitud mínima al texto introducido por el usuario; no se implican mutuamente. El mensaje concreto depende del navegador, el sistema y su idioma.

Indica la regla antes del error. maxlength suele impedir que el usuario escriba más de su límite, pero HTML mide estas longitudes en unidades de código UTF-16. Algunas secuencias visibles, como ciertos emoji, no equivalen a una sola unidad. Si tu aplicación admite esos caracteres, compara entradas reales con la regla aplicada por el servidor.

Los valores introducidos mediante scripts pueden tener condiciones de comprobación distintas de las entradas del usuario. Si el formulario utiliza scripts, prueba también ese recorrido. La referencia de maxlength de MDN explica la medida de longitud.

Comprobar rango, paso y formato

El siguiente fragmento combina una cantidad entera de 1 a 10 con un correo obligatorio. Utiliza datos ficticios como name@example.com.

<form method="get">
  <label for="people">Participants (1–10)</label>
  <input id="people" name="people" type="number"
         min="1" max="10" step="1" required>

  <label for="email">Email address</label>
  <input id="email" name="email" type="email" required>
  <button type="submit">Check</button>
</form>

min y max establecen límites y step="1" limita los incrementos permitidos en este contexto. Escribe manualmente 0, 11 y 2.5: que el valor se vea en el campo no significa que sea válido para el envío. Prueba también los controles de incremento del navegador.

type="email" comprueba un formato básico, no la existencia del buzón. El significado del dato debe justificar el tipo elegido, según los tipos de input. Un número válido tampoco convierte en válido todo el formulario si el correo sigue fallando.

Comparar casos límite con resultados esperados

Mantén un correo ficticio con formato correcto durante esta comparación para que su error no oculte el de la cantidad. Cambia un solo valor, intenta enviar y vuelve al estado inicial antes del siguiente caso. La tabla describe restricciones, no una frase exacta que deba mostrar todo navegador.

El ejemplo GET apunta al documento actual y no contiene un servidor que guarde los datos. Con una página servida por HTTP podrás observar la petición; en un archivo local el comportamiento de navegación puede variar. La inspección de GET y POST separa esos resultados.

Dar instrucciones que permitan corregir el error

“Introduce un número entero entre 1 y 10” orienta mejor que “dato incorrecto”. No identifiques un fallo únicamente por el color del borde. Mantén las condiciones importantes visibles y relacionadas con su campo, como en las instrucciones persistentes de un formulario.

Una interfaz de error personalizada requiere asociar cada mensaje al control, actualizarlo cuando cambie el estado y comprobar el foco y el teclado. aria-describedby por sí solo no crea ninguna validación. El atributo novalidate omite la validación interactiva nativa en el envío; no lo añadas simplemente para ocultar un problema.

Validar también en el servidor

El usuario puede eludir las restricciones del navegador mediante herramientas de desarrollo o una petición creada fuera del formulario. El servidor debe comprobar los valores importantes, especialmente los utilizados en cuentas, operaciones o registros persistentes.

Antes de dar por terminada una regla, prueba ausencia de valor, límites inferiores y superiores y valores intermedios. Recorre los campos solo con teclado, corrige los errores y comprueba que puedas continuar. La guía de validación de W3C WAI y la guía de restricciones de MDN ayudan a revisar tanto la comprobación como su explicación al usuario.