Emmanuelle Gutiérrez y Restrepo

Índice

Web semántica en mayúsculas y web semántica en minúculas

Se ha dado en llamar "Web semántica en mayúsculas" a la interacción semántica establecida mediante RDF. OWL, etc., y los contenedores de metadatos definidos en las especificaciones de los lenguajes de autoría para la web (HTML, XHTML, XML, etc.) siguiendo los estándares del marcado semántico. Y "web semántica en minúsculas" a los "microformatos" o "Microcontenidos".

Una definición ruda de "Microformatos" en inglés es: simple conventions for embedding semantics in HTML to enable decentralized development.. Y quizás esa definición en bruto es la que ha llevado a confusión a muchos nuevos desarrolladores que parecen creer que añadir semántica a las páginas o crear p´ginas semánticamente ricas consiste en el profuso uso de estos microformatos, desconociendo la riqueza semántica que deberíamos dar a nuestros contenidos mediante los contenedores, elementos y atributos, estándares que tenemos a nuestro alcance, de toda la vida.

Desde mi punto de vista, los microformatos son fantásticos porque suponen un verdadero desarrollo descentralizado de recursos, herramientas y servicios Web. Pero es curioso comprobar cómo, precisamente en sitios o "blogs" que propugnan el uso de los microformatos, brilla por su ausencia un verdadero marcado semántico.

La rápida aceptación y difusión del uso y desarrollo de microformatos frente al uso y desarrollo de vocabularios y ontologías, probablemente se debe a que el lenguage utilizado para los primeros es mucho más simple que los lenguajes utilizados para los segundos. Pero evidentemente eso tiene su contrapartida. Con un lenguaje tan simple será difícil, y en algunos casos imposible, expresar ideas complejas. Pero, una cosa no excluye a la otra, es decir, en la web pueden coexistir e incluso trabajar unidos para fortalecer su semántica.

Y es eso lo que me motivó a escribir este artículo. Mostrar cómo estamos infrautilizando elementos de marcado semántico que pueden ser muy útiles para los usuarios y no sólo para la interacción de nuestros contenidos con las máquinas.

¿Pero qué es eso de la "Meta Navegación"?

Pues es algo muy simple, que existe o la posibilidad de aplicarla existe, desde tiempo inmemorial, desde el primer borrador de HTML que data de 1995, y antes de ello estaba ya en el documento HTMLPlus, que data de 1993. Pero que, a pesar de ello, no ha sido aprovechada en toda su capacidad por los autores Web, aunque es un requisito de accesibilidad; ni es algo que los usuarios tenían siempre a su alcance, lo que desalentaba a los autores, por otra parte.

Consiste sencillamente en definir la relación entre las distintas páginas de un sitio web y/o entre distintos contenidos. Definición especialmente importante cuando se trata de colecciones de documentos o páginas que están intrínsecamente relacionadas por constituir un todo, como por ejemplo cuando se trata de un manual.

Dicha definición se hace utilizando el elemento <link> con el atributo "rel" o el atributo "rev", para indicar la relación directa o inversa entre dos documentos.

Los atributos "rel" y "rev" están siendo "descubiertos" por algunos autores, y esto está permitiendo el desarrollo de los llamados "microformatos", que están enriqueciendo semánticamente los contenidos y que se están difundiendo muy especialmente entre los "forofos" de los cuadernos de bitácora ("blogs") o abanderados de la llamada "blogosfera". Pero sorprende ver cómo en muchos, por no decir que en la mayoría de los sitios que abogan por el uso de estos microformatos, brillan por su ausencia las formas más básicas de interrelacionar semánticamente los contenidos mediante el uso del citado elemento "link". Por no hablar del "olvido" o desconocimento de muchos otros contenedores de metadatos, definidos ya hace desde las primeras especificaciones de HTML.

