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.

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?

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>

Siguiendo con el tema de la semántica en las etiquetas XHTML, ahora es el turno de las etiquetas dedicadas a la marcación de listas en nuestros documentos. Estas etiquetas son ul, ol, li, dl, dt y dd, (al menos en la versión actual de XHTML, en el borrador de XHTML 2.0 hay un par de añadidos que comentaré en otra ocasión).

Siempre que nuestro documento vaya a contener una lista de cualquier tipo, deberemos marcarla con alguna de estas etiquetas. Una lista puede ser, por ejemplo, la lista de la compra, una receta de cocina, las características de un ordenador, o cualquier otra cosa que se nos ocurra.

Cuando pensemos en listas, normalmente deberemos pensar en dos elementos. En el conjunto global de la lista, y en los elementos que la forman. En el caso de las listas de definiciones, (dl), los elementos que forman la lista se dividen en dos, el título de la definición, (o símplemente "término"), (dt), y la definición en si misma, (dd), pero esto ya lo detallaré más adelante.

En principio, el uso de las listas en HTML o XHTML es muy limitado, simplemente podemos identificar la lista y marcarla, junto con sus elementos. Pero gracias a CSS las posibilidades de las listas se multiplican de forma bestial. Por ejemplo, normalmente los menus de las páginas maquetadas con tablas son simplemente celdas de alguna fila, o cualquier otra cosa de ese tipo. Esto, fuera de toda duda, es totalmente incorrecto. La forma más correcta, por ahora, de hacer menús de este tipo es usando precisamente listas. Al fin y al cabo, un menú no es más que una serie de elementos, una lista de elementos. Una vez marcado correctamente el menú, con CSS podemos hacer que aparezca como queramos. En horizontal, sin los marcadores, (bullets), con color de fondo, borde, etc.

Listas ordenadas: ol, li

El primer tipo de lista que voy a comentar es la lista ordenada. Este tipo de lista debe usarse para listas en las que el orden de los elementos es marcadamente importante. El ejemplo más habitual es una receta de cocina, (una lista de pasos a seguir para cocinar algo). En este tipo de listas se pretende destacar, además de el hecho de que se trata de una lista, el orden de aparición de los elementos.

Normalmente, los agentes de usuario renderizan este tipo de listas colocando números automáticamente y de forma ordenada para cada elemento de la lista, por lo que es totalmente innecesario colocarlos a mano:

Ejemplo incorrecto:



<ol>

	<li>1.- Primer paso</li>

	<li>2.- Segundo paso</li>

	<li>3.- Tercer paso</li>

</ol>

Ya que se mostraría así:

1. 1.- Primer paso
2. 2.- Segundo paso
3. 3.- Tercer paso

Obviamente, se podría retocar con CSS para ocultar la numeración propia del elemento ol, pero me parece una pérdida de tiempo, además de algo absurdo y una forma horrenda de usar las herramientas de las que disponemos.

Viendo este ejemplo os habreis dado cuenta de que hago uso del elemento li. Como podeis comprobar se usa para marcar los elementos que componen la lista, tanto en listas ordenadas, (ol), como en listas desordenadas, (ul), que veremos a continuación.

Para mostrar un ejemplo de un buen uso de una lista ordenada, haré una para la receta de preparación de un huevo frito, ya que es importante el orden para hacerlo:

<ol>

	<li>Verter abundante aceite de oliva en una sart&eacute;n y ponerla al fuego.</li>

	<li>Coger un huevo fresco de la nevera, cascarlo y, teniendo el aceite ya caliente en la sart&eacute;n, echarlo con cuidado.</li>

	<li>Dejar un par de minutos friendo hasta dejarlo en el punto deseado.</li>
	<li>Sacar del aceite con una espumadera y servir en un plato con un buen trozo de pan.</li>

</ol>

Lo que daría como resultado lo siguiente:

1. Verter abundante aceite de oliva en una sartén y ponerla al fuego.
2. Coger un huevo fresco de la nevera, cascarlo y, teniendo el aceite ya caliente en la sartén, echarlo con cuidado.
3. Dejar un par de minutos friendo hasta dejarlo en el punto deseado.
4. Sacar del aceite con una espumadera y servir en un plato con un buen trozo de pan.

