El Imperio del HTML

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">



</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.

El Imperio del HTML

Documents

Transcript of El Imperio del HTML