Algunos desarrolladores o autores Web conocen bien el elemento "link" en cuanto les permite indicar a los robots, que no indexen determinada página, y a los navegadores, dónde se encuentra la o las hojas de estilo, pero poco más. Muchos lo han descubierto al empezar a usar la sindicación o adentrarse en el mundo de los cuadernos de bitácora, pues en ellos se usa para identificar la relación entre entradas, los archivos, los temas, etc. (Véase, la definición de las etiquetas "link" en Atom.

Sinembargo, el uso del elemento "link" permite no sólo que los robots de búsqueda e indización indexen y localicen documentos relacionados, sino que los usuarios puedan navegar fácilmente entre ellos gracias a las barras de navegación que "deberían" proporcionar todos los navegadores y que, empiezan a implementarse realmente en todos ellos.

Barras de navegación

Parece que ya está al alcance de "todos" los autores y los usuarios la posibilidad de aprovechar las ventajas de la navegación semántica o meta navegación. Y digo que parece, porque realmente no he comprobado la situación de todos los navegadores existentes, pero creo que si Internet Explorer ha llegado ahí, y suele ser el último en aplicar los estándares, muy probablemente en todos los demás se haya implementado ya desde hace tiempo

El uso de estas barras de navegación puede simplificar mucho la misma para todos los usuarios e incluso ayudar, como veremos, a los diseñadores a obtener un diseño visual del sitio más "limpio" y bonito sin limitar un ápice su accesibilidad.

Las buenas noticias son que, para los navegadores que no cuentan con una barra de navegación por defecto u omisión, como la tuvo Mosaic desde la versión 3.0 y como la ha tenido desde hace años Opera, existen ya extensiones que nos permiten agregarles una. Contamos hoy con:

• Navegadores que tienen barra de navegación semántica por defecto:
  • Lynx
  • iCab
  • Opera 7.x Y 8.x
  • Mosaic 3.0
  • Mozilla
  • Netscape 6.0 (A partir de la 7.1 la perdió)
• Extensiones para otros navegadores:
  • Link Tool Bar = Para FireFox
  • Link Navigation Bar = Para Internet Explorer
  • SnufKin Browser = Para Internet Explorer

Esta lista evidentemente no está completa (Matthias Gudfeldt mantiene desde el año 2001 una página que da cuenta de la implementación de barras de navegación en diversos navegadores, y también Michael Nahrath en su sitio llamado Subotnik), así que si el lector tiene conocimiento de otros navegadores o extensiones, sería muy de agradecer que añadiera un comentario a este artículo compartiéndolo y de esa manera podremos añadirlo a la página en español de Sidar.

La metanavegación en la práctica

En el sitio del SIDAR, mantenemos desde hace años una sección sobre "Personalización" dentro de la sección de "Recursos", especialmente pensada para dar a conocer a usuarios, e incluso a los desarrolladores, las opciones de personalización de la navegación que tienen a su alcance desde su propio sistema operativo y navegador. Es una sección abierta a la participación de todos (como todas las del Seminario) a la que cualquiera puede contribuir.

En ella hay una página dedicada a la metanavegación, en la que se explica brevemente en qué consiste y cómo activar las barras de navegación en cada navegador. Para no alargarme, y puesto que el objetivo de este artículo no es explicar las cuestiones básicas sino ahondar en su aplicació en el momento actual, remito al lector a esa página para ver el listado de tipos de "link" (link types) comúnmente reconocidos, que el autor de una página web puede utilizar para establecer relaciones mediante el elemento <link>.

(Nota: Si el lector va al sitio de Sidar no debe decepcionarse al comprobar que allí también está infrautilizado el elemento Link. Se usa con profusión en todos aquellos documentos relacionados, como los que conforman manuales, pero deberían usarse más en el resto de las páginas del sitio. En su momento no se hizo porque la mayoría de los navegadores, por no decir ninguno, soportaba este elemento, pero la buena noticia es que estamos rediseñando todo el sitio y entonces se usarán cuanto se deba.)

Lo que realmente me interesa plantear ahora son las diferencias que podemos encontrar entre las distintas barras de navegación y, por ende, las limitaciones que pueden suponer a la hora de usar el citado elemento, ya que en su especificación y en la de los atributos que le sirven no hay limitación alguna y el autor puede crear sus propias relaciones. De hecho, es lo que se está haciendo con el atributo "rel" en los enlaces, por medio de los llamados microformatos que comentábamos antes.

Inconsistencia en el soporte entre navegadores

Como hemos visto, la especificación de los lenguajes (X)HTML indican una serie de tipos para el elemento "link" comúnmente aceptados, pero dejan en libertad a los autores para definir los que requieran.

Entonces nos encontramos con que las distintas barras de los navegadores no presentan por omisión el mismo número de botones de acceso a los enlaces definidos mediante ese elemento.

Tomando cuatro de los navegadores más usuados, las diferencias podemos resumirlas en que (Puede verse un ejemplo con ilustraciones):

Opera

Sólo muestra botones que se corresponden con los tipos reocogidos en la especificación, impidiendo acceder a aquellos que haya definido el propio usuario: Principal, Índice, Contenidos (Tabla de contenidos), Buscar, Glosario, Ayuda, Primera, Anterior, Siguiente, ültima, Arriba, Copyright, Autor. Aunque hay que notar que, por una parte "Buscar" no aparece en la especificación y por otra en la barra de Opera no aparece "Bookmark" que si está en la especificación como ejemplo.

Firefox

Presenta botones para "Top/Start" (la página principal del sitio), Primera, arriba, anterior, siguiente, última; y un desplegable llamado "más" en el que aparecerán todas las que faltan de entre las recogidas en la especificación y todas las que el autor haya definido.

Internet Explorer

Presenta botones para "Top/Start", "Toc/Contents", primera, anterior, siguiente, última, arriba, índice, buscar, copyright, autor, glosario, versiones alternativas, y un botón desplegable llamado "link" en el que aparecerán todos los definidos por el webmaster.

Mozilla

Presenta: "Top", Arriba, Primera, Anterior, Siguiente, Última; un desplegable para los definidos dentro del documento "Document", y otro para cualquiera definido por el autor "More".

Para colmo de males, la interpretación que hace cada barra de navegación de las indicaciones de tipo de enlace no es igual en todas ellas. Por ejemplo, tomemos la página de la especificación de HTML 4.0 en la que se explican los tipos de Link (en la modularización de XHTML se presenta una copia literal de estos) : Veremos que en Opera no se resalta el botón "Principal (en inglés Home)", porque requiere que esté expresamente definido un elemento link rel="home"...; en cambio, en Firefox aparecerá de forma automática resaltado el botón "Top" apuntando a la página inicial del sitio, aunque no hayamos usado ese tipo de enlace. (En realidad Opera está errada, pues el valor "home" está reservado para los navegadores y no debería ser usado por los autores.)

En Firefox aparece resaltado el botón "Up", automáticamente, aunque no está definido expresamente en el documento, y apuntando al nivel inmediatamente anterior al documento en el que no encontramos, no a la parte superior del documento que estamos leyendo, como intuitivamente cabría esperar. En las otras barras, no se resalta ese botón, porque no está definido en la página. Pero en realidad el comportamiento de la barra de Firefox es correcto pues por la definición del tipo "Top" sabemos que identifica el tope lógico de una jerarquía en árbol de la que el documento actual es una rama. Y sabemos también que el tipo "begin" es un equivalente si sólo uno de los dos está definido, al igual que "origin".

Usando esa misma página encontraremos más diferencias, y esto es de especial interés para el aprovechamiento o pérdida de los microformatos, que se supone tienen como principal objetivo al humano y no a la máquina, por ejemplo: Ni en Opera, ni en Mozilla, ni en Internet Explorer, tendremos acceso a ninguna de las relaciones establecidas mediante el atributo rel del elemento a y así perdemos la posibilidad de tener un acceso directo a las referencias bibliográficas relacionadas con el documento, que están muy hábil y útilmente marcadas como tal en la página de la especificación que estamos usando como ejemplo, y que sí podemos aprovechar si usamos Firefox.

Si yo defino un enlace al documento previo, aunque no defina enlace a ningún documento siguiente, en Firefox y en Mozilla se activará el botón "Next", aunque no nos lleve a ninguna parte. Al menos, cuando lo pulsamos no ocurre nada. En cambio, en Opera y en Internet Explorer, se activa el botón y encima nos llevan a una página de error. Al menos, en la barra de Internet Explorer se presenta junto al botón "next" un indicador de desplegable, en el que aparecen unos puntos suspensivos, puesto que no hay indicación de título para página siguiente. Este comportamiento en todos, me parece que es un error, aunque puedo estar equivocada, pero parece lógico que, si la página o documento actual es el último de una serie, no tenga indicación de página siguiente ("next") y no se active ese botón.

Class, un atributo no soportado

Algo que no soporta ninguno de los navegadores o sus barras, es el uso del atributo class en el elemento link, a pesar de que es estándar desde la especificación de HTML 3.0. Y es una pena, porque sería relmente útil para los usuarios. Lo cuál nos lleva a la necesidad de crear nuestros propios tipos de enlace para que, al menos, aparezcan de alguna manera, en las barras de los navegadores, relacionados los documentos que consideremos de una misma clase.

A ver, la cuestión es que, en teoría podríamos indicar una o varias clases de relaciones, utilizando el atributo class en el elemento link lo que debería dar como resultado que todos los de una misma clase aparecieran relacionados y juntos, pero a la vez eliminando la ambigüedad que provocaría que compartiesen un mismo valor en su atributo rel.

Esto sería especialmente útil para, por ejemplo, relacionar nuestro documento con todas sus fuentes bibliográficas, clasificadas temáticamente. También, por ejemplo, si el documento trata sobre una pieza de algo, relacionarlo con el resto de páginas que tratan sobre las piezas que conforman un todo, pero que a su vez pueden clasificarse en distintas categorías. En fin, las aplicaciones serína infinitas.

La ambigüedad se produce, como he dicho, cuando tenemos varios elementos link que comparten un mismo valor en su atributo rel de manera que en Mozilla e Internet Explorer, nos aparecerán varios enlaces con el mismo nombre, aunque apuntando a recursos distintos, siempre que el valor de rel no sea uno de los definidos en la especificación, porque en ese caso sólo ofrecerá uno de ellos. En la barra de Mozilla se crea una subcarpeta dentro de la carpeta "More" pero a su vez, dentro de ella, aparecen todos con el mismo nombre. En la barra de Internet Explorer aparecen todos con el mismo nombre en el desplegable "Link".

En resumen, que ninguna de las barras soporta este atributo que sería muy útil. Puede experimentarse con la página de ejemplos.

Y el único que soporta el atributo rev, para indicar relaciones inversas, es el Internet Explorer, bueno la extensión que han creado para él. Lo cuál significa una limitación importante en los demás navegadores. (Puede verse esto en la página de ejemplo con ilustraciones, en la que está indicada su relación inversa con esta que estás leyendo.)

Entonces, al parecer no se está aplicando en su totalidad los tipos definidos ya en varios documentos pero que no han quedado reflejados en la especificación de HTML 4.01 (Véase un listado extenso de "Link Types"). Aunque parece haber cierta coincidencia a la hora de aplicar algunos, como por ejemplo: "Search", para indicar dónde se encuentra el buscador en el propio sitio; "Author", que se usa o bien para indicar la dirección de correo electrónico del autor (en cuyo caso en la barra de Firefox aparece un bonito icono que representa una carta) o para indicar la página del autor, una biografía, un audio o videoclip del autor del documento; y "Up", para apuntar al nivel inmediatamente anterior en el sitio, como hemos visto antes.

Algunas propuestas "subversivas"

Se me ocurre una aplicación mucho más práctica, para los usuarios, de "Up/Arrriba", puesto que el nivel anterior a la página en la que nos encontramos puede estar ya enlazado mediante otro elemento, pues puede ser la página inicial, por ejemplo, y puesto que hay otros tipos que nos permiten definir ese nivel jerárquico: Que sirva para enlazar con el inicio del contenido del documento actual. Es decir, que en vez de ser un enlace externo al documento actual, sea un enlace interno. Esto supondría una facilidad de acceso para muchos usuarios, especialmente para quienes usan el teclado y usan Opera pues en este navegador tiene definido un atajo de teclado (Control+mayúsculas+retroceso) y, por otra parte, supondría un alivio para los diseñadores, que no tendrían que poner el dichoso botoncito o enlace para "arriba" cuando los documentos son extensos, con lo que sus diseños serína más limpios y bonitos. Claro que, por otra parte, en la mayoría de los navegadores está definida la tecla "Home" o "Inicio" para cumplir esta función

Otra propuesta "subversiva" es utilizar el rel="author" para enlazar con la página de contacto del sitio o con la sección en la propia página en la que se encuentre esa información (por ejemplo, el pie de página). De esta manera esa información estará siempre al alcance del usuario de manera más clara y sencilla de alcanzar. En realidad la propuesta no es tan subversiva, puesto que este tipo está pensado para identificar al autor y proporcionar más información sobre él, lo que en el caso de un sitio empresarial o de la administración pública, evidentemente nos llevaría a información sobre su carácter o personalidad jurídica, su localización, etc. Que es justo lo que se suele indicar como referencia de contacto. Y siempre podremos utilizar el atributo rev con un valor de tipo "made" para apuntar a otra página en la que se presente al autor o para usar el agente mailto: con la dirección de correo electrónico.

¿Por qué no, simplemente, utilizar un valor diferente para esto en el atributo rel, como "Contactar", por ejemplo?. Porque como hemos visto, no todos los navegadores aceptan las relaciones "de autor" y porque de esta manera se aprovechan los iconos predefinidos de las barras.

Limitaciones de idioma

Otra razón, para ajustarnos a los tipos definidos por las especificaciones son las limitaciones existentes para utilizar nuestro propio idioma a la hora de definir el valor, pues si lo hacemos se considerarán "de autor", a menos que creemos un "profile" en el que se defina la equivalencia de términos de un idioma a otro.

Si indico rel=up y tengo Opera en español me aparece el botón "Arriba" activado, pero si indico rel=arriba no aparecerá activado, aunque en los navegadores que soportan más opciones, aparecerá entre los de autor solamente, no en los que vienen por omisión.

Esto es así porque, evidentemente los navegadores atienden a la especificación en inglés y no hay una "traducción oficial" a otros idiomas, ni siquiera de los valores convencionales.

Por lo que no nos vendría mal a los hispanohablantes contar con un "profile" que apuntara a un esquema en el que se especificara la equivalencia de los tipos en español. Cosa a la que en este momento no puedo dedicar tiempo, así que si alguien se anima...

Propuestas de nuevos tipos (type)

Una alternativa a mi "subversiva" propuesta de usar "author" para apuntar a los datos de contacto, sería un nuevo tipo con el valor "Contact". Claro que podemos utilizar el castellano y definir "Contacto", siempre que creemos el esquema y lo identifiquemos con el respectivo atributo "profile". Pero quizás sería interesante que se incluyera en la especificación un nuevo tipo específico para esto, de manera que se incluyese por omisión en las barras de los navegadores.

Desde la Fundación Sidar y desde otras entidades internacionales llevamos años promoviendo que se utilice y se extienda el uso del elemento Link con un valor para el atributo rel llamado: "accessibility" y apuntando al informe de evaluación de la accesibilidad de la página. El informe, que deberá estar en formato "rdf" puede generarse fácilmente utilizando HERA u otra herramienta de revisión que pemirta la generación de informes utilizando el vocabulario EARL. Esto está ya siendo implantado como política en muchas empresas, y supone un avance importante para la accesibilidad pues permite comprobar hasta qué punto se han revisado las páginas, quién lo ha hecho y qué nivel de accesibilidad declara.

Por otra parte, y también con nuestra participación, en el grupo de trabajo sobre accesibilidad de DCMI se trabaja en una propuesta de un nuevo término: "Adaptability", el cuál permitiría indicar las características de accesibilidad y, expresamente, las opciones de adaptabilidad que se ofrecen para el documento o aplicación. Aunque esto, finalmente, se hará por medio de un elemento "meta".

Pero estos dos sistemas están dirigidos únicamente a que los informes sean entendidos por las máquinas, y aunque de HERA existe un script que permite que los informes generados en formato RDF se presenten de forma legible para los humanos en formato XHTML (Ver, script para informes), en realidad esto sólo tiene el propósito de que los usuarios puedan conocer el grado de cumplimiento de las directrices de accesibilidad. Pero los usuarios necesitan conocer, incluso, cuestiones básicas sobre las opciones de configuración y adaptación, por tanto de personalización, que le ofrece su sistema operativo y agente de usuario favorito.

Entonces la idea sería contar con un valor definido para el atributo rel del elemento link llamado: "Personalizar". Dicho valor se usaría para apuntar a una página en la que se desciben y/o se facilitan opciones de personalización a la hora de navegar por el sitio web. Una página, por ejemplo, como la que se ofrece en la sede web de la Asociación La Hoya de los Álamos, en la que hay un enlace a una página llamada "personalizar".

Este sería distinto del valor "alternate" que lo que hace es ofrecer acceso a una presentación alternativa del documento. Porque, si bien, puede ser interesante para los usuarios contar con diversas formas de presentación, que se acerquen o incluso se ciñan a sus necesidades, siempre será más positivo enseñar a pescar que dar un pez, es decir, siempre será más positivo darle información sobre cómo puede, él mismo, personalizar la presentación del documento y, en general, la navegación por Internet. Lo cuál no impide, ni quita valor, a las versiones alternativas que se puedan ofrecer, aunque hay que tener en cuenta que es imposible satisfacer, mediante versiones alternativas, todas las preferencias posibles de uso.

Un caso claro es el del alto contraste, y la reciente popularidad de la llamada "Zoom Layout" que no es ningún invento novedoso, y que desde luego sólo podrá satisfacer las necesidades de algunos de los usuarios que requieren del alto contraste, pues no existe una combinación que se ajuste a las necesidades de todos los usuarios con deficiencias visuales.

rel no indica un microformato

Como decía, muchos diseñadores o desarrolladores han descubierto el atributo rel usando en el elemento a gracias a los microformatos, por ejemplo para definir "etiquetas" que serán interpretadas por el servicio Technorati. Pero este atributo, que no es nada nuevo, puede y debe usarse para relacionar contenidos en nuestras páginas, sitios y servicios web. El valor de éste y de su inverso atributo rev debe ser un tipo de enlace (link type) previamente definido en alguna especificación estándar o en un "profile" creado por el autor, tal como hemos explicado antes.

Por ejemplo, desde siempre se ha utilizado el atributo rel=biblioentry para indicar las referencias bibliográficas, cuando se enlaza con un documento que actúa como tal. Lo que en las barras de navegación supone que se presentarán todas las referencias que hayamos hecho, juntas.

Y dado que el atributo puede usarse "libremente" (previa definición del esquema que le de sentido a su interpretación por cualquier agente) podríamos aprovecharlo para incrementar la accesibilidad "a" y "de" distintos elementos componentes de nuestras "páginas" web.

Aprovechando el atributo rel para la accesibilidad

Algunas de mis subversivas propuestas pueden verse en acción, aunque incorrectamente implementadas pues no he creado el correspondiente "profile" ;-), pero no por ello menos útiles para el usuario, en la sede web de la Asociación Los Álamos.

