Armonía | En definitiva...

Hace algunas semanas se comenzó a discutir en la lista de correo del grupo AccesoWeb del SIDAR sobre cómo se debe marcar de forma semántica y correcta un poema, o una canción, con XHTML. Se vertieron muchas opiniones, todas muy interesantes, pero bajo mi punto de vista, y desde el de otros tantos en la lista, la forma correcta sería la que voy a explicar a continuación.

Normalmente, un poema o una canción se componen de estrofas, y cada una de estas estrofas está formada por uno o varios versos. En XHTML no existe ningún elemento que se encargue explícitamente de marcar este tipo de textos, por lo que habría que recurrir a elementos existentes para conseguir un marcado correcto y semántico, y además, que sea accesible. Ahora bien, ¿qué elementos son los correctos?

Bajo mi punto de vista, se puede considerar cada estrofa de un poema, o de una canción, como un párrafo normal de texto, con la salvedad de que las lineas están "partidas", no son contínuas. Una de las opciones contrarias al uso del elemento p para marcar las estrofas era usar el elemento pre, y escribir el poema tal y como se quiere que aparezca. Para mí esto no es una opción válida, ya que no se le da al poema un marcado semántico adecuado, se obvian los párrafos, etc.

A raiz de la sugerencia de usar pre, alguien apuntó el uso de párrafos, pero añadiendo la propiedad CSS white-space con el valor pre para "imitar" el resultado del elemento pre, pero sin usarlo. Desgraciadamente esta opción tampoco me parece correcta. Un usuario con CSS desactivado no podría comprender que lo que esta leyendo es un poema, ya que los versos desaparecerían y solo vería párrafos.

Para mí, la mejor opción es usar párrafos para marcar las estrofas, y saltos de línea para separar los versos. Parece un poco contradictorio, porque el elemento br suele estar desaconsejado cuando hablamos de XHTML y demás, pero creo que en este caso hemos encontrado una situación en la que es, además de correcto, aconsejable usarlo.

Usando esta forma, nos aseguramos de que los usuarios con CSS desactivado puedan leer correctamente el poema. Pero se nos plantea otro problema, ¿qué ocurre con los lectores de pantalla? ¿Cómo leerian el poema estos lectores? Es ahora cuando saltan a la palestra una serie de propiedades CSS normalmente desconocidas para la gran mayoría: los estilos aurales.

Estos estilos sirven para controlar la forma en la que los lectores de pantalla van a leer nuestro documento. Desde las pausas, hasta la velocidad, pasando por el tono, etc. Desgraciadamente muy pocos lectores de pantallan soportan este tipo de estilos. Aún así es algo que está ahí, y que hay que aprovechar, puesto que es importante.

Teniendo en cuenta todo lo comentado, y siempre según mi punto de vista, la forma más correcta para marcar un poema sería la siguiente:

<p>Siempre nos piden que entendamos<br />
el punto de vista de los otros,<br />
sin importar si es anticuado,<br />
necio,<br />
asqueroso.</p>

<p>A uno le piden<br />
que entienda<br class="pausa" />
amablemente<br class="pausa" />
todos los errores de los otros,<br />
sus vidas desperdiciadas,<br />
sobre todo si son de edad avanzada.</p>

<p>Pero su edad es lo único<br />
en lo que nos fijamos.<br />
Han envejecido mal<br class="pausa" />
porque han vivido sin enfoque,<br />
se han negado a ver.<br />
¿Que no es culpa suya?</p>

<p>Se me pide que oculte<br />
mi opinión ante ellos<br class="pausa" />
por miedo a su miedo.</p>

<p>La edad no es un crimen,<br />
pero la vergüenza de una vida<br />
deliberadamente desperdiciada<br />
entre tantas vidas,<br />
deliberadamente desperdiciadas,<br  class="pausa" />
sí lo es.</p>

Siendo su CSS:

.pausa {pause-after:700ms;}

Como veis, hago uso de un estilo CSS con la propiedad pause-after asociado a algunos elementos br del marcado del poema para determinar una pequeña pausa al final de ese verso. Obviamente esto es muy personal, y según como interpretemos que debe ser la lectura del poema, tendremos que jugar con más propiedades aurales de CSS, como pitch, volume, etc.

Por cierto, el poema es de Charles Bukowsky, y se titula "Siempre nos piden que entendamos...":

Siempre nos piden que entendamos
el punto de vista de los otros,
sin importar si es anticuado,
necio,
asqueroso.

