Creación de aplicaciones HTML5

Mejores formularios web con los formularios HTML5

Brandon Satrom

Descargar el ejemplo de código

Si usted se dedica al desarrollo web, probablemente creó un formulario HTML alguna vez. De hecho, puede que haya creado tantos que ni pueda recordarlos todos. Sin lugar a dudas, conocerá bien los tipos clásicos del elemento input como text, password, file, hidden, checkbox, radio, submit y button y es probable que haya usado la mayoría de estos en muchas ocasiones.

Si tuviera que decir cuál de todos estos tipos es el que más usa, probablemente respondería “text”, igual que la mayoría de nosotros. El tipo de entrada de texto es la herramienta de uso múltiple en el desarrollo clásico de los formularios HTML. Por un lado, es capaz de adaptarse a cualquier tarea que se le asigne, pero por el otro, es semánticamente neutro y, por lo tanto, el explorador no entrega ninguna ayuda para convertirlo en algo práctico. Para compensar esta carencia, los desarrolladores y diseñadores han agregado su propia semántica a estos elementos (mediante identificadores y nombres de clase) y se han apoyado en marcos y JavaScript en el servidor para procesar la validación y agregar interacciones más sofisticadas.

Un ejemplo clásico es la entrada de fechas en los campos de texto. Generalmente deseamos mejorar los campos para las fechas con algún tipo de selector de fechas. Para esto, frecuentemente escribimos una solución en JavaScript o empleamos un marco como jQuery UI, que agrega un comportamiento de interacción que permite al usuario seleccionar una fecha de un widget para rellenar el campo original con esa fecha.

Por muy útil que resulte este patrón, y como desarrolladores nos hemos vuelto expertos en patrones como este, hemos de repetirlo tantas veces, que no podemos dejar de preguntarnos: “¿por qué será que el explorador no puede hacerse cargo de esta tarea rutinaria?”

La buena noticia es que con los formularios HTML5 el explorador sí puede y sí se hará cargo. Aparte de text y de los pocos tipos existentes que hemos usado durante años, HTML5 agrega 13 nuevos valores para el atributo type del elemento input, además de un sinnúmero de otros atributos que permitirán acelerar el desarrollo de formularios. Este mes quiero compartir algunos de los nuevos tipos y atributos del elemento input que traen los formularios HTML5, además del estado de su implementación en varios exploradores. Luego, presentaré una descripción rápida de las nuevas características de validación del lado cliente de los formularios HTML5. Por último, echaré un vistazo a cómo las actualizaciones recientes de Visual Studio 2010 y Microsoft .NET Framework 4 permiten combinar elegantemente los formularios HTML5 con los formularios ASP.NET Web Forms. A lo largo del artículo mostraré cómo adoptar los formularios HTML5 en las aplicaciones de la actualidad y entregaré las soluciones de resguardo necesarias para los exploradores más antiguos. Todos los ejemplos de este artículo (que se encuentran disponibles en línea) fueron creados con WebMatrix, una herramienta gratuita y ligera para el desarrollo de web de Microsoft. Puede probar WebMatrix en aka.ms/webm.

Tipos nuevos para el elemento input en HTML5

Lo que conocemos hoy como formularios HTML5 o Web Forms HTML5 comenzó como Web Forms 2.0, una especificación previa a HTML5 que fue desarrollada por un grupo conocido como Web Hypertext Applications Technology Working Group (WHATWG). Gran parte del trabajo inicial de WHATWG se convirtió luego en el punto de partida de lo que ahora conocemos como HTML5. La iniciativa llamada Web Forms 2.0 ahora forma parte de la especificación oficial de HTML5, disponible en bit.ly/njrWvZ. Gran parte de la especificación está dedicada a los nuevos tipos y atributos de contenido del elemento input, el que podrá encontrar en bit.ly/pEdWFs.

Tal como mencioné recién, la especificación presenta 13 nuevos tipos para el elemento input en los formularios: search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range y color.

El uso de estos tipos nuevos es muy fácil. Supongamos que queremos poner un nuevo campo para correo electrónico en un formulario de pedido. Como podrá apreciar en la figura 1, modifiqué la página Pedido del sitio web de la plantilla Bakery de WebMatrix con algunos campos adicionales, uno de los cuales es para el correo electrónico.

