Repensando formas en HTML5

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

Si bien hay muchos cambios para mejor en la especificación de HTML5, no hay mejor momento para el dinero para el sitio web impulsado por datos que la transformación de formularios. Estos simples cambios transformarán la manera de ingresar, validar, procesar e incluso visualizar entradas. Podrá crear aplicaciones web más útiles con menos código y menos confusión.

Introducción ¿Qué hay en la tienda?

"En el pasado reciente, la mayoría de las innovaciones en las formas provienen del uso de JavaScript, en lugar de HTML antiguo. Si bien no hay nada de malo con el uso de JavaScript para mejorar formularios, sí trae su propia usabilidad junto con muchos problemas de desarrollo."

HTML 5 todavía está experimentando cambios antes de que se finalice. Si observa las especificaciones, verá que todavía hay una última convocatoria de comentarios junto con las declaraciones, por ejemplo, los Implementadores deben tener en cuenta que esta especificación no es estable. Además, particularmente para los propósitos de este tutorial, centrándose en los cambios a los formularios, la implementación del navegador es irregular por decir lo menos. Dicho esto, vale la pena examinar los cambios en el horizonte de hoy. Si bien los cambios son de gran alcance, la implementación para los desarrolladores parece ser bastante fácil. En este tutorial, tomaremos una descripción general de alto nivel de estos innovadores cambios, y pensaremos en cómo afectarán la naturaleza de los comentarios de los usuarios.

En el pasado, los cambios en las formas han sido relativamente menores. Si vuelve a la especificación de HTML 3.2, que se finalizó en 1997, verá las mismas entradas de formulario básicas que utiliza en la actualidad. Select, textarea, radio, casillas de verificación y texto estaban disponibles entonces. Una generación de desarrolladores web creció escribiendo sobre estos mismos estándares. Si bien las versiones posteriores de la especificación generaron cambios en los formularios, como fieldset, etiqueta, leyenda y acciones de formulario como onsubmit o onchange, la forma en que manejamos la entrada del usuario ha permanecido algo estática. En el pasado reciente, la mayoría de las innovaciones en las formas provienen del uso de JavaScript, en lugar del antiguo HTML. Si bien no hay nada de malo con el uso de JavaScript para mejorar los formularios, trae su propia usabilidad junto con muchos problemas de desarrollo. Por ejemplo, hay muchas maneras diferentes en que podemos validar formularios usando JavaScript, pero ¿qué sucede cuando un usuario no tiene JavaScript habilitado? Además, tenemos que aplicar la lógica a nuestros scripts del lado del servidor. Al final, tenemos una forma no tan consistente de manejar la entrada del usuario. HTML 5 no aborda todos los dolores de cabeza por la innovación en los formularios en los últimos 13 años, pero nos brinda muchas herramientas para
hacer nuestro trabajo mucho más fácil, y nos permite producir formas mucho más consistentes.

Hay tres cambios básicos que debemos examinar. En primer lugar, veremos los cambios en los elementos de entrada, como autocompletar o autofoco. El segundo es cambios a los estados de entrada, ¡y hay bastantes! Finalmente, examinaremos los nuevos elementos de formulario. Es importante replantear que la especificación está en flujo; entonces no me sorprendería si, en el futuro, hay cambios sutiles en lo que estamos discutiendo. ¡Eso es lo que hace que esto sea divertido!

Cambios a los elementos de entrada: Un nuevo patio de juegos.

Los atributos de entrada son aquellos elementos que coloca en las entradas para explicar lo que está haciendo la entrada. Por ejemplo:

1	<input name="form_text" id="form_text" type="text" value="foo" size="10" maxlength="100">

En el ejemplo anterior, los atributos de entrada son value, size y maxlength. Estos han existido por bastante tiempo. HTML 5 no cambia el concepto de tener elementos de entrada, sino que agrega bastante más. Parece haber al menos una resta, o más bien sustitución, y ese es el cambio de deshabilitado ahora parece ser de solo lectura. La especificación no detalla el cambio, pero si fuera un apostador, el cambio permitiría que los manejadores de eventos, como onblur, disparen, lo que impide un elemento desactivado.

Los nuevos atributos incluyen autofoco, autocompletar, lista, requerido, múltiple, patrón, mínimo y máximo, paso y marcador de posición. Pienso en estos como dos sabores diferentes de elementos. El primer sabor mejora la experiencia para el usuario, mientras que el segundo mejora la experiencia de desarrollo. Lo que quiero decir con esto, es autofocus, autocompletar, list, multiple y placeholder ayuda a la experiencia del usuario en la selección de elementos, o tal vez dando una descripción de lo que busca el formulario, o ayudando a completar el formulario. Los patrones y pasos requeridos, mínimos y máximos se suman a la experiencia de desarrollo al decir lo que debería estar en la forma misma.