Otro aprovechamiento útil para la accesibilidad sería relacionar los típicos enlaces para saltar directamente al inicio del contenido y para ir al menú, mediante el atributo rel, de manera que aparezcan reflejados en las barras de navegación que admiten relaciones establecidas por el autor. De esta manera, el usuario no tiene la necesidad de subir hasta el principio de la página cada vez que quiere activar uno de esos enlaces.

Valores que el tiempo se llevó

Me da la sensación, tras la lectura de todos esos antiguos documentos que he citado, en los que se definen los tipos de enlace, que allá por el año 93 los autores tenían un concepto de la web mucho más inteligente y flexible del que luego se ha hecho realidad y que, hemos perdido algunos valores para los atributos rel y rev que sería interesante recuperar.

Es claro que la mayoría de los tipos de enlace no están soportados por todos los navegadores como cabría esperar. Y me parece claro también que algunos de ellos se ajustan más a la realidad de la web actual que el concepto que de ella se maneja generalmente. Me explico con un ejemplo: Se discute y sugiere utilizar marcado estructural para definir secciones de un menú de navegación. A mí no me convence porque creo que hay una serie de elementos en una página web que son el "contexto" del contenido principal y, por tanto, no merecen ese marcado estructural pero, a su vez, sí merecen un marcado semántico que en este momento no se está aplicando por lo general.

