tierra de nómadas - debates

A vueltas con los marcos

Evolución

Hay un problema de ritmo. Siempre lo hay. Si echamos un vistazo a la primera versión de HTML, se puede constatar que la situación actual ni siquiera se soñaba, al menos no en tan poco tiempo. De lo contrario, el elemento object hubiera formado parte de esa primera especificación (o a lo sumo de HTML 2.0), los elementos img, frame, applet o iframe nunca hubieran sido formulados, y esta discusión versaría únicamente sobre problemas de accesibilidad.

La rápida generalización de Internet como medio de masas ha obligado a ir adaptando el lenguaje a las nuevas necesidades. Así es como ocurren las cosas. De otra forma estaríamos todavía agrupándonos al anochecer alrededor de un fuego, pensando que las estrellas eran hogueras que protegían a otros grupos de nómadas. Pero la evolución incluye aciertos y errores, y como las cosas no suelen ser blancas o negras, todo tiene aspectos positivos y negativos. Y los marcos no van a ser menos.

Elementos reemplazados

Los elementos mencionados en el primer párrafo tienen una especial peculiaridad, que pasa desapercibida en una inmensa mayoría de dispositivos, sistemas y navegadores que cuentan con las tecnologías apropiadas para sustituir una simple referencia por una imagen, un programa o por otro documento. Pero nada de esto se puede considerar una solución "global", a pesar de la proliferación de sistemas operativos gráficos con capacidad para representar contenidos de diversa índole.

Y no es algo en lo que no se haya pensado. De salida se establecen atributos como alt o elementos como noframes para incluir un contenido alternativo a mostrar en el caso de que el reemplazo no tenga éxito. El modelo de elemento object puede considerarse el más "amable" al poder incluir sucesivas soluciones alternativas (otros elementos object de diferente tipo y texto en último caso). Una página con marcos, desde el punto de vista de este párrafo, incluye únicamente dos o tres elementos reemplazados y, en el mejor de los casos, un elemento con información alternativa.

El papel del autor

Varias son las razones que arrastran a un autor a la utilización de un conjunto de marcos, la mayoría están relacionadas con la comodidad, y en general todas siguen el mismo patrón: menú omnipresente a la izquierda y contenido cambiante a la derecha (y quizá una cabecera también constante, pero sin ninguna funcionalidad). Podemos descartar la colocación como factor a tener en cuenta, ya que no corresponde al documento HTML especificar cómo o dónde se representa el contenido (ver ejemplo en el taller nº3).

Nos queda analizar las ventajas que podemos obtener de separar en varios archivos la información que va a mostrarse. En el ámbito de la organización personal puede venirnos bien, pero los marcos no son la única salida, ni tampoco la mejor. Es preferible la elección de cualquier tecnología en el lado del servidor, alguna sorprendentemente simple, como el uso de SSI para incluir un contenido común en cualquier documento de forma transparente, independiente del cliente. Incluso si no hay posibilidades de operar en el servidor, siempre hay soluciones de andar por casa, y no se descarta dedicar un futuro taller al respecto.

En el lado del usuario

Los marcos sólo tienen sentido cuando se ven. Esta perogrullada no es gratuita, ya que cuando el usuario, ya sea por problemas físicos o técnicos, no puede hacer uso de ellos, la utilidad del sitio queda reducida dramáticamente, y todas las molestias que se tomó el autor caen en saco roto. Pasando este escabroso detalle por alto, el usuario recibe una interfaz gráfica bastante clásica, que no es exclusiva del uso de marcos. Sólo notará algo raro cuando, al ir navegando por los contenidos del sitio, constate que la URL que exhibe el navegador no cambia, por más que se carguen nuevos documentos. Esto, junto con la invariabilidad del marco del menú, le puede provocar cierta desorientación.

Las máquinas también opinan

¿Y qué lenguaje utilizan? Por ejemplo HTML, cuya funcionalidad queda bastante maltrecha cuando se utilizan marcos. El elemento característico de este lenguaje es el hipervínculo, que sirve de bien poco en una composición de marcos. Como hemos dicho antes, la URL siempre es la misma, la que contiene el conjunto de marcos. Cualquier combinación de marcos resultante de la navegación por el sitio será irreproducible por métodos normales, y los enlaces que apunten a fragmentos dentro de un documento son imposibles.

