Diseñorama » Articulos

DHTML no intrusivo

Escrito por Sergi en 2.12.04

Primero nos centraremos en la teoría y comentaremos los ejemplos al final, cuando ya tendremos una base teórica suficiente. La finalidad no es explicar la sintaxis del lenguaje y sus posibilidades, sinó cómo usarlo para crear páginas web usables, accesibles y que sigan los estándares.

¿De qué va todo esto? (definiciones chapuceras )

HTML

Lenguaje de marcado para la estructuración de información en la web. Si os fijais no digo nada sobre cómo debe presentarse esa información, puesto que eso lo trataremos más adelante

XML

Lenguaje de marcado para la estructuración de metadatos. No solo se consigue saber qué información tenemos sino también qué es cada cosa, puesto que las etiquetas se definen a priori

XHTML

Lenguaje basicamente igual al HTML pero con unas especificaciones que permiten ampliarlo como el XML (pudiendo definir etiquetas propias)

CSS

Lenguaje para la representación de los estilos de una página (aquí es donde definiremos los colores de los textos, posiciones de los bloques, etc.) no solamente a nivel de pantalla, también por impresora, dispositivos braille, etc.

Javascript

Lenguaje para interactuar con el usuario, validar formularios en el lado cliente, crear elementos al vuelo, etc.

Nodo

Los nodos son la representación de los elementos de la página en una especie de árbol jerárquico, algo así como un arbol genealógico de elementos que van descendiendo de otros elementos. Debemos saber que un nodo no tiene por qué ser un elemento, ya que tenemos más tipos de nodos, que especifican si es un elemento, un texto, una sección CDATA, etc

DOM

Define la estructura lógica de los documentos HTML y XML y el modo en que se accede y manipulan sus nodos. Aunque es un conjunto de librerías independiente del lenguaje solemos hablar de DOM refiriendonos a las rutinas Javascript que nos permiten manipular nodos HTML.

DHTML

Combinación de Javascript, CSS y DOM para modificar documentos web.

Como vemos cada lenguaje tiene su utilidad y lo que intentaremos en este artículo es aprender a separar sus usos para obtener documentos mejor estructurados y más correctos, con lo cual además ganaremos otras cualidades

Objetivo de una web

Lo importante en la mayoría de webs es el contenido, la información. Cómo se presente es algo secundario. Debemos pues asegurarnos que esa información llegue a todos los usuarios. Tenemos que dejar de pensar en páginas web para PC o Mac y empezar a pensar que hay mucha gente que accede a los contenidos a través de multitud de plataformas de conexión a internet diferentes, como teléfonos móviles, PDA's, WebTV, etc. Incluso si aceptamos los PC como los instrumentos más utilizados nos encontramos con una gran variedad de navegadores, aparte de los conocidos Explorer, Netscape y Opera, pues existen entre otros, navegadores de texto como Lynx o navegadores de voz como el de IBM. Así pues debemos tratar de proporcionar una accesibilidad del 100% a nuestras páginas, no solamente a los discapacitados sinó a aquellas personas que acceden a internet a través de distintos dispositivos a los habituales. Siguiendo los estándares nos aseguramos que la información estará accesible también para futuras plataformas, navegadores, dispositivos, etc.

Accesibilidad no es Usabilidad

Hemos hablado de la accesibilidad como una meta a seguir para que la información pueda ser leida por cualquier dispositivo de conexión a internet. No debemos confundir el térmimo con usabilidad, que podríamos asociar más a la experiencia que tiene el usuario al utilizar la página (facilidad para navegar por el menú, encontrar una buena disposición de elementos en la pantalla, etc). De todas maneras, una página accesible probablemente sea más usable que una página no accesible, pero no necesariamente. Lo que sí es seguro es que una página accesible se indexará mucho mejor en los buscadores, con las ventajas que eso conlleva, aunque ese no es el tema que nos ocupa.

La simplicidad y la cebolla