A uno le piden
que entienda
amablemente
todos los errores de los otros,
sus vidas desperdiciadas,
sobre todo si son de edad avanzada.

Pero su edad es lo único
en lo que nos fijamos.
Han envejecido mal
porque han vivido sin enfoque,
se han negado a ver.
¿Que no es culpa suya?

Se me pide que oculte
mi opinión ante ellos
por miedo a su miedo.

La edad no es un crimen,
pero la vergüenza de una vida
deliberadamente desperdiciada
entre tantas vidas,
deliberadamente desperdiciadas,
sí lo es.

Nada más volver de pasar unos días en Sevilla, abro mi cliente de correo favorito, y me encuentro con la agradable sorpresa de que han publicado mi plugin generador de SiteMaps para DotClear en la lista de plugins para SiteMaps que mantiene Google.

Se han portado. Ahora a seguir mejorándolo y creando nuevas cosas, de las que os mantendré informado puntualmente.

Otro blog que visito a menudo, y cuyos contenidos realmente merecen la pena, (además del de Stan), es el blog de Pablo Viojo, un Uruguayo amante de los estándares Web, la accesibilidad, y todos esos temas que tanto nos gustan por aquí.

Su blog, llamado Concept&Development, tiene un diseño minimalista pero muy cuidado. De fácil lectura, temática variada aunque principalmente sobre tecnologías Web, y con una expresión clara y sencilla que permite una lectura y comprensión estupenda de sus contenidos.

Desde aquí os animo a visitarle, y a que le apoyeis en su proyecto blogsuy.net:

Hace un tiempito me vino la idea a la mente de hacer un directorio de weblogs uruguayos y casi al mismo momento Stan me sugirió la misma idea.

La idea es armar un directorio de blogs uruguayos, de modo de conocer bloggers de esta parte del mundo. Por ahora lo único que hay es un logo y un dominio blogsuy.net.

Pasado más de un mes desde que los pedí, hoy han llegado los CDs gratuitos de Ubuntu 5.04 Hoary Hedgehog. En realidad la tengo instalada desde que fue anunciada oficialmente la salida de su versión estable, pero siempre hace ilusión que lleguen estas cositas, para tenerlas uno mismo y para repartirlas como un buen evangelizador.

En este nuevo texto sobre la carga semántica en los elementos de XHTML vamos a hablar sobre tres elementos del grupo que forman los elementos de formulario. Concretamente veremos los elementos fieldset, legend y label.

Tengo una duda bastante grande sobre la carga semántica en estos tres elementos, puesto que no tengo claro si puede llamarse "semántica" a lo que estos elementos nos ofrecen. Sea como sea, son elementos importantes que se deberían tener en cuenta siempre que en nuestros documentos tengamos pensado incluir algún formulario.

El primero de estos elementos, fieldset, sirve para agrupar campos de un formulario que esten relacionados entre sí. Hay que destacar que tanto la etiqueta de apertura como la de cierre son obligatorias, y que debe situarse dentro de un formulario marcado con su correspondiente elemento form.

Veamos un sencillo ejemplo del uso de este elemento:

<form id="formularioEjemplo" method="post" action="http://www.mipagina.com/accion.php">
  <fieldset title="Formulario de ejemplo">
    <legend>Prueba este formulario de ejemplo</legend>
    <label for="campo">Campo:</label><input type="text" id="campo" />
    <input type="submit" id="enviar" value="Enviar datos" />
  </fieldset>
</form>

Como podeis ver, es el ejemplo más simple que os encontrareis en mucho tiempo, y es poco probable que en un documento de verdad haya algo así, pero seguro que os haceis una idea.

En formularios más grandes, con más campos, el uso de fieldset se vuelve indispensable. Imaginad por un momento que tenemos un formulario para guardar datos de nuestros visitantes. Queremos guardar sus datos personales, y las respuestas que ellos nos van a proporcionar a una serie de preguntas a modo de encuesta. En este caso se debería usar al menos dos fieldset, el primero de ellos para agrupar todos los campos relacionados con los datos personales del visitante. El segundo englobaría las preguntas a realizar.

Gracias a este elemento se facilita mucho la comprensión y el orden en los formularios, además de aumentar su accesibilidad, más aún si le añadimos atributos como title, con un texto explicativo sobre la finalidad de los campos que engloba, o la acción que se va a realizar, o simplemente describiendo un poco el formulario.

Si os habeis fijado bien en el ejemplo anterior, aparece el elemento legend, y su manera de usarlo. Es un elemento muy simple, pero de mucha utilidad, ya que nos permite etiquetar el grupo de campos que estamos englobando con el fieldset.

