Por Andreu Ballesteros, junio de 2003
Los documentos de hipertexto que se transmiten por la red Internet usan un sistema de marcado de texto para representarse.
El lenguaje que se utiliza para marcarlos es el HTML o Hyper Text Markup Language, que permite definir la estructura de un documento y la relación entre sus partes, por ejemplo, se define qué es un titular, qué es un parrafo de texto, qué es un hiperenlace, etc.
El HTML como lenguaje se basa en SGML (Standard Generalised Markup Language), que es un estándar (ISO 8879) derivado del antiguo GML de IBM.
El SGML se formuló como un lenguaje de marcado que no diera información sobre la representación de los documento en papel o en la pantalla, de manera que se pudieran intercambiar entre diferentes sistemas, ofreciendo diferentes vistas del contenido, o siendo fácilmente procesables por máquinas.
Algunos autores, en cambio, pensaban que, para una comunicación efectiva, el aspecto o diseño de un documento es tan importante como el contenido en sí. Desde la primera definición del HTML en 1991 se ha recurrido a las herramientas que proporcionaba este idioma para proporcionar información sobre el diseño de los documentos, recurriendo en ocasiones a “trampas” o caminos poco ortodoxos para conseguir este fin.
Históricamente, uno de los medios más usados por los profesionales del diseño ha sido la utilización de tablas HTML para acomodar los layouts o diseños ya que, aunque en principio fueron concebidas como una simple forma de representar datos tabulares, ofrecen una forma bastante precisa y controlable de presentar gráficamente la información.
Hace unos años, hacia 1996, Netscape Corporation y Microsoft poseían cada uno cerca del 50% del mercado de los navegadores web, con dos aplicaciones (Netscape Navigator e Internet Explorer) que eran claramente incompatibles, ya que cada una de ellas usaba su propio DOM (Document Object Model) y hacía, por tanto, una interpretación particular y propia del HTML.
Debido a las muchas características propietarias de los navegadores, el trabajo de los webmasters rápidamente se convirtió en una tortura: los sitios web debían testearse no sólo en dos navegadores diferentes, sino también en diferentes plataformas con diferentes versiones del mismo navegador. Los desarrolladores no seguían los estándares porque los navegadores no los seguían, y los navegadores no los seguían porque los desarrolladores tampoco lo hacían.
En este contexto, el 
Web Standards Project (WaSP), lanzó un mensaje de alarma: Si Netscape y Microsoft persistían en su actitud, el coste de desarrollar para la web continuaría incrementándose absurdamente, y la web podría acabar convertida en una Babel digital, que, de hecho, era lo que estaba ocurriendo.
La solución llegó de la mano del inventor de la web, Tim Berners-Lee, quien fundó en 1994 el World Wide Web Consortium o W3C, organismo formado por representantes de la industria y desarrolladores para recomendar tecnologías como CSS o XML, que permitirían al nuevo medio continuar siendo abierto, interoperable y accesible. Se creó un DOM abierto y gratuito, que, con el tiempo, se convertiría en el estándar.
Si las tecnologías recomendadas por el W3C tuvieran soporte total, los diseñadores podrían diseñar y los desarrolladores podrían crear funcionalidades más allá de las limitaciones de cualquier navegador individual. Se trata, en definitiva, de llevar la web a su pleno potencial. Para ello el W3C publica periódicamente unas recomendaciones que, de hecho, se convierten en estándares.
Hasta bastante recientemente, Netscape y Microsoft continuaban sin ser partidarios de soportar las mismas tecnologías abiertas, ya que, como grandes compañías que son, no se sentían cómodas con la idea de que nadie (ni siquiera los inventores de la web) les dijera cómo debían hacer sus negocios.
Los ingenieros de software de estas dos compañías han sido quienes privadamente han convencido durante los últimos años a sus equipos de marketing para adoptar las recomendaciones del W3C, y crear navegadores que se adhieran a los estándares.
Según el W3C, en la actualidad el problema de la balcanización de la web ya no son los navegadores, sino la comunidad de diseñadores y desarrolladores encadenados al modelo de marcado de los 90, con clientes que confunden la web con el material impreso e insisten en la presentación “al píxel” de sus sitios web en navegadores que no son capaces de ello, excepto a costa de la perdida de interoperabilidad, accesibilidad y estructura de los documentos.
Los documentos que cumplen con los estándares tienen mayor visibilidad en los resultados de las búsquedas en la web, ya que la información estructural incluída en ellos hace más fácil para los motores de búsqueda evaluar los contenidos e indexarlos con precisión.
Igualmente, estos documentos pueden ser convertidos fácilmente a otros formatos, como bases de datos o documentos de Word. Esto permite un uso más versátil de la información contenida en la web y una migración más fácil a nuevos sistemas como PDAs o Web-TV’s.
No sólo a las personas con minusvalías, sino también a aquéllas que acceden a la web con otros navegadores que los usuales, como navegadores de voz, navegadores Braille, pantallas de teletexto, teléfonos WAP, etc.
A medida que la variedad de sistemas de acceso a la información crece, cada vez es más complicado mantener diferentes versiones de los documentos que puedan funcionar en todos ellos. Creando documentos que cumplan con los estándares se asegura que tanto los navegadores actuales como los futuros puedan acceder correctamente a la información.
La mayoría de los estándares de la web se han diseñado con compatibilidad pasada y futura en mente. Esto es, los datos que utilizan las viejas versiones de los estándares continuarán funcionando en los nuevos navegadores, y los datos que usan los nuevos estándares producirán un resultado aceptable en los navegadores antiguos.
Un website puede pasar por las manos de varios equipos de diseñadores durante su ciclo de vida, y es importante que todos ellos puedan comprender el código y editarlo fácilmente. Los estándares de la web ofrecen una serie de reglas con las que cualquier desarrollador puede familiarizarse, seguirlas y entenderlas.
Una vez que el desarrollador diseñe un site acorde a los estándares, cualquier otro podrá retomar el trabajo en el punto en que el primero lo dejó.
A lo largo de estos últimos años, el lenguaje HTML ha pasado por una serie de revisiones, la última de las cuales es la versión 4.01, de 1997. El mayor cambio desde entonces ha sido la introducción del XHTML (Extensible Hyper Text Markup Language), que no es más que una familia de módulos y tipos de documentos actuales y futuros que reproducen y extienden el HTML, reformulado en XML (Extensible Markup Language).
La producción actual de HTML en Mubimedia se basa en HTML 4.01 (que es el que por defecto crea Dreamweaver 4), pero no se ha tenido en cuenta el aspecto de la validación; es decir, usamos trucos que nos ayudan en la presentación de los documentos y explotamos los bugs de los navegadores, pero no nos adherimos 100% a los estándares del W3C.
Igualmente, usamos características de la tecnología CSS (Cascading Style Sheets – hojas de estilo en cascada) como mecanismo auxiliar de presentación de fuentes en los documentos HTML. Actualmente esta tecnología permite muchas más cosas, la más interesante de las cuales es la posibilidad de posicionar y definir gráficamente elementos de cualquier tipo en una página; es lo que se conoce como CSS positioning.
Parece claro que un primer paso hacia la estandarización de nuestra producción HTML sería crear documentos HTML 4.01 válidos, pero, debido a la escasa diferencia formal con el XHTML, vamos a pasar directamente a éste. Igualmente, y, aprovechando el cambio tecnológico, vamos a empezar a usar CSS 2 para el posicionamiento gráfico. Sólo mencionar que ya existe la versión 3 de CSS, pero como aún es bastante nueva y está fuertemente enfocada hacia características avanzadas de accesibilidad que aún no vamos a explotar, nos quedaremos en la versión 2.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "DTD/xhtml1-frameset.dtd"><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Virtual Library</title>
</head>
<body>
<p>Moved to <a href="http://vlib.org/">vlib.org</a>.</p>
</body>
</html>
En este ejemplo se incluye la declaración XML del documento, que, si bien no es necesaria en todos los documentos XML, si es recomendada para los autores de XHTML, y necesaria si el documento usa otro juego de caracteres que UTF-8 O UTF-16, que son los que se usan por defecto.Como hemos visto en el apartado “Ventajas de usar los estándares de la web”, sería conveniente que toda la producción HTML que se genere en Mubimedia se oriente en esta dirección.
Parece claro que el que todos los desarrolladores sigamos el camino de los estándares es únicamente una cuestión de tiempo. Cuanto antes comencemos, más rápido podremos ofrecer un producto con este valor añadido a nuestros clientes.
Ya hay una nueva ola de diseñadores web que abogan por la adhesión a los estándares, la muerte de las tablas como mecanismo de layout y la separación estricta entre presentación y contenido. Al final del artículo se incluyen algunos links.
Tampoco debemos olvidar que algunos países como Estados Unidos ya se está legislando sobre accesibilidad en la web y determinados sites, como los de organismos oficiales, universidades, etc. deben ceñirse a ciertas normativas oficiales. Alguno de nuestros clientes ya ha mostrado interés a este respecto.
No obstante, no todo el monte es orégano. Aún deben salvarse un buen número de dificultades.
Veamos a nivel práctico, las ventajas y los inconvenientes de utilizar estas nuevas tecnologías, XHTML y CSS positioning:
http://www.westciv.com/layout_master/index.html), pero esto será tema para un próximo artículo. Sopesados todos estos aspectos en el Área de Nuevas Tecnologías, se ha llegado a las siguientes conclusiones:
Con la experiencia y los problemas que acumulemos los implicados en estos 2 proyectos, podremos sacar conclusiones más exactas que nos permitan formar adecuadamente a todos los integrantes del Área de Nuevas Tecnologías y dar definitivamente el paso hacia la adhesión a los estándares de la web.
http://www.w3.org/http://www.macromedia.com/macromedia/accessibility/http://www.mako4css.com/Links.htmhttp://www.useit.com/alertbox/9707a.html