Partiendo de la accesibilidad como una meta, vamos a modificar la metáfora de Owen Briggs sobre el código de una web y una cebolla. Mirémoslo de otro modo imaginando el concepto de teléfono. Lo importante de un teléfono es que cualquier persona pueda descolgarlo, marcar un número y tener una conversación con otra persona. El color o el hecho de que tenga más o menos funciones o una agenda mayor es lo de menos, y son cosas independientes. Si lo portamos al concepto web, la información, a la que todos los usuarios deben tener acceso, sería el teléfono. Cualquier otra cosa no debería aparecer en la estructura del HTML. A medida que añadimos complejidad en la construcción de la página lo hacemos de manera que cada tipo de información complementaria sea tratada como un añadido pero sea prescindible. Si el usuario no puede interpretar cualquiera de las "capas" añadidas, por lo menos puede leer la información básica, el nucleo de la página. Vamos a extender el concepto con dos ejemplos.

La presentación debe ser tratada por las hojas de estilo, y por lo tanto, debe ir asociada a archivos .css para separar realmente el contenido de la presentación. Por esa razón ningún elemento crítico debe depender de la correcta visualización de un color, por poner un ejemplo, puesto que usuarios daltónicos o simplemente con navegadores que no entiendan las hojas de estilo estarán recibiendo una información incorrecta. De este concepto hay mucha información en la red y bibliografía suficiente como para poder afirmar que se ha dado un gran paso hacia la correcta separación de la estructura y presentación. Es lo que comunmente se define como la nueva corriente de los "estándares" y un poco mas allá, la maquetación sin tablas ("tableless"). Básicamente se trata de usar el HTML (o el XHTML) para definir la estructura de la página lo más semánticamente posible (cada etiqueta para lo que sirve) y el CSS para definir la presentación tanto en pantalla como en distintos dispositivos (print, braille, etc).

Los usuarios que naveguen en Mozilla o FireFox tienen a su disposición dos extensiones para desarrolladores llamadas Developer Toolbar o PNH Toolbar. Son muy similares. Si estás leyendo esto asumo que en cierto modo te interesa la programación de páginas web, así que te aconsejo te instales cualquiera de ellas porque te ahorrarán mucho trabajo. Una de las opciones que vereis es que puede deshabilitar los estilos de una página con un solo botón. Esto nos permitirá ver en funcionamiento la filosofía explicada más arriba, si la estructura y el estilo están separados, deshabilitando el estilo tendremos una página html básica pero totalmente funcional. Un paso más allá podemos aplicar distintas hojas de estilos a la misma página, como en la famosa csszengarden, donde cada autor proporciona una hoja de estilos distinta sobre la misma estructura HTML. Es decir, la misma información, distinta presentación.

Lo mismo pasa a nivel de la capa de "comportamiento". Este será el tema principal de este artículo (sí, después de todo este rollo empieza el artículo), pero a modo de introducción teórica diremos que esta capa es una simple mejora de la experiencia del usuario, como un añadido al contenido y la presentación. Al igual que los estilos deben ir separados del contenido, el comportamiento de los elementos de una página también debe ser separado de la estructura de la misma.

Si volvemos al ejemplo del teléfono, el javascript sería una tercera capa, además de la capa estilos y la capa nucleo. Por ejemplo permitiría usarlo en "modo manos libres", y al igual que el CSS, debería ser prescindible (da igual de qué color sea el teléfono mientras me permita hacer llamadas). De este modo, sin el uso de esta tecnología una página debería ser accesible y navegable. Si el navegador no sabe interpretar el código simplemente no lo ejecutará pero los contenidos seguirán siendo accesibles. Esto es lo que se conoce como degradación del script. Este concepto lo desarrollaremos más adelante cuando hablemos de DHTML no intrusivo.

Ejemplos de mal uso de Javascript

Un ejemplo muy claro es el uso del protocolo javascript: en los enlaces para realizar ventanas emergentes (los famosos popup).

<a href="javascript:popup(pagina.html)">pagina</a>