Un ejemplo claro es el tipo banner que se dejó en previsión de un elemento include que finalmente nunca se llegó a estandarizar, pero cuyo concepto es ampliamente utilizado hoy en día en las webs generadas mediante lenguajes de programación como PHP, por ejemplo.

¿Y qué importancia tiene esa pérdida? Algunas personas entienden un documento o página web, como un texto, un contenido que abarca la cabecera, el menú, el pie de página y el contenido en sí. Para mí, la cabecera, el menú y el pie de página, son en realidad el "contexto" del contenido principal. Y de hecho, cuando utilizamos un lenguaje de programación o un gestor de contenidos para generar una página web, esos 3 elementos son externos y se incluyen en cada una de las páginas mediante programación, pero cada págian en realidad contiene sólo el contenido principal y referencias a esos elementos externos para que "se pinten" cuando la página es llamada por un navegador.

Por tanto, deberíamos contar con tipos para el elemento link para relacionar esos contenidos incluidos. Es decir, la propuesta sería recuperar los tipos: banner y navigator, por ejemplo, y crear uno nuevo para el menú y para el pie de página que podrían llamarse: menu y foot, respectivamente.

Así un marcado semánticamente rico de nuestra página incluiría indicar:

Pero, como digo, ese concepto de una web en la que las páginas no son el equivalente digital de una página en papel, sino la interrelación de una serie de contenidos o elementos diversos, se ha perdido y hoy la mayoría de la gente piensa la web desde la perspectiva de las artes gráficas tradicionales.

Y otra cosa que me encantaría poder recuperar es el uso del atributo class en los elementos link.

Y bueno, se me quedan muchas ideas en el tintero, y pendientes la creación de algún que otro esquema para la traducción y creación de nuevos valores para el atributo rel, pero por el momento debo dejar aparcado todo esto y centrarme en otras cuestiones como ponencias que tengo por hacer y la organización de las IX Jornadas Sidar. Así que espero que el artículo anime a alguien para hacerlo y que todos podamos así aprovecharlo

Technorati Tags: Semántica, Microformatos, Accesibilidad, Web2.0