Advertencia
Algunas de las "técnicas" analizadas a continuación son totalmente incorrectas, otras son obsoletas y el resto simplemente inadecuadas. Es posible encontrar manuales sobre diseño web donde se describe su utilización, y todas ellas están tan extendidas que prácticamente se han convertido en clásicos. El objetivo de este taller no es enmendar errores ajenos, sino dar alternativas.
<a href="JavaScript:PeasoDeFuncion()">
El atributo href debe especificar un URI válido, lo cual no se cumple en este código tan incorrecto como largamente utilizado. Dejando a un lado la discusión sobre la necesidad de utilizar un vínculo para lanzar un script, lo cierto es que este esquema provoca errores en aquellos agentes de usuario que no ejecutan scripts (bien por no contar con esa funcionalidad o porque el usuario lo ha desactivado) e incluso en otros con soporte para scripts pero que interpretan el valor del atributo href de forma estricta.
La manera correcta de lanzar un script es utilizar los atributos de evento, aplicables a cualquier elemento, no sólo a los elementos a: onfocus, onblur, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown y onkeyup:
Código HTML:
<a href="alternativa.html" onclick="Funcion(); return false;">
En el ejemplo anterior, se cuenta con una página, llamada alternativa.html, que se cargará sólo si no se puede ejecutar la sentencia javascript especificada en el atributo onclick. Observemos que el script debe devolver un valor false al ejecutarse, para que quede anulado el vínculo original. Este modelo es muy aconsejable, sobre todo si el script abre una nueva ventana con otro documento, una práctica muy común. En ese caso el atributo href apuntaría al mismo documento:
Código HTML:
<a href="documento.html" onclick="window.open('documento.html', 'Ventana', 'scrollbars=yes,status=yes,width=320,height=240'); return false;">
Los scripts pueden fallar, sobre todo aquellos que se basan no sólo en la especificación ECMA o que incluyen extensiones propietarias. Por ello no sería mala idea modificar el caso del primer ejemplo para conseguir que la función nos devuelva true si el script no ha funcionado satisfactoriamente, y que sea ese valor el que anule o no la acción:
Código HTML:
<a href="alternativa.html" onclick="return Funcion();">
<form action="mailto:micorreo@loquesea.sera">
Este modo de manejar formularios se ha hecho muy popular, debido a su simplicidad (no hay que instalar y configurar ningún script ni programa) y a que no requiere absolutamente nada en el servidor (la mayoría de los servidores gratuitos no admite la ejecución de programas, en especial de aquellos que generan tráfico de correo). Pero el comportamiento de los navegadores ante un atributo action que no especifica un recurso accesible a través de la red es indefinido. Al margen de esta razón, que podría catalogarse de purista, existen otros inconvenientes que desaconsejan esta práctica:
- Para que el proceso comience, el navegador debe identificar cuál es el programa de correo (de existir), y el usuario debe tener configurada una cuenta de correo.
- Aunque se cumplan las premisas anteriores, probablemente el navegador mostrará un mensaje de alerta, para hacer constar que el envío del formulario delatará la dirección de correo electrónico del usuario. Es fácil que el usuario decida cancelar la acción en ese momento.
- En cualquier caso, no es posible averiguar qué ha pasado realmente, por lo cual no se pueden establecer mecanismos que sigan al envío, ni tan siquiera la típica página que da las gracias o informa sobre el envío de los datos, por no hablar ya de procesos más complejos. En otras palabras: se pierde el control sobre el formulario.
- No sólo la privacidad del usuario queda comprometida. La dirección de correo que actúe como recipiente del formulario queda expuesta a los "robots caza-direcciones" de las empresas dedicadas al spam.
La alternativa correcta es, por supuesto, el uso de algún recurso en el lado del servidor. Es totalmente seguro, independiente del lado del usuario y con incontables opciones para el proceso de datos, más allá del simple almacenamiento en un buzón de correo. Existen multitud de scripts libres para manejar formularios, por ejemplo: FormMail o PHPformMail. Aún en el caso de no contar con un servidor que los admita se puede optar por un servicio externo, y también los hay gratuitos, como los de MelodySoft, Response-O-Matic o Freedback. Y si no se quieren perder cinco minutos en darse de alta en uno de esos servicios, la opción más recomendable y transparente que queda es, directamente, pedirle al visitante que mande los datos por e-mail. Viene a sor lo mismo que el mailto:, pero al menos no hay engaños de por medio.
<a target="_blank"...
La especificación HTML admite el atributo target únicamente en documentos que hacen uso de marcos. No obstante, también es utilizado en páginas normales para conseguir que los enlaces se abran en una ventana diferente. Hay que tener en cuenta que eso no tiene sentido en ciertos dispositivos o programas, y también que, en cierto modo, debería ser el usuario el que tuviera el control sobre el destino de los vínculos. Por otra parte, en ciertas ocasiones es más cómodo mantener una ventana con la página origen de los enlaces. En cualquier caso, es bastante sencillo conseguir el mismo efecto sin utilizar el citado atributo:
Código HTML:
<a href="destino.html" onclick="window.open(this.href);return false;">
Aunque los navegadores ofrecen la posibilidad de abrir cualquier enlace en otra ventana, sin necesidad de que el autor se haya tomado ninguna molestia, se pueden crear mecanismos en la propia página para que el usuario escoja.
El primer ejemplo es una opción bastante simple.
<i><b><font color="#8080F0" size="2" face="Arial">
Durante los últimos años, una de las labores del W3C ha sido la de liberar al lenguaje HTML de todos aquellos elementos y atributos sin entidad estructural, entre los que están font, basefont, u, s, bgcolor, align o center. Esto supone limpiar el contenido de todos aquellos fragmentos que sólo especifican un modo de presentación (por regla general gráfica) dejando esa labor a otras tecnologías complementarias como CSS, con muchas más posibilidades y garantías. Comparadas con las numerosas opciones de formato de las hojas de estilo, las restringidas posibilidades de las versiones obsoletas de HTML son paupérrimas. Mediante la utilización de declaraciones muy sencillas podemos establecer tamaños de fuente más exactos, decoración, márgenes, espaciado, interlineado, sangrías, colores, bordes, fondos, etc. y todo ello de una manera más sistemática: una simple declaración puede sustituir a cientos de etiquetas font. También nos permite utilizar los elementos de una manera más lógica, olvidándonos de otras técnicas peregrinas, como el uso de blockquote para sangrar un texto o de textarea para dotar de barras de desplazamiento a un bloque.
La implementación correcta de una hoja de estilos también obliga, en cierto modo, a mantener una buena estructura en el documento HTML. Pero su mal uso, en especial la definición desmesurada de clases sin una estructura previa de selectores, puede provocar el efecto contrario, lo cual debe llamarnos la atención sobre la necesidad de mantener una jerarquía lógica dentro del documento (encabezados, párrafos, listas, etc.).
Si los inconvenientes de elementos como font no han quedado patentes, todavía hay más ventajas en el uso de CSS. Las hojas de estilo pueden combinarse, activarse fácilmente y no requieren ningún cambio en el contenido del documento. También permiten un equilibrio entre el diseño del autor, las posibilidades del navegador y las preferencias del usuario. Además, un único archivo puede definir limpiamente el formato de todas las páginas de un sitio, con el consiguiente ahorro de trabajo. El ejemplo del siguiente apartado, dedicado a las tablas, ofrece una prueba simple de todo ello.
<table><tr><td><table><tr><td><table><tr><td>...
En el anterior taller ya se experimentó con ejemplos de maquetación sin usar tablas. Pero ahora nos referiremos al tema desde otro punto de vista. El uso de tablas no es, por supuesto, intrínsecamente incorrecto. De hecho, dada la desigual implementación del nivel 2 de CSS, puede ser la salida más sencilla. Pero esto no significa cometer los siguientes errores:
- No estructurar adecuadamente el contenido. El uso de tablas no debe ser un impedimento para seguir manteniendo un esquema coherente de encabezados, párrafos. etc.
- Sacrificar el orden de contenidos por culpa de la estructura de la tabla. Lo más recomendable es adaptar el flujo de celdas al del contenido. El anidamiento múltiple y la combinación de celdas dificultan enormemente esa tarea.
- Utilizar celdas con el único propósito de dar formato: establecer márgenes, líneas, fondos, etc.. Todo ello se puede lograr, con mejores resultados, utilizando hojas de estilo.
Como ya establecía Occam, la solución más simple es, probablemente, la correcta. El uso indiscriminido de elementos de tabla complica progresivamente la edición o actualización del sitio, al quedar el contenido sepultado bajo toneladas de etiquetas. Y si hablamos de utilizar editores wysiwyg las tablas pueden llegar a tomar vida propia y actuar de forma inescrutable.
En este apartado se incluyen dos ejemplos extremos, que también ilustran los problemas expresados en el apartado anterior. Son dos versiones de una misma página (imaginaria, por supuesto), utilizando tablas y formato dentro del HTML (es decir, la manera "clásica"), y usando los dos niveles de CSS (formato y posicionamiento). En el segundo, el código ha quedado reducido a poco más de la mitad (pero ha ganado un mundo en claridad), se han eliminado las ocho tablas, y los 19 elementos img ornamentales también han sido desechados en favor del uso de CSS. No obstante, siempre se podía haber llegado a una solución más sencilla y conservadora, utilizando un esquema simple de tabla.
Ver ejemplo "clásico" · Ver ejemplo "CSS2" · Ver código del ejemplo "clásico" · Ver código del ejemplo "CSS2".
<noframes>¡Qué pena! Su navegador no soporta frames</noframes>
A estas alturas de la película, cuando los marcos son ya algo obsoleto en lugar de una novedad, ese aviso carece por completo de sentido. Los problemas de los marcos como tales ya se explicaron en el debate 2, pero este apartado está dedicado exclusivamente al elemento noframes, el cual está concebido para dotar al documento de un contenido alternativo, ni más ni menos.
Hoy por hoy podemos asegurar que aquellos usuarios que utilizan navegadores incapaces de representar marcos ya lo saben, no tiene demasiado sentido recordárselo, y tampoco es de recibo sugerirle que cambie de programa. También es posible que el contenido del elemento en cuestión sea procesado por un robot, como ocurre con ciertos buscadores. En este caso el típico mensaje tiene menos sentido aún, es un texto inservible.
Por todo ello, lo lógico es incluir información útil dentro del elemento noframes, la cual puede estructurarse normalmente, como si de un elemento body se tratase. Una descripción del sitio, y un conjunto de vínculos a las páginas que lo componen es quizás la opción más correcta.