Si el navegador no entiende javascript no podrá navegar la web y por tanto la accesibilidad es cero. Un cambio muy fácil sería algo del estilo:

<a href="pagina.html" onclick="popup(this.href);return false">pagina</a>

En este caso si el navegador no entiende el onclick seguirá el enlace del href y podrá continuar la navegación. La función popup en realidad haría un window.open con sus atributos opcionales. El return false; evita que al abrir el popup además se siga el enlace del href. Os aconsejo la lectura de un excelente artículo sobre cómo hacer popups por el maestro Aaron Boodman.

Otro ejemplo flagrante es el mal uso del método document.write. En la mayoria de los casos este metodo se usa para generar contenidos, ya sean textos del tipo "hola, hoy es lunes bienvenido a mi web" o casos más preocupantes como la generación de menús de navegación jerárquicos. Como podeis imaginaros, si el navegador no soporta javascript, el menú no aparece en pantalla y por tanto no podemos navegar por la web: de nuevo accesibilidad cero. Para arreglar este caso nos basaremos en listas. Las listas son unos elementos definidos por el lenguaje HTML precisamente para eso, mostrar listas de cosas, en este caso enlaces para navegar. El hecho de que queramos que se muestren en árbol no significa que no tengamos que hacer un buen uso de ellas. O incluso podemos usar solamente CSS para darles estilo.

Creación de una página web accesible

Ahora vamos a ver los pasos a seguir para programar una página sencilla usando este concepto.

1. Creación del contenido: estructura de la página web añadiendo cada tipo de información en sus etiquetas adecuadas (usando H1-H6 para títulos, P para textos dentro de párrafos, etc). No añadiremos imágenes espaciadoras, etiquetas font, etc. Mostrar ejemplo de contenido en un popup
2. Validación del código en el W3C: es importante, más que por validar la página en sí, porque algunos scripts pueden funcionar incorrectamente si la página no está bien formada (etiquetas mal cerradas, etc).
3. Asignar estilos a los elementos: según hemos explicado anteriormente, el aspecto del documento debe asignarse mediante hojas de estilo externas para separar al máximo contenido y presentación. Aquí definiremos la separación entre párrafos, los colores, márgenes, etc. Mostrar ejemplo de asignación de estilos en un popup
4. Usar javascript para mejorar la usabilidad: los 3 primeros puntos son una mera introducción a la metodología de programación de páginas web estándares, aunque no voy a incidir más en ello porque hay suficiente documentación al respecto en la red gracias a la "moda tableless". En cambio desarrollaremos extensamente este apartado en el siguiente punto.

DHTML no intrusivo

Ya entrando en materia, ¿qué hace que un código sea no intrusivo?

1. Mezcla con la estructura: principalmente, que no se mezcla el contenido de la página con el comportamiento del script. Esto significa que no habrá eventos intrinsecos en el documento y además que el script estará situado en un archvo .js aparte. Más de uno podría argumentar que la especificación de HTML define atributos que permiten asociar acciones (ejecutar funciones) al producirse ciertos eventos (eventos intrínsecos) sobre los elementos de una página (ejemplo: onclick). En mi opinión debe evitarse al máximo el uso de esos atributos en el HTML porque no dejan de ser una mezcla de conceptos, pero también porque añaden una complejidad innecesaria al HTML y hace que los archivos sean más pesados y las rutinas menos reusables.
2. Compatibilidad: los navegadores que no entiendan el código deben prescindir de él sin devolver mensajes de error.
3. Detección de capacidades: para que lo anterior suceda usaremos detección de objetos en lugar de detección de navegadores. Solamente en algunos casos deberemos usar detección de navegadores cuando sabemos muy bien que cierto navegador no sigue los estándares o que una de sus betas no se ajusta al funcionamiento normal.
4. Inicialización: lo ideal es que el script se inicialice automaticamente al cargar la página y que su inicio no interfiera con otras posibles acciones a realizar en ese momento.
5. Asignar acciones con un manejador de eventos: puesto que hemos evitado el uso de eventos intrinsecos vamos a necesitar algun método para asociar acciones (ejecutar funciones) a eventos capturados por distintos elementos de una página