A Sample Order FormFigura 1 Un formulario de pedido de muestra

Este es el marcado para el campo del correo electrónico de este formulario:

<input type="email" id="orderEmail" />

Observe que el atributo type es igual a “email” en vez de “text”. Lo mejor de los nuevos tipos de entrada HTML es que podemos usarlos hoy y que funcionan hasta cierto punto en todos los exploradores. Cuando un explorador encuentra uno de estos nuevos tipos se pueden producir dos situaciones.

Si el explorador no es compatible con los tipos nuevos, entonces no reconocerá la declaración. En este caso, el explorador se adaptará en forma completamente limpia y tratará el elemento como si fuera type=“text”. Para probarlo, solo tiene que poner este elemento en un formulario y escribir “document.getElementById(‘orderEmail’).type” en la Consola de herramientas F12 de Internet Explorer 9. Por lo tanto, podemos usar estos tipos nuevos hoy mismo y si el explorador no reconoce un campo determinado, este seguirá funcionando como un campo de texto corriente.

Sin embargo, cuando el explorador reconoce el tipo, su uso nos proporciona beneficios inmediatos. En el caso de los tipos reconocidos, el explorador agrega algunos comportamientos específicos para los diferentes tipos. En el caso del tipo email, Internet Explorer 10 Platform Preview 2 (PP2) y posterior validarán automáticamente cualquier entrada y presentarán un mensaje de error al usuario si el valor proporcionado no es una dirección de correo electrónico válida, tal como puede observar en la figura 2.

Automatic Browser Validation of the Email Input Type
Figura 2 Validación automática del tipo de entrada de correo electrónico en el explorador

Como el tipo permite deducir fácilmente el propósito y el comportamiento de cada elemento, hemos obtenido sin dificultad un nuevo nivel de riqueza semántica en los formularios. Es más, algunos de estos nuevos tipos de entrada permiten que el explorador proporcione interacciones más sofisticadas de manera nativa. Por ejemplo, si pongo el siguiente elemento en un formulario y luego abro ese formulario en un explorador que es totalmente compatible con el tipo de entrada de fecha, entonces obtengo una interacción predeterminada mucho más sofisticada que en el caso del cuadro de texto regular:

<input type="date" id="deliveryDate" />

En la figura 3 puede ver lo que Opera 11.5 logra hacer con el tipo de fecha. Lo mejor es que para conseguir esta interacción no tuve que hacer más que escribir type=“date” y el explorador se encargó de todo el trabajo que antes tenía que realizar manualmente en JavaScript para ofrecer una funcionalidad similar.

The Date Input Type in Opera 11.5
Figura 3 El tipo de entrada de fecha en Opera 11.5

Es importante hacer notar que la especificación de HTML5 no dicta cómo los exploradores deben presentar estos nuevos tipos de entrada ni cómo deben presentar los errores de validación. Por lo tanto, resulta probable que podamos encontrarnos con diferencias sutiles o grandes entre los diferentes exploradores. Chrome 13, por ejemplo, presenta un control numérico para la fecha en vez de un selector de fechas, como puede observar en la figura 4 (lo que, por supuesto, ya puede haber cambiado para cuando usted lea esta columna). También conviene mencionar que en el World Wide Web Consortium (o W3C) se mantiene un debate acerca de la aplicación de estilos y la localización de los elementos como datetime, date y color en los exploradores. Por ahora los exploradores no se ponen de acuerdo sobre cómo implementar estos tipos, y en las implementaciones existentes no hay ningún mecanismo de personalización que se parezca a lo que entrega jQuery UI. Al implementar estos tipos nuevos o experimentar con ellos, siempre tenemos que asegurarnos de proporcionar una solución sólida de resguardo. Además, si la coherencia en la presentación y el comportamiento es importante para los usuarios, entonces probablemente tendremos que aplicar estilos personalizados, invalidar los comportamientos predeterminados en esos controles o usar una solución que emplee scripts.

The Date Input Type in Chrome 13
Figura 4 El tipo de entrada de fecha en Chrome 13

