Labels.js: Una Re-Introducción a DHTML
Diciembre 23, 2001
Aclaración
Existe confusión en relación con el propósito de DHTML estos días. Dado que todo el mundo tiene una opinión diferente sobre dónde debe ser utilizado, dónde no debe serlo, y porqué o porqué no.
Yo también tengo una opinión.
Creo que los arquitectos de la web concibieron el DOM (el corazón de DHTML) para ser utilizado para realzar la estructura y la utilidad de los documentos XHTML. No para competir con Flash. No para construir juegos con él. Seguramente no para crear sitios enteros ejecutándolo. DHTML se diseña para ser justo otra capa de realce encima de la base de HTML. Como CSS, pero más divertido.
No existen demasiados ejemplos de este tipo de DHTML ahí fuera en la red ahora mismo, por lo tanto, vamos a ponernos a ello con uno nuevo.
Etiquetas
Creo que todo el mundo está bastante familiarizado con esas pequeñas etiquetas tan lindas para campos de formulario que se han hecho tan populares recientemente. El modo en el que trabajan consiste en que la etiqueta para el campo de formulario ("username" por ejemplo) está dentro del campo donde se supone que tienes que teclear el nombre de usuario. Cuando situas el foco en el campo, la etiqueta se "quita" para que puedas teclear. Ycuando se abandona el foco, si nada ha sido tecleado, la etiqueta vuelve. Algo parecido a esto. y esto. Ahorra espacio, tiene buen aspecto, y y da sensación de astucia.
Pero pensemos en ello. La forma en que estas etiquetas ("labels") han sido tradicionalmente implementadas es algo similar a la siguiente:
<input type="text" name="username" value="username"
onfocus="if (this.value == 'username') this.value = '';"
onblur="if (this.value == '') this.value = 'username';" />
Si el agente del usuario no soporta JavaScript, o si el usuario lo ha desabilitado, estas etiquetas elemento del formulario no funcionarán. No será totalmente inutilizable, sino que no trabajará del todo correctamente. Además, hay una buena ocasión para cualquiera que vaya a enviar "username" al formulario. Vaya una tontería.
¿Por qué no usar el modo de XHTML de construir
los elementos 'label' de un formulario? El elemento
<label>, que es raramente bien utilizado sirve para
enlazar lógicamente un elemento de un formulario con su
etiqueta. Sería algo como esto:
<label for="txtUsername">Username</label>
<input id="txtUsername" name="username" type="text" />
El único resultado apreciable de hacer esto en en la mayoría de navegadores es que un click en la etiqueta de la Interfaz de Usuario(UI)-activa el elemento. De cualquier manera, crea una diferencia no visual enorme en nuestra aplicación DHTML . Ahora, los datos que necesitamos — el texto de la etiqueta ('label') — es parte de la estructura del documento. Si queremos construir nuestro script en la cima de esta estructura lógica, podemos tener la certeza razonable deque siempre degradará estado utilizable. Y eso es una Cosa Buena.
Labels.js es un script que escribí con una tonelada de
empuje e inspiración de
Paul Sowden basado en esta idea.
Primero esconde todos los elementos label, y usa su atributo
for para rellenar las relativas cajas de texto con
etiquetas. Entonces, fija un escuchador de eventos ("event
listener") al campo para controlar la aparición y
desaparición del texto. Incluso maneja cajas de
contraseñas (campos input).
Haz click aquí para ver una demostración de Labels.js.
Aunque simple, Labels.js es un ejemplo de mi script ideal de DHTML , y un ejemplo de lo que creo que el W3C tenía en mente para el DOM. Algunas de las metas de diseño que alcanza son:
- Diseño completamente modular. Labels.js utiliza los escuchadores de eventos exclusivamente para evitar interferencias con cualquier otro script o funcionalidad. No requiere ninguna inicialización especial, y no modifica su entorno.
- Se inutiliza a sí mismo, antes de que la página se descarge con lo que una etiqueta nunca va a ser enviada como el valor de un campo de formulario a un proceso del servidor. Esto es consistente con la idea de completa modularizabilidad.
- Construido sobre el DOM. En lugar de usar sus propias y complejas jerarquías de objetos, Labels.js es esencialmente código pegamento para poner juntas las funcionalidades existentes en el DOM.
- No requiere ninguna información extra sobre presentación o comportamiento más allá de la que está presente en el XHTML subyacente.
- Degrada graciosamente a sus componentes estructurales: una etiqueta ("label") y una caja de texto(" textbox").
Ideales
Hay toneladas de buenas razones para escribir DHTML de este modo. Tu código es compatible hacia delante y hacia atrás. Cualquier usuario con cualquier dispositivo será capaz de usar tu aplicación. Tu código es completamente modular, "black-box", y fácilmente actualizable . Y hey, puedes machacar a la gente en la cabeza con el hecho de que eres más moderno que ellos. Y eso siempre es divertido.
Pero si ninguna de estas razones te convence realmente, hazlo por la razón que yo lo hago: Hazlo por El AmorTM. Esto hará que te sientas mejor . Es irrefutable que, solamente-un-programador-que-conoce-los-sentimientos, sigue el camino que optimiza-hasta-la-caida-del-amanecer. El hecho de que un documento pueda tener múltiples etiquetas de presentación y comportamiento opcional, pero siempre nos lleve al mismo significado lógico es letalmente sexy, y no hay que darle más vueltas.
Y si tú subscribes lo que ocurre en la web es nuestra historia actual, entonces separar comportamiento de contenido es una responsabilidad con la que cumplir. Esto dará a futuros usuarios flexibilidad para modificarlo si tú no lo haces.
El Futuro
En el mundo del encantamiento de DHTML, Labels.js no va a crear convulsiones. Estoy enterado de ello. Pero ese no es el tema. DHTML está diseñado para aumentar la funcionabilidad de XHTML en muchos pequeños caminos, creo. Aquí y allí, precisamente haciendo que los navegadores se comporten mejor.
Aquí hay algunas cosas que creo que podrían hacer a los navegadores mejores. Algunas más complejas que otras.
- un grupo compacto de scripts para formularios. Cuando selecciones un botón radio a), todos los campos del formulario serán relativos a a) se volverán activos. Otros campos de formulario se deshabilitarán.
- una caja combinada ("combo box").
- una interfaz con pestañas-"tabs"- (las pestañas son cabeceras, las áreas de las pestañas son divisiones?).
- un script para un menú drop-down hecho completamente fuera de listas desordenadas y anidadas y elementos anchor.
- un script que pudiese ser aplicado al código xhtml anterior para convertirlo en un menú de árbol expandible/colapsable en lugar de un menú drop-down.
Por lo que vamos a hacerlo. Y hacédmelo saber cuando
hagais algo guay, útil, o sexy.