Listas desordenadas: ul, li

Este tipo de listas, a mi entender, es el más usado de todos. Este elemento, ul, está destinado a marcar listas desordenadas, en las que solo nos interesa resaltar el hecho de que los elementos forman una lista, independientemente del orden de dichos elementos.

La manera de renderizar este tipo de listas por parte de los agentes de usuario es, normalmente, mediante un punto redondo, llamado marcador, o bullet en inglés. Aunque, como digo, esta forma no es la única, ni la por defecto en todos los agentes de usuario. Además, gracias a CSS, este marcador se puede cambiar por otros tipos, (circulo vacío, un cuadrado, una imagen que nosotros queramos, etc.), usando la propiedad list-style-type. Pero al tratamiento de listas con CSS ya hablaré en otro post de forma más amplia.

Un ejemplo muy simple, y perfectamente correcto, del uso de las listas desordenadas puede ser el marcado de una lista de la compra:

<ul>
	<li>Patatas</li>
	<li>Pimientos</li>
	<li>Lechuga</li>

	<li>Ajos</li>
	<li>Filetes de cerdo</li>

</ul>

Lo cual sería renderizado de la siguiente forma, (teniendo en cuenta los estilos que en mi blog aplico a las listas desordenadas):

• Patatas
• Pimientos
• Lechuga
• Ajos
• Filetes de cerdo

Listas de definiciones: dl, dt, dd

Para terminar, existen las llamadas listas de definiciones, que son, a mi entender, las menos usadas de todas. Sirve para marcar listas de definiciones, somo su propio nombre indica. La mejor forma de ver qué es, y cómo se usa una lista de definiciones es viendo un ejemplo:

<dl>
	<dt>Patata</dt>
	<dd>Tub&eacute;rculo de color marr&oacute;n, originario de Am&eacute;rica y muy usado para cocinar.</dd>
	<dt>Aceite</dt>

	<dd>L&iacute;quido que se obtiene a partir de la aceituna, usado comunmente para cocinar.</dd>
	<dt>T&eacute;</dt>
	<dd>Arbusto del que se obtienen las hojas de la popular infusi&oacute;n con el mismo nombre.</dd>

</dl>

La forma en la que los agentes de usuario renderizan este elemento es ligeramente diferente a la del resto de elementos de lista. Para este elemento no se dibujan marcadores, (bullets), y se mantiene un sangrado general, más pronunciado en la definición en si, (elemento dd). Podemos ver el resultado a continuación:

Patata

Tubérculo de color marrón, originario de América y muy usado para cocinar.

Aceite

Líquido que se obtiene a partir de la aceituna, usado comunmente para cocinar.

Té

Arbusto del que se obtienen las hojas de la popular infusión con el mismo nombre.

Otro uso correcto que puede darsele a este elemento es para marcar diálogos, dónde el nombre de cada participante se marcará con el elemento dt, y sus palabras con dd.

Después de muchos días sin escribir vuelvo a la carga con una pequeña revisión a los elementos blockquote y q, usados para marcar citas textuales de otras referencias en nuestros documentos XHTML, (HTML también, por supuesto).

Ambos elementos se usan para lo mismo, para marcar citas textuales, pero se diferencian entre si por el hecho de que blockquote es un elemento en bloque, y q un elemento en línea. Por tanto, blockquote se usa para citas textuales largas, usualmente varias líneas. Y q se usa para citas textuales cortas, de algunas palabras.

Los atributos más interesantes para estos dos elementos son cite y xml:lang, (lang también si estamos usando versiones anteriores a XHTML 1.1). Usando el atributo cite podemos especificar una URI con un documento que aporte información sobre la cita textual que estamos realizando. Su uso es sencillo, veamos el ejemplo que se usa en las especificaciones del W3C:

<blockquote xml:lang="en" cite="http://www.mycom.com/tolkien/twotowers.html">
<p>They went in single file, running like hounds on a strong scent,
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.</p>
</blockquote>

Como podemos ver, hemos citado textualmente un párrafo de Las Dos Torres de J. R. R. Tolkien. Hemos usado el atributo cite para referenciar una supuesta URI con información sobre esa parte del libro, o directamente el capítulo dónde aparece, o cualquier otra cosa referente al párrafo que hemos citado.

