Post on 18-Jan-2016
description
El Imperio del HTML
1. De nuevo la historia.
Da la impresión de que Tim Berners-Lee tardó algún tiempo en reconocer la verdadera
entidad del código HTML que había producido para visualizar sus primeras páginas
web en el CERN. De hecho, HTML no pasaba de ser en aquel entonces una mera
colección de recursos diseñados para solventar los problemas de visualización que
habían ido surgiendo con WWW, el primer navegador orientado al protocolo HTTP.
Este navegador, y por tanto el primer uso no experimental del código HTML estuvo
disponible en el CERN en las navidades de 1990, momento que suele considerarse
como inicio simbólico de la Red.
La primera especificación del código HTML corre a cargo de Tim Berners-Lee y Dan
Connolly y se hace a través de un documento de trabajo presentado en 1993 ante la
IETF –Internet Engineering Task Force- organización no gubernamental destinada al
establecimiento de estándares en Internet. El acto de hacer público el código
declarándolo de libre acceso constituye seguramente un acto determinante para el futuro
que de hecho ha tenido la Red. No se puede saber si en caso de haber actuado de otro
modo, patentado el código y haciéndolo propietario, el destino de la Red hubiera sido
realmente muy distinto al que ahora es. Jugar con la Historia es estos asuntos es siempre
complicado. Pero tenemos ejemplos que nos dan una idea de lo que podría haber
pasado. Piénsese en el estado actual de los documentos de texto o mejor aún, de los
formatos de imagen. La existencia de una gran variedad de formatos hace que nuestras
transacciones estén condicionadas siempre por la compatibilidad de nuestras
aplicaciones e interpretes. Cuando un documento de texto es abierto desde una
herramienta que no soporta su formato suele producirse un error que en mucha
ocasiones no puede ser resuelto de modo alguno. El documento simplemente no es
abierto en nuestra aplicación. En otras ocasiones se puede visualizar parcialmente el
documento forzando una versión compatible en la que muchos datos sin duda resultan
perdidos o dañados. También es posible solicitar al remitente una versión gráfica –pdf-
del documento que permita visualizarlo bajo un estándar compartido, aunque tampoco
sea libre. Piénsese qué hubiera sido de la Red si HTML hubiera sido un programa
propietario en competencia –porque es obvio que ésta se habría producido- con otros
estándares también orientados a HTTP. La posibilidad de navegación habría quedado
restringida a comunidades de usuarios determinadas por estrictas normas de
compatibilidad de sus recursos. Nuestros navegadores, al ser igualmente propietarios,
bloquearían la apertura de documentos incompatibles haciendo de la Red un continuo de
fronteras difícilmente soportable. Por fortuna la historia ha sido otra. Lo cual muestra
bien a la claras cómo ciertas decisiones aparentemente altruistas son, en realidad, la
única respuesta sensata a una situación cuyas condiciones de contorno hacen demasiado
caras las alternativas más egoístas. Habrá ocasión de hablar de todo esto más adelante.
La especificación oficial del código HTML se produce algún tiempo después
presentándose la que fue la primera versión estable del código, la HTML 2.0. No existe,
por tanto, una versión oficial del HTML 1.0. Este documento se incorpora en la serie
RFC –Request for Comments- en la que figura como RFC 1866. Lo firman de nuevo
Tim Berners-Lee y Daniel Connolly y aparece fechado en noviembre de 1995. En su
abstract podemos leer lo siguiente:
“Abstract
The Hypertext Markup Language (HTML) is a simple markup language used
to create hypertext documents that are platform independent. HTML
documents are SGML documents with generic semantics that are
appropriate for representing information from a wide range of
domains. HTML markup can represent hypertext news, mail,
documentation, and hypermedia; menus of options; database query
results; simple structured documents with in-lined graphics; and
hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information
initiative since 1990. This specification roughly corresponds to the
capabilities of HTML in common use prior to June 1994. HTML is an
application of ISO Standard 8879:1986 Information Processing Text and
Office Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type
(RFC 1521) is defined by this specification.”
La declaración de que HTML acepta las normas y la sintaxis del SGML - Standard
Generalized Markup Language- hecha justo al final de este abstract indica la clara
voluntad de sus creadores de fomentar la compatibilidad de sus aplicaciones y de
asegurarse una cierta persistencia para los documentos creados en HTML. El estándar
SGML databa de bastante tiempo atrás, de hecho de la década de 1960, y fue definido
por Charles Goldfarb, Edward Mosher y Raymond Lorie con el fin de producir textos
que pudieran ser fácilmente interpretados por cualquier sistema con independencia de la
plataforma sobre la que estuviera operando. Se suponía que los documentos creados
según este estándar obtendrían una garantía extra de durabilidad haciendo de ellos los
candidatos idóneos para almacenar información cuya preservación se considerara
objetivo primordial. Documentos legales y directivas, normas de aplicación en la
industria o diccionarios son los primeros usuarios de este estándar.
La idea del SGML consiste en hacer uso de etiquetas que enmarcan un texto al cual se
aplican los atributos y acciones indicados en las mismas. Estas estructuras suelen recibir
el nombre de elementos. Un ejemplo basta para entenderlo: <etiqueta1
atributo=””>texto</etiqueta1>. Esas etiquetas pueden aplicarse también a otros
fragmentos etiquetados generando un modelo recursivo de incorporación de la
información. Más adelante veremos detalles concretos del modo en que funciona este
recurso.
El uso de ángulos para definir las etiquetas y distinguir la marca de cierre mediante la
inclusión de una barra invertida es reconocible, no sólo en HTML, sino también en
numerosos recursos de todo tipo. Los procesadores de texto anteriores a la generación
encabezada por Word hacían un uso extensivo de esta técnica para aplicar formato
gráfico al texto visualizado en pantalla. Se trata, por tanto, de un estándar –otro más-
ampliamente aceptado y extendido y sin el cual no se entenderían muchas de las
herramientas y prácticas que son habituales hoy en día.
Pero HTML no ha permanecido sin cambios. De hecho ha experimentado una larga
serie de ellos que se inician ya al poco tiempo de publicarse la RFC 1866. En 1996 se
publican la RFC 1867, RFC 1980, y RFC 1942. En 1997 aparece la RFC 2070, y
finalmente en 2000 la RFC 2845 en la que se hace un resumen de la historia de HTML
y sus versiones y se anuncia la salida de sus especificaciones del sumario de IETF. De
hecho, y como se puede leer en ese documento, las versiones posteriores a HTML 2.0
fueron publicadas todas ellas como recomendaciones del W3C y no ya de la IETF. Así,
HTML 3.2 es publicado en enero de 1997 dando paso a HTML 4.0 en diciembre de ese
mismo año. La versión más frecuente en la actualidad, la 4.01 es de diciembre de 1999
mientras que XHTML 1.0, lenguaje llamado seguramente a reemplazar al HTML
clásico aparece en enero de 2000. Como se puede ver, estamos ante un producto en
cambio permanente impulsado siempre por el intento de incorporar un número creciente
de funciones al entorno de trabajo de la Red: tablas, múltiples ventanas o marcos, tablas,
capas, formularios, incrustación de imagen y sonido, etc.
Pese a la impresión que esta secuencia puede producir, lo cierto es que todas las
versiones de HTML han sido capaces de conservar la suficiente coherencia como para
permitir que los navegadores visualicen siempre ediciones anteriores del código. HTML
4.0 introdujo la opción de conservar elementos abandonados de versiones anteriores a
través de una declaración inicial, transitional, que aconsejaba al navegador tolerar
etiquetas de versiones previas indicándole el mejor modo de actuar con ellas. Esa
práctica se prohíbe en la presentación estricta –strict- mientras que en la variante
frameset se anuncian la incorporación de múltiples ventanas o marcos en la misma
página. Toda esta información no representa en realidad la introducción de versiones
distintas, sino que ofrece, más bien, ciertos consejos al navegador acerca del mejor
modo de visualizar la página en cuestión. Esta estrategia se ha conservado en la versión
HTML 4.01 que, como ya he dicho es la que a buen seguro está más extendida en la
actualidad. El cambio anunciado por XHTML no tiene que ver tanto con las funciones
ya existentes, sino con el intento de fijar con mayor rigor los criterios sintácticos que
están presentes en HTML 4.01 y que han sido calificados, justa o injustamente, como
excesivamente vagos y permisivos. Se intenta, así mismo, abrir el código HTML a
funciones que dependen de un estándar que está reemplazando a todo lo que en su día
siguió el patrón fijado por SGML. Ese nuevo estándar, conocido como XML –
Extensible Markup Language- promete crear un entorno para el manejo de la
información mucho más amplio que el que hay disponible hasta ahora en la Red.
Ajustar HTML a sus criterios y filosofía ha sido considerado por el W3C como un paso
previo para dotar a la Red de nuevas funciones que, según sus promotores, debería
provocar un salto adelante de cuantía similar al que la introducción de HTML supuso en
su día. Ya lo veremos.
2. La estructura de un documento HTML/XHTML.
El apartado anterior sólo ha dado por supuesto un conocimiento muy somero acerca de
qué es una página web. Bastaba con saber que estaban elaboradas en HTML y que este
es el lenguaje que permite que un navegador visualice correctamente los contenidos de
cada una de estas páginas. En este apartado vamos a hacernos algunas preguntas más
generales acerca de HTML, intentado entender qué lugar ocupa en el vasto reino de los
lenguajes que empleamos para comunicarnos con sistemas automáticos del tipo más
diverso. A continuación, describiremos la estructura interna de una página web llegando
a reconocer sus elementos principales. Aprenderemos también a validar nuestras
páginas y a reconocer qué está mal cuando cometemos un error. Todo ello evitando los
detalles que puedan resultar excesivamente técnicos.
Cuando abrimos una página web nuestro ordenador recibe un documento que es
inmediatamente interpretado por el navegador que estamos manejando. De hecho, es ese
navegador el que hace una petición a un servidor a través del protocolo HTTP. Esa
petición es la que figura explícitamente en la barra de navegación de nuestro intérprete
HTML.
En este ejemplo,
he abierto mi
navegador que
presenta la
página de
Google como
página de inicio
y he tecleado en
la barra de
navegación que
figura en la parte superior lo siguiente: http://www.uam.es. Cuando pulse la tecla
correspondiente se enviará esa petición al servidor de la UAM el cual devolverá la
siguiente página:
Pero lo que realmente ha llegado a mi máquina es otra cosa. A nivel del código HTML
lo que el servidor me ha enviado tiene este aspecto:
Ese es el código HTML que es interpretado por mi navegador para dar lugar a la página
que visualizamos cuando usamos las cosas tal y como está pensado que lo hagamos. Lo
primero en que merece la pena detenerse es en el hecho de que haya sido posible
visualizar ese código. La razón es, como ya se dijo en el apartado anterior, que HTML
no es código propietario, no está protegido por copyright alguno, y por tanto todos
podemos acceder a su contenido y cambiar lo que queramos. Quizá merezca la pena ver
cómo.
Todo navegador tiene una opción que permite acceder al código fuente de la página que
se está visualizando. Cuando se accede a esta instrucción, el navegador lanza un editor
de texto –normalmente pensado para texto sin formatos o con formatos orientados a
HTML- que es el que permite mostrar el código de la página en cuestión. Lo primero
que se puede reconocer fácilmente es la presencia masiva del tipo de estructuras que
líneas atrás hemos denominado elementos. Es decir, secuencias del tipo <etiqueta1
atributo=””>texto</etiqueta1>. La cuarta línea del ejemplo anterior, contiene el
elemento:
<TITLE>Universidad Autónoma de Madrid</TITLE>
Quizá sea interesante comprobar qué sucede si en su lugar se escribe otra cosa, da igual
qué. Una vez hecho, se guarda el archivo cuidando de que su extensión sea html, y se
vuelve a abrir en el navegador. Comprobaremos que la página visualizada conserva algo
del contenido de la original aunque muy probablemente también se han perdido muchos
de los elementos que veíamos inicialmente. Más adelante entenderemos por qué.
Además, en la línea superior de la pantalla ya no aparece el mensaje de la página
original, sino aquello que hayamos puesto en el interior de la etiqueta
<TITLE></TITLE>. Es decir, hemos sido capaces de cambiar a nuestro antojo el
aspecto de esa página actuando libremente sobre el código original. Lo primero que se
observa cuando se visualiza en un navegador una página cargada en nuestra máquina es
que la dirección que aparece en la barra de navegación ya no tiene el aspecto http://,
sino que en su lugar aparece la dirección que el documento tiene en la estructura de
directorios de nuestro ordenador. Es decir, estamos visualizando un documento html
como haríamos con un documento cualquiera de texto. Es importante detenerse en este
detalle porque ayuda a entender la auténtica naturaleza de un documento html. Un
documento válido con extensión .html no tiene por qué ser servido por una máquina
remota a través de Internet, es, a todos los efectos, un documento más dispuesto eso sí,
para ser visualizado por un navegador basado en html. Pero eso tampoco es nada
característico o propio, ya que un documento con extensión .doc, por ejemplo, no es
sino un documento de texto pensado para ser leído por Word.
Ahora que ya nos hemos familiarizado algo más con los documentos html, perdiendo el
miedo que este tipo de tecnologías pueden inspirar en todos aquellos que nos acercamos
a ellas desde fuera, quizá merezca la pena reflexionar algo sobre la filosofía en que se
apoyan. Un documento html es, ante todo, un documento electrónico más. Su
característica principal es la de hacer un uso extensivo de metadatos y de las técnicas de
composición de texto basadas en el uso de estos metadatos. Este término no tiene una
historia clara pero al menos sí podemos hacernos idea de en qué consiste cuando lo
aplicamos a un documento html. Se puede considerar que un metadato es una entidad
diseñada para ser aplicada a otro dato de tal forma que añada información acerca del
modo de entender, manipular o actuar ante ese dato. Eventualmente un metadato puede
carecer de atributos explícitos adjudicándose entonces su acción al elemento que lo
contiene. Un ejemplo muy sencillo es el que proviene de alguno de los editores de texto
que fueron de uso común hace algunos años, me refiero al famoso WordPerfect en su
versión 5.1. La incapacidad de esos primitivos editores para ofrecer en pantalla
versiones finales del texto que estaba siendo compuesto obligaba a incorporar el
formato gráfico mediante funciones cuya acción inmediata era aplicar al texto
seleccionado el formato deseado. Eso se conseguía encajando el texto en cuestión
dentro de una etiqueta tipo SGML que, propiamente constituía un metadato. Así, por
ejemplo, si se quería que la palabra “rojo” apareciera en negrita en el formato final
impreso, lo que debía visualizarse en pantalla era algo así como: <b>rojo</b>. La
etiqueta <b></b> constituye un metadato cuyo argumento es la palabra “rojo” y cuya
acción es “poner en negrita”.
La evolución de los procesadores de texto en la dirección de ofrecer presentaciones
finales –similares a las impresas- en pantalla junto con el hecho de que la mayoría de
esos editores son propietarios hicieron que la composición de texto mediante el manejo
de metadatos quedara marginada y prácticamente olvidada. Sólo ahora empieza a
entenderse la auténtica importancia de este tipo de técnica de composición de
documentos. Y no solo por la importancia de HTML, sino por el reconocimiento de que
los medios actuales de creación de documentos permiten considerar técnicas de trabajo
muy distintas a las que hemos heredado de la época en que la máquina de escribir era el
único medio de composición de documentos apto para la libre distribución –y distinto a
su vez de los métodos industriales de imprenta-. Un texto no tiene por qué constar de
una única capa, la que el ser humano puede ver e interpretar, sino que puede constar de
muchas más apoyadas en metadatos y destinadas a otros fines. El formato gráfico es uno
de ellos, como también lo es la estructura de referencias que denominamos hipertexto,
pero puede haber muchas más.
Estas consideraciones permiten ofrecer una definición del lenguaje HTML bastante
esclarecedora. HTML es un lenguaje de metadatos no extensible, es decir, no abierto a
nuevas incorporaciones por parte del usuario, orientado a la presentación gráfica de
contenidos y dotado de capacidad para definir enlaces con objetos y documentos de
todo tipo. Qué otro tipo de entidades o lenguajes pueden generarse mediante el uso de
metadatos es algo de lo que nos ocuparemos más adelante. Por ahora bastará con que
entendamos que HTML es un lenguaje de metadatos entre muchos otros posibles y cuya
característica notable es brindar una gran cantidad de recursos para integrar en un único
contexto elementos de tipos muy diversos suministrando además conexiones entre ellos
a través de un tipo específico de metadato, los hiperenlaces. Los hiperenlaces, es decir,
las etiquetas que indican qué objeto debe visualizarse en el navegador cuando
pinchamos sobre un determinado elemento, texto, imagen, etc., no es por tanto, sino un
tipo más de metadato.
Hay obras de referencia que insisten mucho en ofrecer clasificaciones de las etiquetas
admitidas en HTML según el tipo básico de funciones que realizan. Una división típica
es la que reconoce al menos tres grandes tipos de etiquetas, las tipográficas, las
estructurales y los enlaces de hipertexto. Pero lo cierto es que las cosas no están tan
claras como podría parecer. No creo que en el estado actual de la evolución del HTML
sea fácil imponer categorías como las anteriores, por lo que obviaré aquí la cuestión. Lo
que sí es posible e instructivo además, es analizar la estructura general de un documento
.html. Un documento .html válido no es una colección más o menos afortunada de
elementos, tiene que respetar ciertas reglas que garanticen que los distintos navegadores
no producen errores que impidan o afecten a su correcta visualización. Dicho esto, lo
cierto es que los navegadores suelen admitir casi todo. Basta con que probemos a
elaborar una página de texto que guardaremos con extensión .html y veamos qué
requisitos nos exige realmente nuestro navegador para visualizar la página. El estudio
de la estructura de un documento HTML es interesante por otros motivos,
principalmente para entender las funciones que realmente están disponibles en un
documento de este tipo y toda las transacciones de información que realmente se
producen cuando un servidor envía una página a nuestra máquina.
Todo documento .html válido constará de cuatro estructuras básicas reconocibles por
sus correspondientes etiquetas. El siguiente ejemplo permite reconocerlas.
Estas estructuras son:
i. La declaración del tipo de documento o DTD –
Document Type Definition-.
ii. La etiqueta principal <html></html>
iii. El encabezamiento <head></head>, y por último
iv. El cuerpo <body></body>.
La DTD es una etiqueta procedente de SGML que tiene por objeto hacer público el tipo
de sintaxis empleada en el documento que viene a continuación. En el caso anterior
queda claro que la versión de HTML empleada es la 4.01 en su versión transitional. La
especificación completa de la norma se puede encontrar en
http://www.w3.org/TR/html4/loose.dtd.
La etiqueta que sigue a continuación es la que indica dónde empieza y dónde termina el
documento html que va a visualizar el navegador. Como puede verse no contiene
atributos ni valores de ningún tipo. Este hecho varía ligeramente si en vez de emplear
HTML 4.01 nos decantamos por su sucesor, el XHTML 1.0. Veamos qué aspecto tiene
un documento XHTML vacío y válido:
Como puede verse, la DTD ha cambiado para indicar que el texto que viene a
continuación se ajusta a la sintaxis de la versión transitional del XHTML 1.0. Pero en la
etiqueta <html> aparece un atributo xmlns que aporta una determinada URL. Esta es
una práctica derivada del hecho de que XHTLM es un lenguaje que adopta la sintaxis
XML en la que cada elemento de rango principal –y el que cae bajo <html></html> lo
es porque incluye todos los demás- tiene que venir definido por una especificación
completa, que en este caso es la URL en la que se dice lo que significa la cadena html.
El atributo xmlns es lo que en XML se denomina name space y no es otra cosa, como
acabo de indicar, que la definición de un cierto término.
Tanto en HTML 4.01 como en XHTML 1.0 el elemento principal, el propio documento
html, consta de dos partes, una cabecera acotada por la etiqueta <head></head> y un
cuerpo <body></body>. La cabecera de un documento HTML ha pasado de ser un
elemento auxiliar a convertirse en el portador de una gran cantidad de información. En
la actualidad se reconocen al menos siete etiquetas distintas como posibles contenidos
de la cabecera. Se trata de <title></title>, <base/>, <link/>, <script></script>,
<style></style>, <object></object>, y <meta/>. No las comentaré todas. La etiqueta
<title></title> ya hemos visto cómo funciona y para qué sirve. Es importante incluirla
siempre para evitar ese desagradable encabezamiento que denuncia nuestra falta de
cuidado al nombrar a nuestra página como Página sin título. Los buscadores suelen
mirar ahí a la hora de indexar una página, pero ya veremos que esto sólo es cierto hasta
un punto. Las etiquetas <base/> y <link/> tienen atributos característicos, es decir, hay
valores que pueden aparecer dentro de los ángulos, como por ejemplo en
<link rel=Stylesheet type="text/css"
href="http://portal.uam.es/pls/portal/PORTAL..."/>,
pero no tienen contenido, esto es, no se aplican a texto alguno, no necesitan argumentos
y por tanto se refieren al elemento de orden superior que los contiene. En este caso, la
etiqueta <link/> ha sido usada para asociar el documento actual a otra página que
contiene una serie de elementos relevantes para interpretarla. Esa es la función principal
de esta etiqueta y tiene utilidad para indicar al navegador cuál es la página previa o
posterior a aquella en que se encuentra y sobre todo para asociar estilos al documento en
cuestión. En breve veremos qué es un estilo
La etiqueta <script></script> ha ido ganando peso en los últimos años al irse definiendo
cada vez con mayor claridad la posibilidad de incluir funciones más sofisticadas en la
presentación de nuestras páginas web. Dentro de esta etiqueta figurará básicamente un
pequeño programa, el cual puede estar completamente descrito, o bien puede ser
invocado mediante la correspondiente URL. Para ver un ejemplo, se puede acceder al
código fuente de la página principal del Ftad de Filosofía y Letras de la UAM en
http://www.uam.es/centros/filoyletras/default.html. Allí se incluyen dos pequeños
programas diseñados en JavaScript –por tanto con la extensión .js- cuya función es
controlar los menús desplegables que aparecen en esa página. Hay diversos lenguajes
que pueden ser empleados para fabricar esas pequeñas aplicaciones cada vez más
frecuentes en nuestras páginas, pero el más habitual suele ser JavaScript. Como puede
verse, los scripts alojados dentro de la correspondiente etiqueta son miniaplicaciones
que se ejecutan al abrir un documento html y que añaden funcionalidad a nuestras
páginas. Lo más típico son los menús desplegables pero hay infinidad de ellos que
pueden descargarse de otras páginas o de sitios de desarrollo y pegarse en las nuestras.
La etiqueta <style></style> ha ido cobrando también importancia ya que permite
separar el contenido de un documento html de multitud de aspectos que sólo tienen que
ver con la presentación de ese contenido. A las normas creadas para controlar el formato
que se aplica a un fragmento de texto se le denomina estilo. Los estilos se pueden
definir dentro de la etiqueta correspondiente como en
<style type="text/css">
<!--
.Estilo1 {color: #FFFFFF}
.Estilo5 {font-size: medium}
.Estilo6 {
color: #B49412;
font-size: 36px;
font-family: Papyrus;
}
.Estilo7 {
color: #E6E43B;
font-family: Papyrus;
text-decoration: none;
}
#Layer13 {
position:absolute;
left:721px;
top:328px;
width:143px;
height:27px;
z-index:10;
}
-->
</style>
o mediante la llamada a una página de estilos. Una página de estilos no es sino un
documento aparte identificado por la extensión .css –Cascade Style Sheet-. La tendencia
favorecida en los últimos años es a separar el contenido que aparece en el cuerpo de una
página web de aquellos aspectos gráficos que podrían ser cambiados a placer en
cualquier momento sin que ello afecte al contenido real del documento. En sitios de
cierto tamaño, es decir, formados por una serie considerable de páginas, suele ser
interesante definir páginas de estilos .css externas que controlen el aspecto de todos los
documentos del sitio en vez de permitir que cada página posea el suyo. Es la única
forma, por ejemplo, de garantizar una cierta imagen corporativa o de introducir cambios
de aspecto de alcance suficientemente general.
La última etiqueta que voy a comentar es <meta/>. Se trata de nuevo de una etiqueta
dotada de atributos pero carente de contenido. Su uso es relevante al menos en dos
sentidos. En primer lugar, esta etiqueta se emplea para indicar al protocolo HTPP el tipo
de codificación de datos que corresponde a los caracteres incluidos en el cuerpo del
documento. No me voy a entretener en ello porque el asunto es un tanto técnico y carece
de mayor interés, aunque sí merece la pena indicar que el modo de presentar esta
etiqueta ha variado entre HTML 4.01 y XHTML 1.0. El segundo tipo de uso de esta
etiqueta apunta a la incorporación de datos destinados a informar a otras páginas o
recursos automáticos de determinados aspectos de la página que está abierta. Su formato
es siempre el mismo: <meta name=”” content=””/>. El atributo name fija el término
cuyo contenido se especifica luego en content. Los términos que pueden aparecer en el
nombre los puede fijar el usuario pero también están establecidos por ciertos estándares
de uso. Si el name es keywords, lo que se espera en content es una lista de términos
destinados a orientar a los buscadores sobre el contenido de la página. También se
pueden incluir descripciones, avisos a los buscadores acerca de dónde buscar,
información sobre la frecuencia con que se actualizan los contenidos de la página, etc.
Como puede verse, la cabecera contiene información no destinada principalmente a
agentes humanos, ya que sus contenidos, salvo el título, no se visualizan en las visitas
ordinarias a este tipo de páginas. Su presencia afecta, o bien al aspecto y forma de
manejar el contenido aportado en el cuerpo, o lo que cada vez es más relevante, a
informar a robots y otros agentes de red del tipo de acciones que deben emprender con
ese documento. Me he entretenido en la descripción de la cabecera de una página html
porque ilustra perfectamente la tendencia que el diseño de documentos electrónicos está
adoptando en la actualidad. Un documento puede constar de numerosas capas de
información, todas ellas relacionadas al punto de formar una unidad indisoluble, sin que
tengan por qué estar destinadas al inmediato consumo humano. El problema, como es
fácil suponer, afecta ahora al descubrimiento de formas eficientes de producir texto con
amplia incorporación de metadatos. El sistema de etiquetado heredado de SGML y
adoptado a su vez por XML y sus derivados no permite una producción eficaz de texto
etiquetado siguiendo los patrones habituales, heredados a su vez, de la era Olivetti –en
referencia a las antiguas máquinas de escribir-. Imaginemos por un momento lo que
sería producir una página HTML en un editor habitual de texto. Pero esto no es un
obstáculo real en una época en la que definir un interfaz para la entrada de datos no
representa ninguna hazaña, ni a nivel conceptual, ni mucho menos a nivel de diseño
informático. Los programas destinados a la elaboración y diseño de páginas html
marcan un patrón de comportamiento que quizá debamos seguir en el futuro para la
obtención de texto etiquetado del tipo más general que podamos imaginar.
Pero falta por comentar lo que se supone que debería ser el contenido principal de un
documento html, es decir, el que viene precisamente en el cuerpo del documento y que
aparece encerrado por tanto bajo la etiqueta <body></body>. En esta estructura se
incorpora el material que deseamos hacer explícitamente visible a terceros o a nosotros
mismos. Se trata de un apartado en el que la presentación correcta de la información
resulta de la máxima relevancia, razón por la que proliferan allí los recursos orientados
a producir una adecuada maquetación de los contenidos de nuestro documento. Hay tres
métodos principales de obtener un reparto del contenido de una página web, marcos,
capas y tablas. Los marcos son áreas que dividen toda la página e incorporan sus
propias barras de desplazamiento. Progresivamente han ido cayendo en desuso al
provocar problemas con los buscadores tipo Google y con la apertura de otro tipo de
elementos en su interior. El enmaquetado que prima en la actualidad se basa en capas y
tablas y en una sabia combinación de ambas.
La importancia de un adecuado reparto de los contenidos en una página tiene que ver
con las propias normas de visualización impuestas por este medio. Una página web a
diferencia de la página de un libro estándar, no tiene una dimensión concreta, o mejor
dicho, puede tener cualquier medida. No existe una acto que equivalga exactamente a la
acción de pasar página, por lo que la lectura puede resultar y de hecho resulta mucho
más delicada. Los navegadores no visualizan nunca el contenido íntegro de una página
web, sino sólo aquello que realmente cabe dentro de los parámetros que esa herramienta
tiene definida incorporando barras de desplazamiento –horizontales y verticales- que
permiten acceder al contenido no mostrado. Los formatos de las pantallas en que
solemos visualizar páginas web son a su vez distintos con lo que aún se aumenta más la
confusión y el riesgo de mostrar los contenidos del documento de forma no deseada.
Lo cierto es que hay aún mucho trabajo que hacer hasta llegar a definir un estándar de
lectura de documentos html, pero no es de extrañar ya el uso masivo de páginas web no
es un fenómeno antiguo ni mucho menos terminado. Hasta no hace mucho, una página
web era un medio útil para dar información sobre la ubicación de documentos y datos
mantenidos en soportes clásicos. Nadie había pensado que el soporte habitual llegase a
ser precisamente el documento html llegando a desplazar los formatos tradicionales. Un
lugar privilegiado para observar ese cambio son los grandes medios de comunicación,
sobre todo prensa escrita, la cual ha invertido considerable esfuerzo en lograr versiones
legibles de sus cabeceras que respondan, a su vez, a la lógica del periodismo. Pero como
ya digo, no todo está hecho. La investigación destinada a crear criterios realmente
eficaces de acceder a la información en entornos html es un campo en constante
desarrollo al cual, por cierto, estamos invitados a participar.
El otro elemento que afecta claramente a la legibilidad de un documento html es lo que
resulta más característico de este medio, los hiperenlaces. Los hiperenlaces son
introducidos por etiquetas que tienen el siguiente aspecto: <a href=””></a>. El texto o
el elemento que constituye su argumento –podría ser una imagen o cualquier otra cosa-
queda marcado como un botón que al ser pulsado dirige el navegador al destino
indicado a la derecha de href. Así, por ejemplo,
<a href=”http://www.uam.es”>UAM</a>
tiene el efecto de activar la palabra UAM como un botón que al ser pulsado –pinchado-
dirige el navegador a la página principal de la UAM. Como es obvio hay muchos otros
parámetros que pueden acompañar a esta acción, como por ejemplo, los que indican
dónde abrir la nueva página o archivo seleccionado o el tamaño que ha de tener, pero no
interesa eso ahora. Si me importa dejar claro el tipo de enlaces que pueden ser definidos
en una página web.
La principal diferencia entre enlaces afecta al lugar al que apuntan más que al tipo de
objeto que tienen como destino. Un enlace puede apuntar a otra página web, ya esté en
el mismo sitio, o en otro completamente distinto, o puede apuntar a una posición o
elemento dentro de la propia página. La diferencia es importante. Si el enlace, como en
el ejemplo anterior, apunta a una página web distinta, ésta se identifica mediante una
dirección URL. Cuando la página web a la que apunta el enlace está en el mismo sitio,
es decir dentro del mismo directorio raíz de un servidor, la dirección URL aparecerá
acortada, pero se podría completar igualmente. Las direcciones URL incompletas son,
en realidad, direcciones relativas a un punto raíz. Si este cambia de nombre o de
ubicación pero se mantiene toda la estructura de directorios que depende de él, los
enlaces se preservan intactos, por eso son relativos. En el caso de especificaciones
completas, esos cambios de ubicación puede originar la incorrecta ejecución del enlace.
El tipo habitual de hiperenlace es, precisamente este, es decir, en el que el objeto destino
es otro documento html. Los enlaces a puntos internos a la propia página están pensados
para recorrer con algo de agilidad páginas extremadamente largas en las que hay
referencias constantes a otros elementos de esa misma página. Pero entonces se hace
preciso definir el punto de destino al que apuntan eso enlaces, puntos de destino que se
denominan anclas y se marcan con la etiqueta <a name=" " id=" "></a>. El argumento
de esta etiqueta puede ser, de nuevo, cualquier cosa, pero ha de estar en la misma página
que el enlace. Este tipo de hiperenlaces han caído en desuso porque se considera a todos
los efectos que es preferible dividir un contenido largo en varios documentos que
reunirlos en una página difícil de cargar y aún más difícil de leer. Sólo mantienen su
vigencia en documentos tipo WIKI o páginas con características enciclopédicas en las
que puede ser útil incluir sumarios que remitan a distintos capítulos de un mismo
documento. En estos casos se considera más importante mantener la unidad del
contenido que optimizar la velocidad de carga de la página. Un clásico de los enlaces
internos son los botones que indican un retorno a la posición inicial de la página a su
inicio. Estos botones se hacen perfectamente prescindibles en documentos breves en los
que la barra de desplazamiento basta para recorrer la página de principio a fin sin hacer
sufrir la vista en exceso.
Un tercer tipo de enlaces en claro auge son todos aquellos asociados a elementos
multimedia. La convergencia de recursos en documentos html está convirtiendo este
formato en punto de entrada de innumerables fuentes de contenidos de tipos muy
diversos. Documentos de texto, imágenes, animaciones, archivos de audio o vídeo, etc.
Todos estos recursos pueden lanzarse desde enlaces siguiendo la misma técnica básica
que en el resto de casos, pero entonces hay que tener en cuenta que el tipo de aplicación
de destino ya no es html por lo que nada garantiza su correcta ejecución, ni un retorno
seguro al punto anterior de nuestra navegación. Todos estos aspectos, es decir, los que
tienen que ver con la progresiva integración de medios y recursos en un único entorno
de trabajo es una tarea aún pendiente. El código HTML actual y más aún su sucesor
XHTML parecen haber integrado con éxito formatos considerablemente distintos. El
éxito de ese proceso se encuentra en no haber pretendido en ningún momento diseñar
herramientas propias para manejar los formatos invocados desde un enlace. Si el destino
de un enlace es un documento .doc, el programa encargado de abrirlo en nuestra
máquina será Word. Si no lo tenemos, habremos de conseguirlo. Esto tiene como efecto
colateral la promoción de formatos no propietarios que permitan al menos la
visualización de un determinado objeto aunque no quizá el acceso al código o a
funciones avanzadas. Los documentos de texto suelen tratarse como .pdf por la sencilla
razón de que los lectores de este tipo son de libre distribución. Algo parecido pasa con
formatos de audio, progresivamente derivados hacia archivos mp3 o vorbis. El acierto
de HTML para acoger todo tipo de recurso es también su debilidad. Al tratar cada
objeto como el destino de un enlace se renuncia a lanzarlo desde el entorno de HTML
con lo que se gana en alcance y universalidad, pero se pierde control sobre el destino y
resultado de esa acción.
3. Consideraciones sobre la navegación real en la Red.
La vigencia de un estándar como HTML puede parecernos un logro de la mayor
importancia en un contexto en el que las leyes del mercado no siempre parecen elegir la
mejor de las opciones. Basta intentar imaginar de qué forma se hubiera entorpecido o
retrasado la implantación de una Red auténticamente mundial si HTML hubiera
quedado registrado bajo una patente y asociado a alguna aplicación con código
propietario. Sin embargo, no todo es tan claro en la Red que realmente visitamos a
través de nuestros navegadores. En este apartado voy a comentar algunos elementos
quizá no tan conocidos o visibles pero que tienen una cierta influencia en lo que
realmente ocurre y sobre todo en aquello que podría suceder en un futuro.
¿Hasta qué punto es HTML un estándar real? Esta pregunta se puede entender de dos
maneras distintas. En primer lugar se puede interpretar como una cuestión orientada a
las páginas que realmente habitan en la Red. ¿Están todas ellas escritas en un HTML
suficientemente estandarizado? La respuesta es negativa, obviamente. Y no solo me
refiero a la coexistencia de versiones distintas, sino al grado de cumplimiento de las
propias normas de la sintaxis HTML. Muy pocas páginas de aquellas que están
disponibles en la Red son HTML-válidas. Una página HTML es válida si responde a los
estándares que el W3C establece para la DTD hecha explícita en el documento. Si ésta
no existe, W3C juzgará el documento desde el punto de vista de las versiones más
usuales del código, por lo general HTML 4.01 Transitional. Este proceso se puede
ejecutar de forma automática en la siguiente dirección http://validator.w3.org. Existen
navegadores, Amaya, que también ofrecen esa opción, y en general cualquier buen
editor de HTML permite evaluar la validez del documento que se está elaborando y ello
según distintos estándares. La Red responde, por tanto, al estándar HTML pero sólo si
esto se aplica a cualesquiera documentos y no sólo a aquellos que son válidos, ya que
me atrevo a decir que son una exigua minoría. Y esto nos lleva a la segunda forma de
abordar la cuestión de la estandarización. ¿Significa eso que la Red sólo funciona en
una medida muy pequeña? En absoluto. HTML es realmente un estándar porque
nuestros navegadores no son simples interfaces de HTML, sino que actúan como
genuinos intérpretes. Es decir, completan el código ausente a partir del que está
presente y corrigen los errores optando por las presentaciones más plausibles en cada
caso. Sólo en aplicaciones relativamente complejas puede apreciarse la importancia de
un código convenientemente validado. Puede ser interesante comprobar qué hace un
navegador cuando se le ofrece código realmente roto o incompleto. Para nuestra
sorpresa, casi siempre sabe qué hacer. Es decir, ofrece soluciones aceptables que
permiten visualizar algo.
Otro asunto que interesa evaluar es la coherencia entre la navegación obtenida desde
distintas aplicaciones, IE, Mozilla-FireFox, Netscape, etc. Pese a lo que en ocasiones se
sugiere desde distintos foros, el aspecto de una página no varía gran cosa cuando esta se
abre con distintos navegadores. Suele mucho más problemático, por ejemplo, ajustar el
aspecto de una página a los distintos formatos de pantallas existentes, aunque esto
también está cambiando rápidamente y para bien. Donde sí que se aprecian diferencias
entre navegadores, y sustanciales, es en todo aquello que tiene que ver con la gestión de
contenidos que no pertenecen propiamente al ámbito del código HTML. Me refiero a las
descargas de archivos, a la visualización de clips de audio o video o la activación de
algunos otros contenidos interactivos. Es frecuente que al ejecutar una de estas tareas
cada navegador tienda a encargar la tarea a aplicaciones de su propio entorno que a
menudo se han predeterminado, normalmente por defecto, al instalar el navegador en
cuestión. Como ya dije líneas atrás, es justamente en la periferia del código HTML, es
decir, en el momento en que de hecho se abandona, donde surgen los conflictos y
también la oportunidad para el código propietario. En el próximo tema tendremos
oportunidad de hablar de estos aspectos con más detalle y se analizarán también los
cambios que el tiempo ha ido introduciendo en los gustos y prácticas de los usuarios.
Navegadores de fama hasta hace tan solo unos años aparecen ahora como herramientas
obsoletas o claramente minoritarias mientras que otras se levantan aparentemente de la
nada para hacerse un hueco en el mercado. Porque los navegadores, incluso los
gratuitos, generan en torno a sí un potente mercado a veces nada fácil de apreciar a
simple vista.
Una tendencia muy destacada en los últimos años dentro de la Red es la que intenta
dotar de un mayor dinamismo a las páginas web que la integran. Esto ha llevado a
hablar del DHTML –Dynamic HTML- como una especie de nuevo entorno de trabajo o
quizá una nueva filosofía a aplicar en la Red. DHTML no es, sin embargo, un lenguaje
destinado a reemplazar al HTML clásico, no se trata de eso. Es, y eso en el mejor de los
casos, un conjunto de técnicas y recursos orientados a hacer que la navegación sea una
tarea en la que el usuario pueda tomar una parte más activa. Pero por desgracia no existe
una única forma de entender ese pretendido dinamismo con lo que no siempre se hace
fácil entender qué pretenden aquellos desarrolladores implicados a fondo en el DHTML.
Una frontera fácil de establecer es la que tiene que ver con el modo en que una web se
ejecuta en nuestro ordenador. El HTML clásico es una tecnología orientada al cliente, lo
que solo significa que tras una petición a un servidor de descarga de una página web, lo
que recibimos es, exactamente la página solicitada, ni más ni menos. La navegación se
produce en el ordenador del cliente hasta que se produce otra petición y se vuelve a
repetir el proceso. Nunca hay datos que el cliente pueda introducir a su gusto y que
puedan modificar el resultado de la navegación. Para que realmente exista una
interacción entre cliente y servidor tiene que existir la posibilidad de que el cliente envíe
información que sea analizada y ejecutada por el servidor y que de lugar a un nuevo
contenido original no determinado en todos sus detalles de forma previa. Es preciso, en
definitiva, que parte de nuestra navegación se ejecute en el servidor y su resultado sea
devuelto según los nuevos parámetros introducidos. Un ejemplo bastará para
entenderlo. Cuando accedemos a la página web de una biblioteca universitaria para
consultar la existencia de una cierta obra y enviamos nuestra petición rellenando los
campos de un formulario, estamos interactuando con el servidor. Cuando éste devuelve
la respuesta en forma de una nueva página –que en ocasiones puede tener casi el mismo
aspecto que la anterior, el servidor está interactuando con nosotros. Siempre que hay
formularios con que puedan ser rellenados sin preselecciones cerradas hay una
tecnología por debajo que implica la cooperación del servidor. Creo que todos podemos
juzgar claramente con qué frecuencia accedemos a páginas en las que se produce este
tipo de situaciones.
Este tipo de acceso a contenidos dinámicos exige la cooperación del servidor y la
ejecución de pequeñas aplicaciones cada vez que se requiere un intercambio efectivo de
información. Este hecho, desvía la interacción en la Red hacia herramientas cada vez
más sofisticadas que tienden a trocear mucho los contenidos a los que los usuarios
tenemos realmente acceso. La gran ventaja del código HTML es que permite presentar
grandes cantidades de información de una forma relativamente simple. Una deriva hacia
contenidos dinámicos puede hacer que el papel del HTML tienda a quedar reducido a la
mera construcción de formularios haciendo que las aplicaciones que se ejecutan en el
servidor jueguen un papel cada vez más destacado. En la medida en que esos programas
no son depositados en el cliente, la coherencia y la universalidad del HTML podrían
verse afectadas, pero aún es pronto para saberlo.
La cantidad real de información que un servidor deposita en nuestras máquinas cada vez
que recibe una petición por nuestra parte no es siempre la que creemos que es. Con
frecuencia es mucho menor. La memoria de nuestros ordenadores tiene un espacio
denominado memoria cache en la que se almacenan numerosos datos que ayudan y
agilizan la navegación. Para empezar ahí se guardan páginas que sólo son recargadas
desde el servidor cuando realmente ha cambiado la información que contienen. Para
comprobar la función de la memoria caché basta desconectar el ordenador de Internet e
intentar recargar la página activando una opción que suele denominarse trabajar sin
conexión. Veremos que la página reaparece pese a haber interrumpido la conexión.
También se puede intentar editar directamente buscando el lugar en el que el navegador
ha almacenado toda esa información. Junto con estas páginas almacenadas de forma
temporal se guardan también unos pequeños fragmentos de texto denominados cookies.
Estos archivos son paquetes de información enviados por los servidores en el momento
en que responden a una petición de un usuario. En teoría no contienen información real
que pueda ser leída por terceros, pero sí contiene la suficiente como para que el servidor
pueda reconocer a ese equipo en su próxima visita. Como es obvio, nunca es el usuario,
como persona física, el que va a ser identificado por el servidor que envía una cookie,
sino a lo sumo el equipo al que está asociada una cierta IP y otra serie de datos que
permiten ubicar esa máquina en su contexto. Para ver el contenido de una cookie basta
localizar el lugar en el que nuestro navegador las guarda y abrirlas a continuación. No se
trata de código maligno ni nada por el estilo, sino de texto que permite que un servidor
caracterice nuestras visitas a sus páginas. Eso es todo, y nada menos.