Ahora veremos unos ejemplos explicados, especialmente cómo mostrar y esconder capas eficientemente, validar formularios y generar menús a partir de listas de enlaces (menús de opciones, desplegables, etc). Aunque vamos a tocar bastante código no revisaremos todas las lineas de un script, solamente unas pinceladas para explicar el proceso de creación usando ejemplos prácticos.

Presentación de casos prácticos

Veamos cómo podemos visualizar esto de una manera menos indigesta. Antes hemos visto dos o tres ejemplos del mal uso del javascript. Ahora que tenemos una idea aproximada de la filosofía que vamos a seguir, pasemos a presentar un par de ejemplos. Aunque vamos a tocar algo del código, no lo haremos de forma extensiva, solamente unas pinceladas para ver en código lo que hemos explicado más arriba. Por tanto no es imprescindible para seguir los ejemplos, pero sería bueno que tuvieseis nociones básicas de cómo manipular nodos con el DOM. Si no es el caso podeis leer la Introducción al Modelo de Objetos de Documento (DOM) de Mike Hall traducida por mi colega Pedro Palazón. También sería recomendable alguna noción de qué es y cómo se usa la encapsulación de código para evitar sobreescribir funciones y variables de otros scripts. Os podeis leer una introducción algo avanzada sobre herencia y programación orientada a objetos en f(m).

Mostrar y esconder secciones de una página

Vamos a empezar por este ejemplo y así de paso mejoramos la usabilidad de esta web. Hasta ahora aquí se realizaba el truco de mostrar o esconder los comentarios y el formulario de la siguiente forma:

1. Primero la hoja de estilos se encargaba de esconder esas dos secciones con un display:none
2. El documento contenía un par de enlaces con el simple fin de poder ejecutar un javascript para mostrar o esconder el bloque siguiente. Pero los enlaces estaban vacíos.
3. Y había un script que se ejecutaba en navegadores "actuales" (soportan el DOM en cierta medida, como el document.getElementById) de manera que el enlace llamaba a una función que se encargaba de mostrar o esconder la sección correspondiente a través de un id

Esto representa un error de cálculo: en navegadores que entienden el css pero tienen el js desactivado no se puede acceder a esas dos secciones de la página. De hecho a mi me ha pasado cuando navegaba sin js. En estos casos lo mejor es usar js para añadir toda la funcionalidad, así solamente dependemos de una tecnología.

A partir de la misma página del ejemplo anterior vamos a añadir un pequeño script para mejorar la usabilidad. Mostrar ejemplo de la primera mejora en un popup

Mostrar y esconder al detalle

Partiendo del listado de características que mencionamos en el artículo anterior iremos viendo cómo hemos solventado el problema:

1. Mezcla con la estructura. Como veis, solamente he añadido un archivo js pero el resto del html sigue intacto, así que no hemos mezclado la estructura del documento con su capa de comportamiento.
2. Compatibilidad. Los navegadores que no entienden el script simplemente lo ignoran. Esto se consigue con la última linea del código:

   if (document.getElementsByTagName) ...

3. Detección de capacidades. Fijaos que no hemos detectado qué navegador tiene el usuario, simplemente si entiende el uso del DOM.
4. Inicialización. En esa misma linea, después de la primera comprobación tenemos la asignación del evento onload:

   window.onload = TOGGLE.start;

   Lo que hace es decirle al script que cuando la página haya cargado completamente ejecute la función TOGGLE.start. Atención a dos cosas importantes. No hemos añadido los típicos paréntesis al nombre de la función porque en ese caso la función se hubiese ejecutado al leer la linea. Aquí solamente hemos asignado un evento, no ejecutado la función. Esta forma de hacerlo tiene su peligro, y es que si ya hay otro evento onload el anterior se sobreescribe (muy típico en la mayoría de scripts que vereis online). Esta parte la solucionaremos más adelante, quería mostrarlo para destacar ese fallo.
