En esta introducción a los formularios de HTML5 II de hoy, vamos a introducir varios atributos de los Web Forms 2.0 que ayer se nos quedaron en el tintero en la primera parte de este artículo dentro de la serie Introducción a HTML5.
Ayer hablábamos sobre la inclusión de los atributos placeholder, autofocus y autocomplete y de como usarlos en nuestros formularios de HTML5. También veíamos como definir una función en JavaScript que se encargara de averiguar si un elemento soporta esos atributos para poder ofrecer la misma experiencia de usuario a aquellos navegadores que no soportan aún la nueva especificación.
Para que no tengas que estar mirando el post anterior para recordar esa función voy a reproducirla en esta nueva entrada y entramos en materia con los nuevos atributos:
function elSupports(el, attr) {
var telement = document.createElement(el);
if (attr in telement) {
return true;
} else {
return false;
}
}Novedades II
Hoy vamos a hacer un repaso por más novedades de la nueva especificación en materia de formularios, apasionante sin duda.
Required
Uno de los usos más extendidos de JavaScript en la parte cliente ha sido (y es) sin duda la validación de formularios en el lado del cliente. No conozco ningún framework JavaScript que no incluya herramientas de validación de formularios.
La validación en el lado cliente es importante por que permite que un formulario no sea enviado si no es válido. Eso nos ahorra un consumo estéril de ancho de banda y sobre todo nos ofrece una salvaguarda del tiempo de nuestros usuarios que son informados de inmediato de que algún campo del formulario no cumple los requisitos.
Una de las tareas de validación más extendidas es la de los campos requeridos. La nueva especificación de HTML5 incluye un atributo booleano llamado required que nos sirve para definir si un campo es requerido o no:
<label for="username">Su nombre de usuario</label>
<input id="username" name="username" type="text" required/>El código anterior debe de prevenir a los navegadores que soporten la nueva especificación de enviar el formulario si el campo requerido no ha sido rellenado. No son muchos los navegadores que actualmente soportan esa funcionalidad. ¿Será el tuyo uno de los que si?, vamos a comprobarlo:
Si al pulsar el botón enviar ves un mensaje que dice “¡¡¡ENVIADO!!!“ significa que tu navegador aún no soporta la nueva funcionalidad, no pasa nada, siempre podremos cubrirla con nuestro viejo amigo JavaScript:
if (!elSupports(‘input’, ‘required’)) { // Un monton de brillante código JavaScript que emule la funcionalidad
}
Chromium lo soporta pero el bocadillo que encierra el mensaje de “Campo requerido” es feo con avaricia.
NOTA: Es un error grave de seguridad el validar los formularios únicamente desde el lado del cliente, es imprescindible además, validar los formularios (y cualquier entrada de datos en general) en el backend.
Datalist y List
En esta ocasión vamos a revisar un nuevo elemento y un atributo. El nuevo elemento datalist nos permite realizar una tarea que durante muchos años hemos realizado con JavaScript. Se trata de un híbrido entre un elemento input normal y un elemento select.
Usando el atributo list con nuestros elementos input podemos especificar una lista de opciones en él:
<label for="diasemana">¿Que día de la semana es hoy?</label>
<input type="text" name="diasemana" id="diasemana" list="dias"/>
<datalist id="dias">
<option value="Lunes" />
<option value="Martes" />
<option value="Miércoles" />
<option value="Jueves" />
<option value="Viernes" />
<option value="Sábado" />
<option value="Domingo" />
</datalist>
Esto permite al usuario seleccionar un valor de la lista o escribir uno que no esté en ella. Es lo que en la mayoría de frameworks de JavaScript con soporte para elementos de formulario se viene a llamar Combo Boxes. Veamos si lo soporta nuestro navegador:
Mi Chromium 12.0.742.91 no tiene ni idea de lo que es un datalist ni de lo que el atributo list significa. ¿Y tu navegador?. En Google se han dado un montón de prisa en soportar etiquetas como video, canvas y audio pero esto que mejora la usabilidad y la experiencia de usuario está un poco olvidado, en fin.
Tipos de input nuevos
La nueva especificación viene cargadita de nuevos tipos de inputs. La función para comprobar si un navegador soporta o no los nuevos tipos es un poco diferente a la que hemos estado usando hasta ahora:
function inputSupports(tipo) {
var input = document.createElement('input');
input.setAttribute('type', tipo);
if (input.type == 'text') {
return false;
} else {
return true;
}
}Por lo que podemos usarlo de la siguiente forma:
if (!inputSupports('range')) {
// Codigo JavaScript "super guai" que hace un monton de cosas
}Search
Un elemento de tipo search es prácticamente igual que un elemento de tipo text pero con la diferencia de que el nuevo tipo search tiene un aspecto mucho más consistente con su misión final que no es otra que la de la búsqueda:
<label for="busqueda">Búsqueda</label>
<input type="search" name="busqueda" id="busqueda" />También podemos añadir un histórico de búsquedas al elemento utilizando para ello el atributo results:
<label for="busqueda2">Búsqueda con histórico</label>
<input type="search" name="busqueda2" id="busqueda2" results="5"/>¿Y que tal soporta mi navegador este nuevo tipo de input? te estarás preguntando… vamos a comprobarlo:
NOTA: Para comprobar la búsqueda sin histórico debes escribir algo en la caja.
Aunque en mi Chromium funciona, la verdad es que en Safari tiene un aspecto estupendo.
Detalles de contacto
La nueva especificación añade tres nuevos tipos de valores para los detalles de contacto específicamente: correo electrónico, sitios web y números de teléfono:
<label for="correo">Correo electrónico</label>
<input id="correo" name="correo" type="email" />
<label for="website">Sitio web</label>
<input id="website" name="website" type="url" />
<label for="telefono">Número de teléfono</label>
<input id="telefono" name="telefono" type="tel" />¿Y soportará esto nuestro navegador?:
En esta ocasión nuestro navegador los mostrará como campos de texto normal, pero si tienes un smart phone a mano con un navegador que soporte HTML5 carga esta página para ver el resultado. En Safari del iPhone el teclado cambia si el foco está en uno u otro input:
Sliders
Ostias, ¿ese no era el de las tortugas ninja?, no, ese era Splinter. La mayoría de las librerías JavaScript que vienen con elementos pre construidos para formularios incluyen un slider que no es ni más ni menos que un tirador para fijar normalmente valores numéricos entre un máximo y un mínimo pre establecidos. Para ello utilizamos el nuevo tipo range:
<label for="cantidad">¿Cuanto?</label>
<input id="cantidad" name="cantidad" type="range" />El elemento asume unos límites de cero a cien por defecto. Por supuesto podemos especificarlos de forma explícita usando los atributos min y max:
<label for="cantidad">¿Cuanto?</label>
<input id="cantidad" name="cantidad" type="range" min="1" max="10" />¿Y que tal soporta nuestro navegador estos nuevos tipos?. Vamos a verlo:
Pues en mi Chromium va bien, pero el elemento es más feo que un mono matao a pellizcos, en Opera es mucho más bonito oiga.
Spinners
¡Este si que es el de las tortugas ninja!. Pues no, se parece si, pero la rata esa era Splinter que ya te lo he dicho antes. Un spinner es un tipo de entrada numérica que puede incrementar o disminuir su valor a través de unos controles situados en su lado derecho. Otra vez más, muchos son los frameworks JavaScript que incluyen este elemento para su uso:
<label for="numero">¿Cuanto?</label>
<input id="numero" name="numero" type="number" min="5" max="25" />El tipo de input number es una especie de híbrido entre text y range y además queda muy bonito. ¿Lo soportará nuestro navegador?. A ver…:
De nuevo Chromium lo soporta sin problemas, y en esta ocasión, el elemento no es tan feo como el range.
Calendarios: Fecha y hora
Una de las funcionalidades más populares de todos y cada uno de los frameworks JavaScript en el mercado es sin duda la del tipo de campo de selección timesheet o calendar o timedata o como demonios haya querido el framework de nombrar a un tipo de campo que cuando lo seleccionamos nos aparece un precioso calendario interactivo donde podemos seleccionar una fecha (y una hora en algunos casos). Como no podía ser de otro modo, lo que es popular, llega al estándar.
HTML5 introduce todo un rango de nuevos tipos relacionados con la selección de fechas y horas:
-
datese usa para fijar año, mes y día -
datetimese usa para fijar año, mes, día, hora, minuto, segundos e información del timezone -
datetime-localpara lo mismo que el anterior pero sin la información del timezone -
timese usa para fijar la hora, minutos y segundos -
monthpara fijar el año y el mes pero sin el día -
weekse utiliza para fijar el número de semana del año (entre 1 y 53)
Usar este nuevo tipo de input es muy sencillo:
<label for="calendario">Fecha de inicio</label>
<input id="calendario" name="calendario" type="date" />¿Y que tal soporta esto nuestros navegadores?. Pues ni idea, vamos a verlo:
Pues parece que Chromium lo soporta de maravilla pero nos están dando gato por liebre, por que en lugar de un calendario fantástico y maravilloso como el de Safari y Opera, en Chromium es un spinner pero feo feo que te deja aumentar o disminuir la fecha.
Selectores de color
Perdonad pero este es una pasada a todos los niveles. Un elemento nativo para seleccionar colores es algo que jamás me hubiese imaginado que entraría nunca en el estándar, pero mira tú ahí esta el tio en proceso de estandarizado:
<label for="awesome">Colorcillo</label>
<input id="awesome" name="awesome" type="color" />Esto no puede ser real te estas repitiendo en tu cabeza, pues si, mira:
Chromium lo soporta y hace validación del campo pero como pasa con el caso anterior, aún no provee de una interfaz elegante para seleccionar el color. Sin embargo Opera 11.11 si lo soporta.
Patrones
Para concluir vamos a ver un atributo que puede ser usado para validar la entrada del usuario. Este es el atributo pattern que admite una expresión regular contra la que validar la entrada del usuario:
<label for="cp">Código Postal</label>
<input id="cp" name="cp" pattern="[\d]{5}(-[\d]{4})" />¿Y esto como irá en nuestro navegador:
En chromium esto funciona pero tenemos el mismo problema que con el atributo required el bocadillo es bastante feo.
Conclusión
No es necesario explicar los beneficios de disponer de controles nativos como los descritos hasta ahora, el único problema es que de momento no se les puede aplicar un estilo CSS al menos hasta que el grupo de trabajo dedicado a ese módulo no avance en su trabajo y los navegadores vayan implementando esta funcionalidad.
En la siguiente entrega de la serie hablaremos sobre la web semántica y las novedades que la nueva especificación añade en ese contexto.
En Genbeta Dev | Introducción a HTML5