Enfoque automático

Lo que hace cada uno de estos nuevos atributos es relativamente fácil de entender. Por ejemplo:

1	<input name="form_text" id="form_text" type="text" value="foo" autofocus>

Arriba, el elemento de enfoque automático enfoca la entrada de texto en la carga de la página. Esto significa que tan pronto como se carga la página, esta entrada de texto está lista para tomar una entrada. Puede comenzar a escribir de inmediato, ya que este elemento tiene el foco del documento. Algo que solíamos hacer en JavaScript en una línea más o menos, ahora se puede hacer con una sola palabra.

1	<input name="form_text" id="form_text" type="text" value="foo" autocomplete="off">

En el ejemplo anterior, al desactivar la función de autocompletar, impide que el navegador complete el campo de formulario desde un valor anterior. Nada me molesta más que ver el número de mi tarjeta de crédito en un formulario tan pronto como escribo un dígito. El valor predeterminado para autocompletar es estar activado, por lo que la única vez que necesita usar este elemento es cuando desea evitar que el campo de formulario se complete desde entradas anteriores. Se agrega a la experiencia del usuario al evitar que la información sensible simplemente "aparezca".

Lista

    <input name="form_url" id="form_url" type="url" list="url_list">
    <datalist id="url_list">
        <option value="http://www.google.com" label="Google">
        <option value="http://www.nettuts.com" label="NetTuts">
    </datalist>

El atributo de lista es muy bueno. Esencialmente, proporciona un datalist y creará un menú desplegable a partir de su entrada de texto. Piense en ello como un auto natural completo. Lleve un poco más lejos, y en lugar de tener que agregar una biblioteca de JavaScript para una búsqueda rápida, basada en las entradas clave, podría simplemente agregar un controlador de eventos "onchange" con una publicación AJAX y terminar con un desplegable que se vuelve más específico a medida que el usuario escribe en el cuadro. Con HTML 5, esta funcionalidad se puede crear con solo unas pocas líneas.

Múltiple

1	<input name="form_url" id="form_url" type="url" list="url_list" multiple>

El atributo múltiple le permite seleccionar varios elementos de su datalist. Por ejemplo, es posible que tenga un formulario que envíe mensajes desde su sitio web. Al usar el elemento múltiple, puede permitir que el usuario seleccione múltiples destinatarios para enviar ese mensaje. Nuevamente, esto es algo que podemos lograr con un poco de JavaScript ahora, pero con HTML 5, solo tenemos que agregar un solo comando al formulario.

Placeholder

1	<input name="form_text" id="form_text" type="text" placeholder="Type Here">

El atributo placeholder es algo que hemos estado haciendo durante años con un toque de JavaScript. Lo que hace es que, tan pronto como la entrada esté enfocada, "Escriba aqui" se desvanecerá. Si no hubo ningún cambio en el texto sobre desenfoque, entonces Type Here volverá a aparecer. Una vez más, estamos quitando JavaScript de la imagen para mejorar la experiencia del usuario.

Necesario

Estos próximos nuevos atributos mejoran nuestro desarrollo. Con la excepción de "step," cada ayuda en la validación de la entrada del usuario.

1	<input name="form_text" id="form_text" type="text" value="foo" required>

El atributo requerido es exactamente como suena. Yo, el desarrollador de esta página web, le pido que complete este formulario antes de presionar Enviar. Esta es la validación de formulario básico que usamos hoy con JavaScript. Lo que tomó una biblioteca antes para agregar una entrada requerida, ahora toma una sola palabra en el formulario.

RegEx

1	<input name="form_text" id="form_text" type="text" value="foo" pattern="[0-9][A-Z]{3}">

De todos los nuevos atributos de forma, este es el que más me entusiasma. Sr. Form, déjeme presentarle a mi buen amigo, Regex. Así es, podemos validar las entradas de formularios basadas en expresiones regulares. Si bien este será desconcertante al principio, a medida que aprenda la expresión regular, las posibilidades de validación ahora se vuelven ilimitadas.

Validación

1	<input name="form_range" id="form_range" type="range" min="1" max="10" step=".5" value="5" >

He agrupado los tres últimos en un solo ejemplo, ya que todos se ocupan de la validación de números, o del rango de números que podemos incluir.

Min: es el valor mínimo que tendrá una entrada.
max: es el valor máximo de entrada que tomará la entrada.