Anteriormente afirmé que estos campos se siguen comportando como campos de texto corrientes y, por lo tanto, el explorador nos proporciona una manera sencilla de lograr una degradación estable. Pero un campo de fecha implementado en un cuadro de texto simple resulta tosco y se considera comúnmente como una experiencia del usuario insatisfactoria. Con un poco de ayuda de Modernizr y jQuery UI, sin embargo, podemos entregar una solución que reúne lo mejor de los formularios de HTML5 con una buena solución de resguardo.

Recordará de mi último artículo (msdn.microsoft.com/magazine/hh394148) que Modernizr (modernizr.com) es una biblioteca para JavaScript que permite detectar si los exploradores reconocen las características nuevas de HTML5. En este ejemplo quiero emplear Modernizr para detectar la compatibilidad con el tipo de entrada de fecha de HTML5 y, en caso negativo, usar el widget datepicker de jQuery UI (jqueryui.com) para proporcionar una experiencia de usuario similar. Después de descargar y agregar las referencias para Modernizr, jQuery y jQuery UI, puedo agregar la solución de resguardo para los elementos de fecha con unas pocas líneas de código:

if (!Modernizr.inputtypes.date) {
  $("input[type=date]").datepicker();
}

En la figura 5 puede observar el resultado final, tal como se ve en Internet Explorer 10 PP2.

Date Field Support with jQuery UI
Figura 5 Compatibilidad con el campo de fecha mediante jQuery UI

Nuevos atributos de contenido del elemento input en HTML5

Además de los nuevos tipos de entrada, HTML5 también proporciona algunos atributos de contenido nuevos que podemos usar en los campos de entrada para validar los contenidos y proporcionar funcionalidades mejoradas. Uno de los atributos nuevos es “placeholder”, que de acuerdo con la especificación “…representa una sugerencia corta (una palabra o frase corta) destinada a ayudar en la entrada de datos” (énfasis en el original). Por ejemplo, puedo tomar algunos campos de nuestro formulario de pedido y agregar placeholder=“algún texto” en cada campo, para obtener el resultado que vemos en la figura 6:

<input type="email" id="orderEmail" placeholder="ex. name@domain.com" />
<input type="url" id="orderWebsite" placeholder="ex. http://www.domain.com" />

Using the Placeholder Attribute with Input Fields
Figura 6 El uso del atributo placeholder en los campos de entrada

El texto marcador de posición tiene un color más claro que el texto normal y, al ubicar el foco en el campo, el texto desaparece para que el usuario pueda escribir el valor.

Al igual que en los nuevos tipos de entrada, el atributo placeholder no es reconocido por los exploradores más antiguos. Pero como nada malo sucede si un usuario visita una página que lo contenga, conviene tomar en cuenta la posibilidad de comenzar a usarlo, incluso si no pretendemos agregar compatibilidad para los exploradores más antiguos. Y si deseamos agregar compatibilidad del tipo “polyfill” con los marcadores de posición, entonces Modernizr será de gran ayuda. Tal como mencioné en el último artículo, la buena gente de Modernizr trata de mantener un listado actualizado de todos los polyfill y resguardos imaginables para cada una de las características de HTML5. El listado completo se encuentra en bit.ly/nZW85d.

Para el siguiente ejemplo usaremos jQuery HTML5 Placeholder, creado por Mike Taylor, que está disponible en bit.ly/pp9V4s. Una vez instalado, debemos agregar lo siguiente a un bloque de script al que hace referencia la página:

Modernizr.load({
    test: Modernizr.input.placeholder,
    nope: "../js/html5placeholder.jquery.min.js",
    callback: function() {
      $('input[placeholder]').placeholder();
    }
  });

Aquí, Modernizr revisa si el explorador reconoce el atributo placeholder y, en caso negativo, carga html5placeholder.jquery.min.js. jQuery luego selecciona todos los elementos que tienen un atributo placeholder y agrega compatibilidad con el complemento a cada uno. Al probar este método en Internet Explorer 9 podemos comprobar que el resultado final se ve muy parecido al resultado que entrega Internet Explorer 10 PP2 en forma nativa.