Pongámonos por un momento en el lugar de un "robot araña", de esos que trabajan para los buscadores más ilustres. Llegamos al directorio de turno y cazamos el archivo principal, junto con una descripción que, en la mayoría de los casos, alude al uso de marcos y hace una gracia sobre lo antiguo que es el navegador que está usando el usuario. No aporta gran cosa sobre el tema real del sitio, pero a nosotros, como robots obedientes que somos, nos importa un pimiento. Quizás en ese momento, o en la siguiente vuelta que nos demos por esos lugares, indexaremos el resto de documentos que componen el sitio, los cuales sí mostrarán un contenido coherente. Por tanto, es de esperar que los usuarios que utilicen el buscador accedan a estos últimos enlaces, que estarán huérfanos, al faltarles la información del conjunto de marcos. ¡Buena la hemos liado! Y es que los robots somos así.

Y los monitores no van a ser menos

Ya que son estos dispositivos los únicos que pueden mostrar marcos (siempre que el hardware y el software se lo permita), es razonable que también puedan aportar su granito de arena, y además la estructura de este documento pedía a gritos una última parte sin demasiado hierro. Sobre un total de trescientos monitores encuestados, a un ochenta y cinco por ciento le parecía muy raro eso de que el contenido "desapareciera" debajo de otro elemento de la propia página, unos cuantos, cuyos dueños les tienen condenados a unas resoluciones ridículas, se ven incapaces de representar las páginas de marcos con un mínimo de estética y buen gusto, y uno de ellos, muy simpático, aunque algo neurótico, nos relató que cierta vez sufrió un colapso cuando una página cargó en uno de sus marcos otra página que también contenía marcos y que a su vez llamaba dentro de otro a... Bueno, era algo así, pero él lo contaba con más gracia.

Reflejo condicionado

Algunos comentarios y sugerencias me han llevado a pensar que quizás algunas cosas no han quedado suficientemente claras, y aunque no sé si conseguiré enmendar esa situación no está de más intentarlo. En primer lugar, y antes de volver nuevamente a detalles más técnicos, decir que esto no tiene ninguna relación con otros debates más pintorescos, como los famosos PC vs Mac, Windows vs Linux o el manido Explorer vs Netscape. En todo caso entroncaría con la discusión sobre la utilidad real de los estándares, tema que acabará teniendo, irremisiblemente, su artículo propio dentro de estas páginas.

Es posible crear piezas de código JavaScript que eluden ciertos problemas de los marcos, como los derivados de cargar directamente un documento proyectado para formar parte de un conjunto de marcos, e incluso el de la inmutabilidad del título. Puede que estos scripts salven la situación en ciertas ocasiones. Pero en otras lo único que hacen es engordar gratuitamente la lista de problemas de accesibilidad, porque generar contenido mediante scripts en el lado del cliente es una técnica aún menos recomendable que el uso de los marcos.

En ciertas ocasiones he observado una especie de reflejo condicionado merced al cual alguien se entusiasma con los métodos de presentación gráfica utilizando elementos div posicionados mediante CSS, para preguntarse después cómo se puede cargar una página en cualquiera de esos div. Obviamente no se puede, salvo que el citado elemento fuese en realidad un iframe o un object, pero entonces volveríamos a tener los mismos problemas (o todavía más, debido a lo relativamente novedoso de estos últimos elementos). HTML no puede ni debe establecer el dónde o el cómo ocurren las cosas, porque existe un sinfín de posibilidades, que quedan reducidas a una (en el mejor de los casos) cuando se utilizan marcos o técnicas similares.

Hay algo que en un principio decidí no tocar, debido a su controversia: el tiempo de descarga. Atendiendo a este argumento, en circunstancias normales no se obtendrán resultados que permitan inclinar la balanza a favor o en contra del uso de marcos. Evidentemente, si contamos con un menú común que "pesa" 150 Kb él solito, las páginas tardan una eternidad en representarse (salvo que la mayor parte de su tonelaje derivase del uso de imágenes, con lo cual la lectura de la caché aceleraría notablemente el proceso en sucesivas peticiones). Es lógico pensar que el uso de un sistema de marcos evitaría tiempos de espera innecesarios. Pero el problema fundamental en este caso es más simple que el debate que nos ocupa, y reside en lo poco apropiado que resulta un menú de tan "generosas" proporciones.

Realmente, la gestión de un sitio mediante marcos se queda pequeña a las primeras de cambio. El más que discutible ahorro de recursos que parece ofrecer en un principio se convierte en una soga que limita el desarrollo a una inflexible distribución de contenidos. Los marcos constituyen un sistema de representación, pero más allá de opiniones acerca de su idoneidad en ese sentido o de sus evidentes problemas de accesibilidad y compatibilidad, lo cierto es que lastran sin solución el proceso previo de todo desarrollo, la fase de estructuración. Y es que una web es algo más que unos cuantos miles de píxeles incrustándose sobre la pantalla de un monitor.

Comentarios

Estás en: tierra de nómadas > debates > A vueltas con los marcos.