Si miramos bien también vemos el atributo xml:lang, para especificar que el texto está en inglés. Gracias a este atributo, los agentes de usuario, (navegadores, para que nos entendamos), deberían colocar las marcas tipográficas adecuadas para el idioma que estamos citando, ya que, por ejemplo, las marcas tipográficas para las citas no son las mismas en castellano, («»), que en ingles, (""). Pero esto no es así, aunque gracias a CSS podemos solucionarlo.

En el blog de Federico hay un excelente post informativo sobre el tema de las comillas para las citas usando CSS para conseguirlas, (el se centra en los elementos en bloque). En su artículo hay algunos enlaces que tratan lo mismo, pero centrandose en los elementos en línea, por ejemplo este artículo en el blog de Manuti.

Siguiendo con el tema de la carga semántica en las etiquetas XHTML, hoy me gustaría hablar de cuatro etiquetas poco conocidas, usadas principalmente en contextos informáticos. Estas etiquetas son: code, kbd y samp.

Empezaremos hablando de code, que ha de utilizarse, según las especificaciones del W3C, para designar un fragmento de código de computador. Atendiendo a esta definición, podemos determinar que usaremos la etiqueta code para marcar cualquier trozo de código fuente que coloquemos en nuestros documentos.

Si miramos el código fuente de este blog, encontraremos probablemente varios ejemplos del uso de code. A continuación pongo un ejemplo específico para un trozo de código embebido dentro de un párrafo.

<p>En tu caso falta inicializar <code>$contador = 1;</code></p>

Que daría como resultado:

En tu caso falta inizializar $contador = 1;

Otra etiqueta que usaremos probablemente a menudo si escribimos sobre temas informáticos será kbd. Esta etiqueta se debe usar para marcar texto que el usuario deba introducir en el ordenador mediante el teclado, bien sea en un formulario, en una consola, en una barra de direcciones, etc.

Un uso muy extendido para esta etiqueta es colocarla cuando se quiere mostrar un atajo de teclado, al estilo Ctrl + Alt + Supr. Y posteriormente aplicarle estilos a esta etiqueta desde CSS para imitar el aspecto de una tecla del teclado, (como explica mini-d en este post).

A continuación un par de ejemplos del uso de kbd, el primero para mostrar un texto que se debe introducir, y el segundo para marcar un atajo de teclado.

<p>Para actualizar su sistema <cite>Debian</cite> introduzca <kbd>apt-get dist-upgrade</kbd> en su consola</p>

Que daría como resultado:

Para actualizar su sistema Debian introduzca apt-get dist-upgrade en su consola

Y ahora el ejemplo para representar un atajo de teclado:

<p>Para cerrar la ventana activa se suele utilizar <kbd>Alt</kbd> + <kbd>F4</kbd></p>

Que daría como resultado:

Para cerrar la ventana activa se suele utilizar Alt + F4

Otra etiqueta que, por ejemplo, estoy usando en este post, es samp, usada para marcar un ejemplo de salida para un programa, un script, etc. Esto es muy útil, por ejemplo, cuando queremos mostrar un mensaje de error que nos devuelve un comando Linux, o cuando debemos marcar cualquier texto que un programa nos devuelva. Aqui va un ejemplo:

<p>Al pulsar sobre el icono se muestra el siguiente texto: <samp>Elija un numero del 1 al 10</samp></p>

Dando como resultado:

Al pulsar sobre el icono se muestra el siguiente texto: Elija un numero del 1 al 10

Bueno, esto es todo, espero que os haya servido de algo este otro pequeño paso en nuestro repaso por la carga semántica de las etiquetas que componen el XHTML.

<p><code> if (document.getElementById) <var>blnDOM</var> = true; </code></p>

Volviendo al tema de la carga semántica de las etiquetas XHTML, hoy me gustaría hablar de la etiqueta abbr. Quizá lo más lógico hubiese sido hablar de abbr en el mismo post en el que hablé de acronym, pero pero quise separar las distintas etiquetas en distintos posts para tener más claro y separado el concepto de cada una.