5. Asignar acciones con un manejador de eventos. Como en el html no hay ningún onclick en ningún elemento, vamos a necesitar algún método para ejecutar la función de mostrar o esconder elementos de la página. La función TOGGLE.start básicamente busca todos los elementos de la página que tengan una clase llamada "toggle" y guarda su referencia en un vector llamado togglers. Realmente este método de asociar elementos de la página con un script es mucho más elegante que ir añadiendo eventos en el html, puesto que solamente necesitamos una clase en cada elemento que debe interactuar. Vereis que para cada comportamiento vamos a asignar una clase distinta (que será detectada por su script particular; en este caso, toggle). Para cada elemento que tiene una clase "toggle" (usamos un bucle para recorrer el vector) se detecta el elemento justo anterior a ese usando el DOM:

   var box = togglers[i].previousSibling;
   

   Luego se ejecuta otra función llamada TOGGLE.prepare que pasa como parámetros la referencia a la capa que debe esconderse y el elemento anterior que actuará como "enlace". Para ello se añade un evento onclick que llamará a TOGGLE.run al hacer click sobre él. También se cambia el aspecto del cursor cuando pasa por encima del elemento, para imitar un enlace. La tercera función realiza la acción de mostrar o esconder la sección dependiendo de si está actualmente visible o no, cambiando el display de block a none y el texto del "enlace" según sea el caso. En realidad no hemos usado un manejador de eventos, pero aquí no hacía falta complicarse, y de paso vemos otra manera de asignarlos. La desventaja de hacerlo de este modo es que si luego queremos eliminar el evento onclick deberíamos sobreescribirlo para dejarlo vacío. De nuevo, quería mostrarlo para destacar esta característica.

Validación de formulario

La validación por javascript suele ser el típico ejemplo del mal uso de esta tecnología. Normalmente se usa el javascript de manera que el formulario solamente se puede enviar a través de una función de validación, con lo cual volvemos a lo de siempre, si el usuario no tiene javascript activado o su navegador no entiende esa validación, no podrá hacer uso del formulario. Y si estamos hablando de un banco o de una tienda online eso significa dinero perdido.

Lo ideal es validar por javascript pero sin requerir su uso, añadiendo los eventos necesarios si el navegador los soporta. Aunque solo sea por seguridad es aconsejable validar los datos en servidor de nuevo, así que la validación en cliente sería solamente para saber si los datos obligatorios están presentes y tienen el formato adecuado. Esto puede parecer una pérdida de tiempo, pero es lo más efectivo. La validación por javascript suele aplicarse en el 90% de los casos, evitando así peticiones innecesarias al servidor, pero aun quedarían casos donde fuese necesario validar los datos en el servidor, de modo que se pueden aceptar todas las peticiones y además se pueden validar de un modo u otro.

Podeis ver un ejemplo de cómo interpreto esta metodología en la segunda mejora de nuestro ejemplo básico en un popup. El html sigue siendo el mismo, pero si os fijais en el código del formulario no vereis ni una sola instrucción javascript en el html. Por lo tanto hemos conseguido separar la estructura del comportamiento, como hemos explicado anteriormente. ¿Cómo añadimos la funcionalidad? Veamos.

Validación de formulario al detalle

Como ya es el segundo script que usamos en la misma página y tenemos algunas funciones comunes, vamos a separar algunas de ellas en un archivo externo (extras.js, en el cual he añadido también un espacio CSS para calcular estilos de un nodo, que usaremos más adelante). Asimismo, como tendremos que inicializar dos funciones sería aconsejable cambiar el método de añadir el evento onload. En este caso vamos a usar un manejador de eventos (EXTRAS.addEvent), en lugar del anterior window.onload = TOGGLE.start, de este modo podemos inicializar los dos mecanismos sin problemas (uno al final de cada archivo javascript):

EXTRAS.addEvent(window, 'load', TOGGLE.start, false);
. . .
EXTRAS.addEvent(window, 'load', VALID.start, false);