Otro atributo nuevo interesante es “autofocus” que permite, tal como dice su nombre, establecer el foco en un campo determinado del formulario cuando se carga la página. Solo debe haber un campo por página con este atributo; cuando son varios elementos que establecen este atributo, entonces el primer elemento en declararlo recibirá el foco al cargar la página. En mi formulario de pedido quiero que el campo Name reciba el foco, por lo tanto, agrego el atributo del siguiente modo:

<input type="text" class="field" id="orderName" autofocus />

Podemos emplear el atributo autofocus con cualquier control de formulario y resulta ser una alternativa excelente a las estrategias basadas en scripts con las que los desarrolladores web nos hemos tenido que batir en el pasado al lidiar con los formularios.

Validación de los formularios HTML5

No cuento con el espacio necesario para abarcar todos los nuevos atributos interesantes, pero dedicaré un poco de tiempo a analizar “required”, “pattern”, “novalidate” y “formnovalidate”. Gracias a estos, podemos realizar en un dos por tres la validación del lado cliente de los formularios.

En el caso de los exploradores que lo reconocen, el atributo “required” indica que el formulario no se pude enviar sin un valor. Por ejemplo, si agrego “required” al campo Name de mi formulario de pedido:

<input type="text" class="field" id="orderName" required />

Cuando visito esta página en Internet Explorer 10 PP2 e intento enviar el formulario, veo algo parecido a lo que podemos apreciar en la figura 7. El uso de este simple atributo entrega al explorador toda la información necesaria para saber que debe representar el elemento con un borde rojo y mostrar un mensaje al usuario que explique que el campo es obligatorio.

Using the Required Attribute on a Form Field
Figura 7 Uso del atributo required en un campo del formulario

Previamente, en la figura 2 mostré cómo el explorador puede validar automáticamente determinados tipos, como por ejemplo “email” y “url”, sin ningún tipo de entrada adicional por parte del usuario. El atributo “pattern” nos permite proporcionar pruebas de validación personalizadas para los tipos de entrada. De acuerdo con la especificación de HTML5, “pattern” consiste en una expresión regular que el explorador puede emplear para validar el campo correspondiente.

Mi formulario de pedido contiene un campo de teléfono (type=“tel”) y puedo especificar un patrón de validación del siguiente modo:

<input type="tel" id="orderTelephone" pattern="\(\d\d\d\) \d\d\d\-\d\d\d\d" title="(xxx) xxx-xxxx" />

Esta expresión regular (no muy compleja) instruye al explorador que debe esperar un número de siete dígitos con el código de área entre paréntesis y un guion en el número local. Al escribir otra cosa, aparece el mensaje de la figura 8. Observe que el mensaje contiene instrucciones acerca del formato esperado: “(xxx) xxx-xxxx”. Como esta parte del mensaje proviene del atributo title del mismo elemento, nos entrega la oportunidad de controlar el mensaje de validación con el marcado, al menos en parte. Pero hay una cosa que debemos tener en cuenta al usar el atributo title como ayuda en la validación. De acuerdo con la especificación, el explorador también puede optar por mostrar el título en otros casos que no tienen relación con los errores; por lo tanto, este atributo no debe contener texto que suene de algún modo a error.

Using the Pattern Attribute to Specify a Validation Expression
Figura 8 Uso del atributo pattern para especificar una expresión de validación

La validación automática que proporciona el explorador está bien, pero hay dos preguntas que inmediatamente se vienen en mente. Primero: ¿qué sucede con los scripts para la validación del lado servidor o cliente que genera el marco de servidor (por ejemplo ASP.NET MVC)? Y segundo: ¿qué pasa cuando queremos permitir que el usuario guarde el formulario como trabajo en proceso, sin validarlo? La primera pregunta lamentablemente está fuera del alcance de este artículo, pero en mi blog escribí un artículo acerca de este tema en ASP.NET MVC (bit.ly/HTML5FormsAndMVC).