Cada uno de estos trata de valores numéricos. No los confunda con maxlength, que trata con el número de caracteres que tomará una entrada. El elemento de paso es tal como suena. Cuando seleccione un valor numérico, increméntelo en .5 o hacia abajo en .5, lo que significa que este tipo de entrada tendrá los valores posibles de 1, 1.5, 2, 2.5, y así sucesivamente.

A partir de ahora, según mi leal saber y entender, el soporte del navegador es algo irregular en estos atributos. Aquí hay un gráfico rápido que muestra lo que pude encontrar en las implementaciones.

Cambios en los tipos de entrada: un montón de amor.

Hay ocho nuevos tipos de entrada, sin contar todos los nuevos tipos de fecha y hora, que para nuestros propósitos, estoy agrupando en uno. Es importante tener en cuenta que los navegadores que no han implementado los nuevos tipos de entrada se degradarán a un tipo de texto en cada uno de los que he probado. Lo que aportan los nuevos tipos de entrada es la capacidad de validar la entrada del usuario según el tipo que está utilizando. También hay más validación por venir que discutiré en las próximas dos secciones. Cada uno de los nuevos tipos de entrada nos permite separarnos de un campo de texto en algo más específico. Por ejemplo, para tomar valores enteros o flotantes antes de HTML 5, usamos principalmente un tipo de texto de entrada. Solo a partir de la anotación, es contrario a la intuición para principiantes. Al ser más específicos, tenemos un mejor control visual sobre nuestra interfaz, ya que cuanto más específico es el elemento en HTML, mayor es el control que tiene dentro del CSS, y más fácil es definir esos elementos visuales. Además, con los nuevos tipos de entrada específicos, los navegadores ahora pueden ajustar con precisión el rango de entrada. Finalmente, con el advenimiento de la informática móvil, podemos hacer que los elementos del formulario de la aplicación web se diseñen para que se vean como aplicaciones naturales, o pueden dar forma al teclado que estamos utilizando.

Veamos primero el manejo de números:

Números, enteros y flotantes

1	<input name="form_range" id="form_range" type="range" min="1" max="10" step=".5" value="5" >
2
3	<input name="form_number" id="form_number" type="number" min="1" max="10" >

Cada uno de estos tipos de entrada nos permite jugar con números, y cuando publicamos los formularios, debemos estar seguros de que tenemos esos valores flotantes para nuestro procesamiento del lado del servidor sin la validación de JavaScript añadida. En pocas palabras, para cada uno de estos tipos, esperamos volver a tener los números dentro del rango que definimos y con el paso que queremos. La diferencia entre los dos tipos es cómo se muestran. Mientras espero ver la implementación en el tipo de número, esperaría una tirada o un cuadro de texto, o posiblemente un tipo de selección con números. El tipo de rango es un poco diferente, en cuanto se parece a un valor deslizante, similar a lo que esperaría ver para un control de volumen.

Fechas y horarios

    <input name="form_date" id="form_date" type="date">

    <input name="form_month" id="form_month" type="month">

    <input name="form_week" id="form_week" type="week">

    <input name="form_time" id="form_time" type="time">

    <input name="form_datetime_local" id="form_datetime_local" type="datetime-local">

Otro gran alivio para estandarizar el desarrollo de su back-end es el nuevo tipo de entrada de fecha y hora. Desde la implementación de Opera que he visto, cada una muestra un menú desplegable de calendario, que le permite a su usuario seleccionar una fecha. De nuevo, podemos validar en nuestra página web que la entrada está en el formato que estamos esperando. Cada uno hace exactamente lo que pensarías; está seleccionando un mes, una semana, un día o una hora. El que es un poco diferente es el local de fecha y hora, que muestra la fecha y la hora sin el desplazamiento de la zona horaria. Por ejemplo, si está seleccionando un vuelo, el local de fecha y hora mostrará la hora y la fecha en la ciudad a la que se dirige, que no es necesariamente la zona horaria en la que se encuentra actualmente.

Urls, correos electrónicos, teléfono y color

    <input name="form_url" id="form_url" type="url" list="url_list">
    <datalist id="url_list">
        <option value="http://www.google.com" label="Google">
        <option value="http://net.tutsplus.com" label="NetTuts+">
    </datalist>

    <input name="form_email" id="form_email" type="email" list="email_list" multiple>
    <datalist id="url_list">
        <option value="jane.doe@test.com" label="Jane Doe">
        <option value="john.doe@test.com" label="John Doe">
    </datalist>

    <input name="form_telephone" id="form_telephone" type="telephone">

    <input name="form_color" id="form_color" type="color">