Lo primero que nos tiene que llamar la atención es el uso de un nombre de función similar (start). Si no hubiésemos encapsulado las funciones de cada script en un espacio propio (TOGGLE y VALID) ahora tendríamos un conflicto de nombres.

El método start hace básicamente lo siguiente: añade un evento onsubmit a los formularios de la página, que ejecutará una comprobación VALID.checkForm al enviar el formulario. También recopila en un vector todos los textarea e input de tipo texto de la página y les añade un evento onblur de manera que ejecutarán una función al salir del campo.

Esa VALID.bluring en realidad llama a una función mayor que chequea si es obligatorio o no al salir del campo, buscando si hay una clase "required" en su label asociado. Dependiendo del valor del campo cambiará el fondo del label para mostrar un icono de alerta o de aceptación, y en caso de que el error sea en el formato del campo mostrará una alerta.

Ya solo nos queda explicar VALID.checkForm, que comprueba que todos los campos obligatorios estén llenos y tengan el formato adecuado. Si es así nos deja enviar el formulario usando el return true y si no lo es muestra una alerta explicando qué campos deben llenarse aun y deniega el envío forzando un return false.

Menu estilo combo usando listas

Ahora que ya tenemos una filosofía establecida y un poco de práctica con la técnica de añadir dhtml de forma no intrusiva, vamos a realizar un menú tipo combo usando una lista de enlaces. Veamos el ejemplo simplificado sin estilos. La parte que nos importa es la siguiente:

<div class="selmenu">
	<h2 class="selmenutitulo">Escoje tu opción</h2>
	<ul class="selmenulista">
		<li> <a href="1.html">Uno</a></li>
		<li> <a href="2.html">Dos</a></li>
		<li> <a href="3.html">Tres</a></li>
	</ul>
</div>

Como vemos usamos una lista para presentar los enlaces. Sea cual sea el navegador podremos utilizar la navegación. Pero eso es muy feo, así que vamos a darle algo de estilo.

Sigue siendo algo pobre, aunque se puede mejorar no solo el estilo sinó también cómo se comporta el menú. Añadiremos algo de dhtml para imitar el efecto combo.

Menu estilo combo al detalle

En el html hemos estructurado cada menú de manera que tenemos una capa con la clase "selmenu", que contiene un título con la clase "selmenutitol" y una lista con la clase "selmenulist". De nuevo inicializamos el script añadiendo un evento onload que ejecutará SELMENU.prepare. Esa función se encarga de buscar en la página todos los elementos con una clase llamada "selmenu". Para cada uno de ellos (pueden haber muchos menus) buscamos su título y su lista de enlaces. Luego recorremos esa lista de este modo:

var enlaces = menu.getElementsByTagName("A");
for (var a = 0; a < enlaces.length; a++) {
	enlaces[a].style.display = "block";
	enlaces[a].style.width = "100%";
}

Nótese el uso de menu.getElementsByTagName("A") en lugar de document.getElementsByTagName("A") para acotar el nodo en el cual queremos buscar enlaces. El bucle nos permite simular que cada enlace ocupe todo el ancho de la caja, como en los elementos de un combo. Después ejecutamos SELMENU.run, que se encarga de varias cosas. Primero añade una imagen de fondo al título, para imitar la flecha de expandir el combo. Para finalizar añade dos eventos inline a cada menú, onmouseover y onmouseout, que mostrarán o esconderán los enlaces al pasar el ratón por el título del "combo":

menu.onmouseover = function(){
	enlaces.style.display = "block";
	menu.style.zIndex = z+5555;
}
menu.onmouseout = function(){
	enlaces.style.display = "none";
	menu.style.zIndex = z;
}

Como veis, el detalle final es forzar el menú para que se muestre por encima de todos los demás elementos, aumentando su z-index. Luego dejamos su z-index intacto al esconderlo.

Despedida y cierre

Creo que con esto podemos terminar, os he dado unas cuantas pautas que podemos resumir en estos puntos:

• Definiciones de los términos usados
• Nociones de accesibilidad y usabilidad
• Filosofía de separación del contenido, el diseño y el comportamiento
• Pasos a seguir para programar DHTML de forma no intrusiva
• Ejemplos prácticos

Nos hemos dejado muchos ejemplos, como podrían ser la creación de menus jerárquicos a partir de listas de enlaces, tablas de contenidos a partir de las secciones de la página, ordenación dinámica de tablas, extraer las citas de una página, etc. Las posibilidades son infinitas. Espero que os haya gustado y que a partir de ahora vayais inventando nuevas maneras de aplicar estos conceptos en vuestros proyectos.

Enlaces Relacionados

No puedes utilizar este artículo con fines comerciales, mientras que las condiciones de uso de los ejemplos son más flexibles.

Comentarios

1. 3 diciembre 2004, 12:26Nelson Rodríguez-Peña

   Felicitaciones por tan exhaustivo artículo, estoy recién comenzando a leerlo, definitivamente hay que darle más tiempo.
   
   Para complementar el ejemplo de JavaScript, creo que falta un detalle: agregar el evento onkeypressed para asegurar el acceso vía teclado alternativamente al mouse:
   
   pagina
   

2. 3 diciembre 2004, 14:36Stan

   Excelente tutorial, debere leerlo con atencion para poder aplicarlo… estaria bueno eso que menciona el comentario de arriba sobre el teclado… un saludo. Excelente Web.
   

3. 18 diciembre 2004, 02:00fael

   magnífico tutorial como siempre.
   
   saludos
   

4. 29 diciembre 2004, 23:25Dolores

   Exelente post, realmene quede impesionada y le pido permiso para usarlo en el aprendizaje de mi sobrino, asi lee y le queda claro y del propio tambien.
   Felicitaciones.
   Cambieo mi link allli se lo deje.
   Feliz año nuevo
   

5. 23 enero 2005, 05:48Raspu

   Muy bueno el artículo, ya he empezado a tomar en consideración muchos de los tratamientos que se mencionan.
   
   Pero me gustaria agregar algo. Mencionabas que era mejor utilizar directamente javascript para iniciar con ciertos elementos de la pagina ocultos (por ejemplo este formulario) en vez de hacerlo con CSS, por si el browser tenia javascript desactivado (si escondes por defecto el formulario con CSS dicho usuario no tendria acceso a el).
   
   Referente a eso mencionabas tu caso con el menu de Monolinea.com En el caso de los menues desplegables habria que tener algo mas en consideracion y voy a tomar como ejemplo justamente el menu de Monolinea:
   
   Si los submenues los escondieras por defecto con javascript en vez de CSS (como está actualmente) y si desactivo javascript en mi navegador igual tendré acceso a esos submenues ya que no quedarán escondidos por defecto. Sin embargo, es posible que al estar todos visibles pudiesen desarmar el diseño de la pagina (no se si será el caso de monolinea, pero a simple vista me pareciera que sí podría encontrase con algun conflicto, como que se monten los submenues y hacerlos ilegibles).
   
   Bajo esa particular situacion tal vez lo recomendable seria esto para monolinea:
   
   En el caso del boton curriculum lo tienes linkeado con un ”#”, y si desactivo javascript no podré ver los submenues. Pero si ese boton lo tuvieras linkeado a una de las subsecciones de tu curriculum (por ejemplo “experiencia”) y en esta subseccion tuvieras links al resto de tu curriculum, aun con javascript desactivado permitirias el acceso a la info de tu curriculum.
   
   ¿Se entiende?
   
   
   

6. 27 enero 2005, 19:22Kemie

   Hola Raspu,
   En efecto, mis menus de Monolinea son un pésimo ejemplo de menú, de los dias oscuros antes de que el Maestro Sergi me hiciera ver la luz. Para la proxima actualización de monolinea lo tengo ya contemplado :). (Por cierto, no se si hay una pequeña confusión, porque el autor del artículo es Sergi, y no yo).
   

