Validación de formularios del lado del cliente: JavaScript Vs HTML5

Imaginad que estáis desarrollando vuestro website modernísimo de la muerte y, por tanto, decidís hacerlo en HTML5. Llegáis a la parte del formulario de contacto, lo validáis con HTML5 y, probando en Safari (porque todos los guays de ahora programan en Mac y tienen Safari y prueban las cosas ahí también), os horrorizáis al ver que Safari suda de vuestra verificación y manda los formularios vacíos o mal completados. Aaaaaamigos, ¡bienvenidos una vez mas al maravilloso mundo de: ¿por qué me dediqué yo a esto con lo feliz que sería haciendo otra cosa?!

Veamos cómo funcionan las validaciones del lado del cliente, es decir, en el dispositivo del usuario que interactúa con nuestra web, no en el servidor donde ésta está alojada (verificaciones estas otras que son también necesarias y deseables pero de las que no hablo en esta ocasión).

Por un lado tenemos la forma de toda la vida de verificar que, cuando alguien nos manda un formulario, al menos haya algo escrito en él: El JavaScript (está también muy de moda la verificación JQuery, pero a fin de cuentas…). Por otro lado, tenemos la forma más reciente propuesta por HTML5. A saber:

 

Ventajas y desventajas de la verificación con JavaScript

A favor

  1. Personalizable
    • En casuística (que para eso la programas)
    • En diseño (para poner colorines y mensajes de alerta)
  2. Mayor compatibilidad con navegadores (casi todos los modernos y no tan modernos)

En contra

  1. Algunos usuarios pueden tener el JS deshabilitado (lo hacen por fastidiar, ¡lo sabemos!)
  2. Hay que programar cada verificación (y eso es un engorro)

 

Ventajas y desventajas de la verificación con HTML5

A favor

  1. Validación nativa, es decir:
    • Rápida para el desarrollador, pues no requiere programar las verificaciones, basta con decir: oye, esto es obligatorio (required)
    • Rápida y segura para el usuario, su navegador lo hace todo, sin complementos
  2. Mayor precisión semántica:
    • De la generalidad del campo de tipo texto, pasamos a poder especificar si se trata de un email, una url, una fecha…
  3. Ideal para dispositivos móviles:
    • Algunos terminales mostrarán distintos tipos de teclado según los datos que se tengan que introducir (números para fechas, @ para emails, .com para urls…)

En contra

  1. Escasamente personalizable:
    • En cuanto a diseño de los errores/alertas (los navegadores se lo guisan, los navegadores se lo comen)
    • En cuanto al control de determinados comportamientos de la validación (ver caso con textarea explicado más abajo)
  2. Menor compatibilidad con navegadores, habiendo casos sangrantes:
    • (a 2014) Safari, aunque reconoce los input types de HTML5, no reconoce el atributo required y, por tanto, envía los formularios sin validar (¡alegría! NO.)

Aclarando conceptos sobre HTML5

required

Con el atributo required, HTML5 se asegurará de que haya contenido en cada uno de los campos especificados y, si no lo hay, advertirá al usuario. Además, en caso de los input, verificará si ese contenido coincide con el type que se le haya asignado. Es decir, en un input de tipo email, HTML5 por sí mismo comprobará que los datos metidos por el usuario parecen un email con su arroba y su punto obligatorios.

Imagen de un fragmento del código de un formulario HTML5
Si añadimos el atributo title, ampliaremos la información de error mostrada por defecto en algunos navegadores (Chrome y Opera la muestran siempre, Firefox en algunos casos).

En el caso del textarea, required verificará que en ese campo haya al menos 1 carácter escrito. Si queremos un tope por lo alto (un máximo de caracteres), indicaremos con el atributo maxlength cuál será, entonces cuando el usuario lo sobrepase, no podrá escribir más (los caracteres se pararán sin recoger más datos). Sin embargo, no podremos establecer un tope por lo bajo, ni siquiera con un patrón de comportamiento (pattern).

pattern

Como acabo de comentar, para ser más específicos todavía en el formato del tipo de datos que se pueden introducir en un campo, podemos establecer patrones de comportamiento según los cuales required afinará la validación. Así, por ejemplo el patrón: pattern="\S{3,20}" define que el dato introducido en ese input sólo puede contener de 3 a 20 caracteres. Típico de campos de contraseña, por ejemplo.

Este atributo, con otros parámetros, puede ser usado para verificar el contenido de otros input types. Por ejemplo, para email sería algo como: pattern="^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$". PERO, en esta ocasión, estaríamos verificando lo que ya hace de por sí el navegador cuando lee que un input es de tipo email.

 

Conclusiones

Así las cosas, resulta que, a estas alturas del partido (septiembre, 2014), HTML5 sigue siendo un estándar en desarrollo y falla, cual escopeta de feria, en temas como este. Bueno, HTML5 no falla, falla su adopción por parte de los navegadores que se van adaptando a él. Por lo que, para evitarnos el horror de ver cómo ciertos navegadores ignoran ciertos comportamientos del HTML5 y, a la vez, ser más precisos que antes, lo mejor es optar por hacer un batiburrillo con las dos metodologías de verificación:

  1. Usaremos la verificación JS
    • Para una mayor compatibilidad y personalización
  2. Jugaremos con los tipos de input y las nuevas etiquetas de HTML5
    • Para una mayor precisión semántica
    • Para adaptarnos a los dispositivos móviles

Como habréis visto, éste no es un tutorial sobre cómo verificar formularios con JS o con HTML5, de esos hay unos pocos en internet y muy variados. Preguntadle a Google si tenéis dudas. O también podéis comentar aquí vuestras impresiones.

¡Comenta!

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.