Como siempre, para saber en que ocasiones debemos usar una etiqueta u otra, tenemos que tener clara la idea de lo que significa el texto o la palabra que queremos marcar y las herramientas de las que disponemos. En el caso de XHTML, las herramientas que poseemos son las etiquetas. Como aqui vamos a hablar de abbr, lo primero que debemos hacer es entender para qué sirve esta etiqueta.

Segun las especificaciones del W3C, abbr debe ser usado para marcar formas abreviadas de palabras o grupos de palabras. O lo que es lo mismo, abreviaturas. Ahora, para poder comprender bien el uso de esta etiqueta, y sabiendo que su función es marcar abreviaturas, debemos asegurarnos de comprender el significado de esto último. Segun la RAE:

abreviatura.

1. Tipo de abreviación que consiste en la representación gráfica reducida de una palabra mediante la supresión de letras finales o centrales, y que suele cerrarse con punto; p. ej., afmo. por afectísimo; íd. por ídem; SS. MM. por Sus Majestades; D. por don.

2. Palabra representada en la escritura de este modo.

Conociendo todo esto, ya sabemos como marcar nuestro texto para formar un buen XHTML, y esta misma fórmula sirve tanto para abbr como para cualquier otra. Pero como estamos hablando de la primera, vamos a poner algunos ejemplos prácticos:

<p><abbr title="A la atenci&oacute;n de">Att.</abbr> <abbr title="Don">D.</abbr> Juan Antonio Navarro</p>

Este ejemplo de arriba quedaría como:

Att. D. Juan Antonio Navarro

Bueno, creo que esto es todo. Me gustaría recordar una pequeña regla que uso yo para diferenciar cuándo debo usar abbr y cuando acronym. Todas aquellas palabras que se abrevian usando un punto al final, (P. ej. Barriada, que pasa a ser Bda.), son, a mi entender, abreviaturas, y por tanto uso abbr. Para el resto, (P. ej. Extended Hypertext Markup Language, que pasa a ser XHTML), uso acronym.

Recordar que es una regla personal, y que para mi es correcta. Pero no soy un experto lingüista y puedo estar equivocado en los conceptos de abreviatura y acrónimo.

Los dos últimos artículos de A List Apart me han dejado maravillado. Son dos técnicas avanzadas, pero a la vez tan simples y lógicas, que no puedo más que quitarme el sombrero y aplaudir, (cosa común cuando hablamos de A List Apart).

Los artículos en cuestión son:

• Javascript Triggers
• Validating a custom DTD

Siendo sinceros, yo no soy muy partidario del uso de Javascript, aunque a veces no dudo que venga genial, sea útil, y hasta bonito. Pero aún asi no me convence, (será mi vena fundamentalista). A pesar de ello, el comienzo del primer artículo es genial. Habla de la separació entre contenido, presentación y comportamiento. Tres capas distintas, que jamás deberían mezclarse. Cada una de ellas corresponde a una tecnología distinta:

• XHTML para la capa de estructura, semántica y contenido.
• CSS para la capa presentacional.
• Javascript para la capa de comportamientos, (behaviors).

Simple, directo al grano, y a mi entender, dando en el clavo. Aunque obviamente el artículo no habla expresamente de esto, pero es el concepto con el que prefiero quedarme. El resto no es más que una técnica, fantástica, eso si, pero nada más. Sea como sea, bravo por A List Apart, una y mil veces.

Este post no va a ser muy largo, puesto que las etiquetas que voy a comentar, (p, em y strong), no son excesivamente complicadas, y además son de las que más se suelen usar. Pero de todas formas me gustaría comentar algunos detalles que creo que son bastante importantes a la hora de escribir nuestros documentos XHTML.

Para empezar, hablaré de la etiqueta p. Su uso es muy simple, se utiliza para determinar párrafos de texto. Cada párrafo de texto que tenga nuestro documento, deberá estar encerrado en esta etiqueta. Mucha gente se olvida de esto, y marca sus párrafos simplemente colocando saltos de linea, (br). Esto, además de muy cutre, es ilógico. ¿Por qué no usar una etiqueta expresamente creada para marcar párrafos, si precisamente lo que queremos es hacer eso? Un ejemplo simple de cómo usar esta etiqueta sería:

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit,sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi
enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis
nisl ut aliquip ex ea commodo consequat.</p>