7. 28 enero 2005, 02:34Raspu

   Tienes toda la razón con lo de Sergi. De hecho, hace poco nomás que me di cuenta que los artículos eran de varios autores, no solamente tuyos :P
   
   Le devuelvo los c´reditos de autoría a Sergi jajajaj.
   

8. 19 febrero 2005, 02:02Carlos

   hola Sergi,
   
   acabo de leer esto en A List Apart, en referencia al uso de una clase “required” para indicar que un campo de un formulario es obligatorio:
   
   “In my opinion, the class attribute should only be used for CSS. Classes are XHTML’s primary triggers for the presentation layer, and making them carry behavior information, too, confuses the issue. Triggering both layers from the class attribute violates the separation of behavior and presentation, though in the end this remains an issue you have to take your own decision on.”
   
   
   ¿es adecuado ese uso del atributo “class” para indicar información que no es relativa a la presentación?
   
   saludos y enhorabuena por el artículo, está muy interesante.
   

9. 23 febrero 2005, 05:51Sergi

   En realidad, siendo muy puristas, lo que comenta ppk es cierto. Lo que pasa es que de algún modo hay que decirle a la capa behaviour (al script) qué campos son obligatorios. De momento, como él dice, solamente nos queda decidir si podemos vivir son ese sacrilegio de darle un atributo al HTML que contenga información sobre el comportamiento.
   
   Estoy buscando un link que puede ser interesante, si lo encuentro lo subo y os explico algo más.
   

10. 26 marzo 2005, 14:05Antonio

    Solamente gracias y felicitaciones
    

11. 9 junio 2005, 10:17NOLY

    SABES ME PARECE MUY INTERESANTE TU PAGINA ME GUSTARIA QUE SUBIERAS TODOS LOS TIPOS DE ESTILOS QUE UTILIZA DHTML
    

12. 29 septiembre 2005, 00:33miketrix

    Super bueno el artículo. Mis sinceras felicitaciones.
    

13. 26 junio 2006, 00:11juan

    RESUPER BUENO ESTE ARTICULO REXVERE SALUDOS A LOS CREDORES DE ESTA PAGINA

14. 31 agosto 2006, 15:36fernando

    mis requete felijitaciones a ejta pagina de nahualotes

15. 28 enero 2007, 01:48Gabriel

    Hola: he leído todos tus artículos y me han sido de mucha utilidad, ya que me gusta actualizarme e innovar.
    Ahora estoy detrás del AJAX y un poco de prototype.
    Con respecto a esto: estoy haciendo pruebas con el AJax y te tengo una consulta:
    Quise implementar un formulario como el que explicas en el ejemplo 4 de DHTML no intrusivo, y la página la llamo con AJAX. el tema es que no me hace ningún tipo de validación ni nada, pero esta página si la llamo de modo tradicional si funciona.
    Tienes idea de xq? la llamada al script está (por las dudas) en las 2 páginas, tanto la que realiza la llamada al Ajax como la que contiene el formulario.

    Espero tu respuesta: desde ya muchas gracias

16. 6 febrero 2007, 15:35Sergi

    Hola Gabriel, pueden ser mil cosas, sin mas pistas…

17. 19 agosto 2008, 16:01Joey Aguirre

    nisus sorty tysonite microbeless rightfulness nomeidae cadaveric leprosied
    <a href= http://www.lutheran-hymnal.com/organbook/organbuchlein.htm >J. S. Bach’s Organbuchlein (Little Organ Book)</a> http://www.kumo.it/BeOS/
    <a href= http://www.usask.ca/psychology/sarty/rasc/starparty.html >Saskatchewan Summer Star Party – 2001</a> http://imdb.com/title/tt0056757/
    <a href= http://p095.ezboard.com/bendemoniadaswarboard >Endemoniada’s Warboard</a> http://www.brightlightsfilm.com/31/hk_johnwoo.html
    <a href= http://www.soccerstreaming.co.uk/ >SoccerStreaming</a> http://www.nqcontent.com