Comunidad de diseño web y desarrollo en internet online

Migración rápida a XHTML

Bienvenido al Mundo Real.
The Matrix. Morfeo, capitán de la Nabucodonosor

Si ya usabas HTML 4, puedes aprender muy rápido XHTML, puesto que las bases son las mismas. Sólo hay que tener en cuenta que XHTML deja de lado todo aspecto estético y se centra en el contenido y en la semántica. En lugar de usar una etiqueta para dar un aspecto concreto, usamos etiquetas para hacer que las palabras signifiquen una cosa u otra. Ahora veremos una serie de “reglas” a seguir para pasarnos a XHTML. También es recomendable leer el capítulo donde se explica la estructura de un documento XHTML. Evidentemente, no se muestran aquí todas las diferencias, pero sirve para hacernos una idea de qué es lo que nos espera1.

Minúsculas y comillas, por favor

Antes era una práctica muy común escribir las etiquetas en mayúscula, para diferenciarlas del código. Por compatibilidad con XML, en XHTML todas las etiquetas deben ir en minúsculas.

Además, todos los atributos tienen que estar entre comillas dobles. Por ejemplo, si antes teníamos:

<IMG SRC=icono.gif ALT=Icono>

Ahora escribimos:

<img src="icono.gif" alt="Icono" />

Todas las etiquetas se cierran

Con HTML podíamos crear párrafos con la etiqueta <p> sin necesidad de cerrarla con </p>. Lo mismo ocurría con <li>, por ejemplo. En XHTML ninguna etiqueta puede quedar sin cerrar.

Lo de “ninguna” es literal, y etiquetas que no tienen una de cierre, como <img>, <br> deben ser cerradas también. ¿Cómo lo hacemos? Insertando la barra /, de forma que el salto de línea ahora nos queda <br />. El espacio en blanco que hay entre el nombre y la barra es necesario para que los navegadores antiguos reconozcan la etiqueta.

<FONT> y ciertos atributos desaparecen

Hemos dicho que XHTML deja de lado la apariencia del documento, ya que eso es controlado por CSS. Entonces, las etiquetas <font> y <basefont> carecen de sentido.

Además, esos atributos de algunas etiquetas que hacen referencia al color de las cosas, imágenes de fondo, etc. también desaparecen por este motivo: son sustituidos por reglas CSS. Así que sayônara a bgcolor y compañía. Lo mismo para el atributo align usado en párrafos e imágenes.

<B> y amigos también se van

Ciertas etiquetas de formato, como <b> (negrita), <i> (cursiva), etc. ya no se usan porque hacen referencia exclusivamente a la apariencia de las palabras. Si queremos dar énfasis, utilizamos <em>, y para dar énfasis más fuerte <strong>. Los navegadores suelen mostrarlas como cursiva y negrita, respectivamente, aunque esto es lo de menos porque podemos cambiarlo con CSS.

Hay que usar alt y title

XHTML hace hincapié en la accesibilidad de un documento, y por eso debemos facilitar atributos de “apoyo” a algunas etiquetas. La etiqueta <img> dispone del atributo alt, que se muestra cuando la imagen no se puede cargar (a veces también cuando se pasa el cursor del ratón por encima). Hay que utilizarlo siempre.

Existe un atributo muy similar llamado title, que se utiliza en la etiqueta <a> (entre otras) y sirve para mostrar una descripción del sitio al que nos dirigimos. Por ejemplo:

<a href="http://www.google.es" title="Buscador">Google</a>

Cuidado al anidar etiquetas

XHTML es muy estricto en cuanto a la anidación de etiquetas. Básicamente, hay dos tipos de elementos: los block y los inline. Los block son etiquetas como párrafos, headings, listas, etc. Así a ojo los distinguimos porque siempre van solos e insertan saltos de línea. Los inline no interrumplen el flujo del texto. Son las etiquetas de formato, los enlaces, y demás. No podemos meter un elemento block dentro de uno inline.

Por ejemplo, si queremos hacer que el heading principal de nuestra página sea un enlace, esto sería incorrecto:

<a href=".." title="..."><h1>Texto</h1></a>

Hay que hacerlo así:

<h1><a href="..." title="...">Texto</a></h1>

Además, hay ciertas etiquetas que no admiten otras dentro. Si tienes dudas, lo mejor es utilizar el validador de código del WWW Consortium.

No existen los frames

Aunque la especificación XHTML 1.0 Frameset permite el uso de frames (marcos) en una página, tanto la Transitional como la Strict los prohíben3. Así que ya no podemos usar ni frames ni inline frames.

3En realidad esto es como la Cherry Coke. Existir, existe, pero nadie la compra.

De todos modos, aunque se pudieran emplear, no deberíamos, ya que los frames son un atentado contra la usabilidad4.

4Y a Google no le gustan, de paso.

No se puede utilizar target

Antes, la etiqueta <a> tenía un parámetro llamado target que permitía especificar en qué frame debía cargarse el destino de un link. Como ya no hay frames, este atributo es innecesario.

A los amantes del target="blank" para abrir webs en ventanas nuevas les digo que si el visitante quiere abrir un ventanuco nuevo, lo hará con el botón derecho del ratón. Y para los que usamos navegación con pestañas5 es bastante molesto que se abran nuevas instancias del navegador. Gracias.

5Ahora mismo prácticamente toda la humanidad con acceso a Intenet, ya que la nueva versión del Maligno por fin las trae.

Las tablas no se usan para maquetar

Aunque puedes crear un documento XHTML con tablas para maquetar que pase el análisis del validor del W3C, va contra la filosofía de dejar XHTML sólo para el contenido. Las tablas están hechas para representar información tabulada, no para diseñar layouts.

De todos modos, el paso para un layout tableless no suele ser fácil, así que creo que es conveniente familiarizarse primero con el resto de XHTML y CSS, y dejar la maquetación sin tablas para más tarde6.

6“Tarde” no significa “nunca”.

Los ampersands dan por saco

Si tienes URL’s que contengan el ampersand (&), te llevarás la sorpresa de que el validador del W3C se pelea con ellas. Esto es debido a las entities.

¿Qué demonios son? Pues la manera que tenemos de insertar caracteres de forma “segura”7. Por ejemplo, el carácter á se escribiría &aacute;. Como ves, las entities comienzan por un ampersand y acaban en punto y coma.

7Es decir, que se vean cuando usamos una codificación muy limitada, como el ASCII estándar. Si usamos Unicode no deberíamos tener ningún problema.

Por eso, cuando se leen las URLs que contienen ampersands, hay confusión porque lo que sigue no es una entity. . . Así que lo que tenemos que hacer es sustituir el ampersand por su propia entity, que es &amp;. Es decir, que esta URL:

http://alianza.net/p.php?nick=leia&show=all

Se quedaría en:

http://alianza.net/p.php?nick=leia&amp;show=all

Aunque hemos estado hablando de URL’s, también debemos emplear la entity &amp; en nuestro texto normal y corriente cuando queramos escribir un ampersand.

 

Información adicional

Contenido publicado bajo licencia Creative Commons. Belén Albeza (BenKo)

Si tienes alguna pregunta de este ejemplo; puedes hacerla aqui en los foros.