<p>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie
consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et
iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore
te feugait nulla facilisi.</p>

Otra etiqueta que se suele usar mucho, pero que se usa la mayoría de las veces de forma incorrecta es la etiqueta em. Según el W3C, la etiqueta em sirve para dar énfasis a una determinada palabra o frase. Desgraciadamente, dar énfasis a una palabra o frase no es simplemente ponerla en cursiva, que es para lo que se suele usar esta etiqueta comunmente. Dar énfasis a una palabra o frase es marcar de forma distintiva los puntos más importantes de un texto. Un ejemplo del uso adecuado de em podría ser:

<p>El jam&oacute;n de Jabugo es <em>el jam&oacute;n m&aacute;s rico de Espa&ntilde;a</em></p>

Por último comentaré la etiqueta strong. No hay mucho que decir, habiendo explicado ya em. Al igual que esta, se usa para dar énfasis a una palabra o frase, con la diferencia de que strong le da aun más peso que la primera. Un ejemplo válido sería:

<p>Hace dos d&iacute;as entren&eacute; durante <strong>m&aacute;s de 3 horas</strong></p>

Seguimos con la racha de etiquetas XHTML con carga semántica, y esta vez le toca el turno a la etiqueta cite. Al igual que hice con las anteriores, (acronym, headings), para entender correctamente el significado de esta etiqueta he recurrido a la Web de la RAE, y esto es lo que he obtenido:

cita.

1. f. Señalamiento, asignación de día, hora y lugar para verse y hablarse dos o más personas.

2. f. Reunión o encuentro entre dos o más personas, previamente acordado. "Trabajaron mucho en su primera cita".

3. f. Nota de ley, doctrina, autoridad o cualquier otro texto que se alega para prueba de lo que se dice o refiere.

4. f. mención.

mención

1. f. Recuerdo o memoria que se hace de una persona o cosa, nombrándola, contándola o refiriéndola.

Lo primero que uno "entiende" al leer la etiqueta cite es "cita", asi que fue eso lo primero que busqué en el diccionario, pero no encontre nada que me llevara donde yo quería, excepto la cuarta acepción, "mención", me fuí a por ella, y lo que encontré si que me pareció lógico. Por lo tanto, hasta ahora creo que estaremos de acuerdo en que la definición correcta para la etiqueta cite es el significado de la palabra "mención".

Entendiendo el significado de esto, ya tenemos cómo usar cite. Pongamos unos ejemplos:

Musashi Miyamoto es el protagonista del manga japonés Vagabond, cuyo autor es Takehiko Inoue.

Como podemos ver, en este ejemplo hacemos mención a dos personas y a un objeto. La primera, Musashi Miyamoto, luego mencionamos el manga Vagabond, y por último a su autor, Takehiko Inoue. Veamos como escribiriamos esto en nuestro código XHTML:

<p>
	<cite xml:lang="ja">Musashi Miyamoto</cite> es el protagonista
	del manga japonés <cite xml:lang="en">Vagabond</cite>,
	escrito por <cite xml:lang="ja">Takehiko Inoue</cite>
</p>

Observando el ejemplo podemos ver el uso de cite. La etiqueta de cierre es obligatoria, y siempre que la mención sea en un idioma distinto al de nuestro documento, haremos uso de lang o xml:lang para especificar el idioma del texto. También, aunque en el ejemplo no lo use, se puede hacer uso de la propiedad title para especificar alguna nota sobre la mención que estamos realizando. Mucha gente usa esta propiedad para colocar la traducción al idioma del documento del texto encerrado entre la etiqueta, (siempre que esté en otro idioma, claro). A mi esto no me parece correcto, ya que, si a la etiqueta le especificamos un idioma diferente con lang o xml:lang, el title que le pongamos se supone que tambien entraría dentro de ese idioma especificado. Pero bueno, como no lo tengo claro oficialmente, podeis tomar vuestra propia decisióon con respecto al tema.

Para XHTML 2.0 he visto que se añade una propiedad más, una llamada cite, (si, igual que la etiqueta), en la cual se pondría una URL referente a la mención que estemos haciendo, (si procede ponerla, claro).