Este elemento ha de estar siempre dentro de un fieldset, y ha de tener la etiqueta de apertura y la de cierre obligatoriamente. Con respecto a su contenido, como ya he dicho antes, lleva un texto informativo que da una idea rápida al usuario del fin de los campos contenidos.

Por último hablaremos del elemento label, que también aparece en el ejemplo anterior. Este elemento es, como los anteriores, de gran importancia en los formularios, ya que nos aporta una serie de ventajas, tanto de accesibilidad, como de sentido a la hora de comprender el formulario.

El elemento label sirve para relacionar un campo del formulario con un texto identificativo. Esto nos permite asociar, por ejemplo, una caja de texto que debe contener el nombre del visitante que rellena el formulario, con un texto identificativo que nos especifica que en ese campo debe ir el nombre. Veamos el ejemplo para tenerlo más claro:

<label for="nombre">Nombre:</label><input type="text" id="nombre" />

Como podemos ver, estamos relacionado un label a una caja de texto que va a contener el nombre del visitante. Para identificar visualmente a esta caja de texto hemos elegido el texto "Nombre:". Será este texto el que debamos marcar con label. La forma de asociar un label con el campo correspondiente se hace mediante el atributo for del elemento label. En dicho atributo se debe colocar el identificador del campo con el que lo deseemos relacionar. En el ejemplo anterior hemos colocado el id del input, que era "nombre".

Se podría hablar largo y tendido de las ventajas de usar estas etiquetas, de pequeños trucos para aumentar su usabilidad, de diferentes formas de usarlos, etc. Pero creo que la idea básica ya ha quedado explicada. Sólo me quedo con la duda de si se pueden considerar elementos semánticos dentro de XHTML. ¿Vosotros qué opinais?

And you don't seem to understand
A shame you seemed an honest man
And all the fears you hold so dear
Will turn to whisper in your ear
And you know what they say might hurt you
And you know that it means so much
And you don't even feel a thing

I am falling, I am fading
I have lost it all

And you don't seem the lying kind
A shame then I can read your mind
And all the things that I read there
Candle lit smile that we both share
and you know I don't mean to hurt you
But you know that it means so much
And you don't even feel a thing

I am falling, I am fading, I am drowning
Help me to breathe
I am hurting, I have lost it all
I am losing
Help me to breathe

He decidido crear una serie de posts para presentaros a los blogs que más me gustan de la blogosfera hispana. Principalmente de blogs que se han interesado en el mío, que se han molestado en escribir comentarios, que me han hecho ver mis errores, que me han enseñado, etc.

El primero de ellos es el blog de Estanislao Vizcarra, (más conocido como Stan). Un blog con un diseño limpio, sencillo, atractivo y cómodo. En su blog, Stan nos habla de todo un poco, desde cine hasta estándares Web. Tiene una forma agradable de contar las cosas, y él mismo es una persona agradable, lo cual queda reflejado en su blog. Y una cosa importante, actualiza casi a diario, lo cual es de agradecer. Además está trabajando en un proyecto muy interesante, sa.bros.us.

No dudeis en visitarle, lo merece.

A estas alturas ya todos conocereis el nuevo servicio de Google para webmasters llamado SiteMaps. A grandes rasgos se basa en el envío a Google de un fichero XML con las URL de todas tus páginas, algo así como un "mapa de tu sitio web", (SiteMap). Gracias a ese fichero, Google tendrá un acceso más sencillo y controlado a todas las páginas de tu Web, facilitando así su indexación, etc.

Pues bien, gracias a la ayuda de Richard, he creado un plugin para DotClear que genera este fichero de forma automática para poder facilitar a Google la indexación de tu blog.

La instalación es muy sencilla, tan sólo hay que copiar el fichero sitemap.php en el directorio raiz de tu instalación de DotClear. Posteriormente debes irte al sitio Web de SiteMaps y darle la URL a dicho fichero.

La generación del XML es configurable, pudiendo decidir si queremos incluir en el fichero las URL de nuestros feeds, de la página principal del blog, las URL a las categorías que lo forman, etc. Para un listado completo de las opciones sólo teneis que echar un vistazo a los ficheros README en el paquete, (la traducción al francés del README corre de la cuenta de Richard. ¡Gracias!).

Aquí os dejo los enlaces. Teneis a vuestra disposición el plugin comprimido en ZIP y en TAR.GZ, para que escogais el que más os guste. Para cualquier duda, sugerencia o lo que sea, ya sabeis dónde encontrarme.