La segunda pregunta, por otro lado, es muy sencilla. Supongamos que tenemos un formulario que tomará bastante tiempo a los usuarios. Es posible que incluso tengan que guardarlo varias veces antes de enviarlo al servidor. En este tipo de casos, donde queremos permitir que el usuario pueda enviar un formulario sin validarlo, podemos usar dos atributos: “formnovalidate”, que se emplea en los campos de entrada del tipo “submit”, y “novalidate”, que se emplea en la etiqueta del formulario mismo. Aquí, defino dos campos para enviar el formulario, del siguiente modo:

<input type="submit" value="Place Order" />
<input type="submit" formnovalidate value="Save for Later" id="saveForLater" />

El atributo “formnovalidate” del segundo botón desactiva la validación y me permite guardar el trabajo en proceso del usuario en mi base de datos. Incluso lo puedo guardar del lado cliente, si empleo una de las nuevas tecnologías de almacenamiento de HTML5 como localStorage o IndexedDB.

Formularios de HTML y formularios ASP.NET Web Forms

Antes de finalizar el artículo, quiero compartir algunos detalles adicionales acerca de los formularios HTML5 para los desarrolladores de formularios ASP.NET Web Forms. Tengo buenas noticias para aquellos que pretenden desarrollar formularios HTML5 con ASP.NET Web Forms. Muchas de las actualizaciones de .NET y Visual Studio relacionadas con HTML5 se están publicando en forma paralela al ciclo de publicación normal y, por lo tanto, no hace falta esperar la siguiente versión del marco para usar estas características.

Para comenzar a trabajar con los formularios HTML5 y ASP.NET Web Forms, tendrá que descargar algunas actualizaciones. Asegúrese primero de tener Visual Studio 2010 SP1 (bit.ly/nQzsld). Además de la compatibilidad con algunos tipos de entrada y atributos nuevos de HTML5, el Service Pack también proporciona algunas actualizaciones que le permitirán usar los nuevos tipos de entrada de HTML5 en el control de servidor TextBox. Si no cuenta con esta actualización recibiría errores de tiempo de compilación al usar los nuevos tipos.

Probablemente también deberá descargar Microsoft .NET Framework 4 Reliability Update 1 (bit.ly/qOG7Ni). Esta actualización fue diseñada para solucionar algunos problemas relacionados con el uso de los nuevos tipos de entrada de HTML5 con los formularios ASP.NET Web Forms. En agosto Scott Hunter describió algunos de estos tipos (UpdatePanel, Validation Controls y Callbacks) en un artículo en su blog (bit.ly/qE7jLz).

La adición de compatibilidad de los formularios Web Forms con exploradores con HTML5 es una excelente noticia para todos los desarrolladores web. No solo nos proporcionan un conjunto de tipos de entrada semánticos que podemos aprovechar en nuestras aplicaciones, sino que además podemos usarlos hoy mismo sin efectos negativos en los exploradores más antiguos; simultáneamente, nos ofrecen funciones mejoradas en los exploradores más nuevos, incluida la validación automática del lado cliente. El uso inmediato de estos campos también entrega beneficios en el mundo de las aplicaciones móviles, donde el uso de tipos tales como “url” y “email” indica al dispositivo móvil que debe presentar al usuario un teclado en pantalla adaptado para ese tipo de entrada. Al combinar estas características nuevas con Modernizr y alguna de las excelentes alternativas de polyfill disponibles obtenemos todas las herramientas necesarias para adoptar los formularios de HTML5 ahora mismo en nuestras aplicaciones.

Visite ietestdrive.com para obtener más información sobre la compatibilidad de Internet Explorer 10 PP2 con los formularios HTML5 y consulte la guía para desarrolladores en el Centro para desarrolladores de Internet Explorer (bit.ly/r5xKhN). Si está interesado en un análisis más profundo sobre los formularios HTML5 en general, recomiendo el capítulo “A Form of Madness” del libro de Mark Pilgrim “HTML5: Up and Running” (O’Reilly Media, 2010), además de la sección sobre formularios en la especificación de HTML5 de W3C (bit.ly/nIKxfE).     

Brandon Satrom *se desempeña como desarrollador y evangelista de Microsoft en las afueras de Austin, Texas. Tiene un blog en userinexperience.com y lo puede encontrar en Twitter como @BrandonSatrom.*

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: *Jon BoxJohn HrvatinScott Hunter y *Clark Sell