Cada uno de estos tipos de entrada es descriptivo. Los tipos de URL y correo electrónico tienen validaciones de patrones de URL válidos y patrones de correo electrónico válidos. Sin embargo, el teléfono no se ajusta a ningún patrón específico. Simplemente elimina los saltos de línea. Si desea aplicar un patrón de validación en el campo del teléfono, siempre puede usar el elemento de patrón. Cada uno de estos elementos menos color también tomará el atributo de lista, menos el color. El color es el bicho raro del grupo; Puedo ver su uso práctico, donde puedes seleccionar un color de un menú desplegable de lujo que muestra colores, y aplicar la entrada de texto de algo como # 000000, pero en realidad no se ajusta al resto de los cambios, en mi opinión. Es como jugar cuál no es como los demás.

Al igual que los atributos, la implementación del navegador de tipo de entrada es bastante irregular. Mi iPhone parece ser compatible con más de estos que Safari, que es un poco gracioso para mí. Esto es lo mejor que pude encontrar, como apoyo.

Cambios en los elementos del formulario: no tan drásticos

La cantidad de cambios en los elementos del formulario no es tan drástica como los atributos y tipos de entrada. Dicho esto, hay algunos elementos nuevos a tener en cuenta. Ya hemos cubierto el datalist, es la forma en que definimos qué se seleccionará de una llamada a un elemento de lista, pero no hemos visto keygen, output, progress o meter. Fuera de Keygen. estos no son tan auto explicativos como los nuevos atributos. Vamos a profundizar en estos solo un poco.

Keygen

1	<keygen name="key">

Este es un poco confuso No genera una clave pública para ti. En cambio, es un control de generador de par de claves. Una vez que se envía el formulario, empaqueta el par de claves para almacenar la clave privada en el almacén de claves local, y envía la clave pública de vuelta al servidor. Generará el certificado del cliente y lo ofrecerá al usuario para que lo descargue. Una vez descargado y almacenado con la clave privada, puede autenticar los servicios, como SSL o la autenticación por certificado.

Salida

1	<input name="number_1" type="number"> + <input name="number_2" type="number"> =
2	<output onforminput="value = number_1.valueAsNumber + number_2.valueAsNumber"></output>

Piense en el elemento de salida como un área de texto con esteroides. Lo que puede hacer es calcular a partir de dos entradas de texto de tipo de número y generar ese cálculo sin enviar el formulario de regreso al servidor. Si solo devuelve false onsubmit, en el ejemplo anterior, calculará number_1 plus number_2 y le proporcionará la respuesta. Como muchas de las cosas discutidas en este tutorial, esto es algo que podemos lograr hoy con JavaScript, pero esto realmente disminuye la cantidad de código que necesitamos escribir en el futuro.

Progreso y medidor

1	<progress id="p" max=100>0% </progress>
2
3	<meter min=0 max=20 value=12 optimum=10>12cm </meter>

Los dos últimos elementos nuevos son progreso y metro. Son similares, pero con una diferencia. El progreso está destinado a ser utilizado para medir el progreso de una tarea específica. Por ejemplo, si tiene que completar cinco páginas más antes de realizar una encuesta, mostrará el elemento de progreso en esa área. El medidor, por otro lado, es una medida de algo. Es posible que desee mostrar el espacio restante en el disco que le queda a un usuario. Utilizaría el medidor para mostrar esa medida. Hay nuevos elementos de límite, como bajo, alto y óptimo. Estos reemplazan los elementos mínimo o máximo; entonces, si los superan, se convierten en los nuevos límites inferior y superior de la forma.

Al igual que el resto de los cambios de formulario HTML 5, la implementación del navegador es deficiente en este momento. Aquí está lo que parece funcionar, y lo que no (en el momento de escribir esto).

Conclusión

Por lo que puedo ver, no hay ninguna razón para no comenzar a usar formularios HTML 5. Los elementos y tipos de entrada se degradan muy bien, incluso en IE6, donde se ignoran como elementos o se degradan a entradas de texto. Vamos a tener que esperar un tiempo para que los atributos de validación se hagan realidad, pero dicho esto, todavía hay algunos usos sin esas ventajas. Por ejemplo, el iPhone modifica el teclado si está usando tipos url, el correo electrónico o de números. El tipo de entrada de rango ya es compatible con los navegadores WebKit, por lo que podría ser el primer niño en el bloque con un control deslizante numérico que funciona sin JavaScript. La especificación está finalizando rápidamente, y los navegadores están alcanzando rápidamente los cambios de paradigma. ¡No hay tiempo como el presente para al menos comenzar a jugar con estos juguetes nuevos! ¿Qué piensas?