• SiteClearMap.zip
• SiteClearMap.tar.gz

Actualización [16/06/2005 13:21]

Corregidos algunos bugs menores.

Actualización [16/06/2005 16:56]

Mejoras en la programación del plugin. Ahora se hace uso de los objetos propios de DotClear para generar las consultas.

Añadido el fichero README traducido al inglés

Navegando por ahí me he topado con un artículo excelente y muy completo sobre cómo funcionan la opacidad y las transparencias en CSS.

Un aspecto del CSS que no creo que esté todavía maduro para usar, pero siempre viene bien investigar, comprobar, hacer experimentos, etc. Es la mejor forma de aprender.

Retomamos el tema de la carga semántica en XHTML con una serie de elementos que, curiosamente, forman parte del módulo presentacional del Document Type de XHTML, por lo que, en teoría, su carga semántica es nula. Aunque personalmente, hay un par de elementos que para mi modo de ver, si tienen sentido semántico. Es por esto que quiero mostraros el sentido de estos elementos.

Los elementos b, i y tt

Como ya he dicho antes, estos elementos son presentacionales, por lo que no aportan ningún tipo de semántica a nuestro documento, pero si nos permiten dar un poco de formato a lo que escribimos. Se ha dicho muchas veces que todo lo relacionado con la presentación se debe manejar con CSS Si bien estoy de acuerdo con esa afirmación, también estoy de acuerdo en que si XHTML nos ofrece este módulo, es totalmente lícito usarlo.

El elemento b, de bold en inglés, nos permite poner en negrita un texto. Hay que recordar que es un elemento en linea, y que la etiqueta de apertura como la de cierre son obligatorias.

<p>Lo siguiente es un <b>texto en negrita</b></p>

No hay que confundir este elemento con el elemento strong, aunque su renderizado por defecto sea el mismo, su sentido semántico es distinto. El elemento b no tiene ningún tipo de sentido semántico, mientras que strong nos proporciona un enfásis sobre el texto marcado.

Por otro lado tenemos el elemento i, que funciona de la misma forma que el anterior, pero el efecto presentacional que representa es la letra cursiva. También hay que recordar que aunque su renderizado por defecto sea igual que el del elemento em, carece del sentido semántico de este último.

<p><i>Esto es un texto en cursiva</i></p>

Para finalizar este grupo, comentaremos el elemento tt. El elemento tt nos permite marcar el texto para mostrarlo con una fuente monoespaciada, o de teletipo. Este elemento, al igual que los otros, también puede ser usado erroneamente debido a su forma de renderizado. Al mostrarse con una fuente monoespaciada, tiende a confundirse con el elemento code, usado para marcar código fuente dentro de nuestro documento.

<p><tt>Esto es un texto con fuente monoespaciada</tt></p>

Los elementos small y big

Con estos elementos ya entramos un poco más en la discusión sobre si ofrecen sentido semántico o no. Como vereis ahora, no alteran el significado del texto marcado, pero si cambian un poco su relevancia.

El elemento big se usa para aumentar el tamaño del texto marcado. Al aumentar su tamaño, se puede decir que aumentamos su importancia dentro del documento. Es por esto por lo que no lo considero un elemento meramente presentacional. Aunque sólo afecte a la presentación, tiene cierto sentido semántico al permitir su uso para cambiar la importancia de un texto del documento.

<p>Esto es un texto normal. <big>Esto es un texto grande</big></p>

El elemento small sirve para justo lo contrario que el anterior, disminuye el tamaño del texto marcado. Al disminuir su tamaño se puede usar para quitar relevancia al texto marcado.

<p>Esto es un texto normal. <small>Esto es un texto pequeño</small></p>

Si quereis ver un poco más de estos dos elementos os recomiendo este artículo de mini-d.

Los elementos sup y sub

Aquí ya es dónde encontramos los elementos de la discordia. Los elementos sobre los que pienso que tienen un carácter semántico muy marcado, a pesar de estar dentro del módulo presentacional de XHTML.

Estos elementos se usan para marcar textos en superíndice y en subíndice respectivamente. Es por eso que yo me pregunto, ¿significa lo mismo un texto estando normal que estando en subíndice o en superíndice? Ahi tenemos los números en potencia, o las marcas para señalar notas al pie, o bien los números en las fórmulas químicas, etc.

Pero no voy a entrar en polémica. Así que simplemente os voy a poner un par de ejemplos del uso de estos dos elementos.

<p>Texto normal y <sup>superindice</sup></p>

<p>Texto normal y <sub>subindice</sub></p>