A continuación, contribuyo con un análisis visual y de código sobre el sitio, esperando que Cadena 3 tome estas sugerencias para mejorar.

El amor entra por los ojos

Visualmente, el sitio es pobre. Como no hay muchos espacios en blanco es dificil que a alguien le de placer leer el sitio. El contenido está muy junto, el diseño no respira y se extraña una buena grilla que dé más orden y separación entre los elementos.

Pero, el diseño no es terrible —como muchos piensan—; solamente faltan un par de toques y tal vez ampliar un poco más la paleta de colores. Me imagino que ese azul es un color institucional, por lo cual a los diseñadores no les quedó otra que usarlo en todas partes.

Los degradados están mal logrados: Parecen un descarte de algun sitio Web 2.0 hecho por un amateur. Me da la impresión de que usando degradados Cadena 3 quiere ser cool o ser Web 2.0 —si es así les faltó el reflejo en el logo—. Un poco más de sutileza y contraste ayudaría mucho a mejorar el diseño. No hay que inventar nada nuevo ni engancharse en ninguna moda estúpida, solamente seguir principios básicos del diseño gráfico.

Por otro lado, no hay una jerarquía de la información. Para mí, el Ranking de Radio Popular es tan o más importante que las noticias del día. El banner de Creativos Unidos tiene tanta o más importancia que el inmenso logo de Cadena 3. Miren por ejemplo la sección Bitácora de Audios: Yo, que solo escucho la radio cuando me subo a un taxi, no diferencio el El Chiki Chiki de Juntos.

Al igual que en el sitio de La Voz del Interior, el clima no es accesible a simple vista, el usuario tiene que hacer click y esperar a que se cargue otra página para saber un dato tán básico. Hubiera sido mejor ubicar un par de íconos y su descripción dentro del encabezado. Al menos, el enlace para consultar el clima está en la parte superior del sitio, en La Voz del Interior es inevitable presionar Cmd + F y luego tipear «clima» para que el navegador busque y resalte el enlace —que está en la última sección derecha del sitio!—.

Si todo es importante, entonces nada es importante

A simple vista, Cadena 3 tiene más contenido en la página principal que el New York Times. Y realmente no creo que produzcan más notas que la Gray Lady; el problema aquí es la pésima maquetación, el uso poco inventivo de la grilla —si es que hay alguna— y la política de encajar todo en la homepage. Está bien, para muchos cordobeses el cuartetero Damián Córdoba puede ser muy importante, pero dedicar más de 800 pixels de alto a una sección de rankings musicales —de dudosa calidad, o no— es demasiado.

En este sentido, separar casi 900 pixels de alto para las posiciones del campeonato futbolero es también curioso, y de hecho, me sugiere el tipo de audiencia de la cadena, más preocupado por saber como salió Instituto y por las ventas de La Fiesta, que de las noticias del país. Pero mejor evitemos las críticas tendenciosas y nos dediquemos a lo que realmente sabemos hacer: diseñar.

Podemos imaginar un mejor uso de la grilla para maquetar y disponer los elementos. Por ejemplo, para ahorrar los casi 600 pixels de alto de la columna Boletines Informativos, reemplazamos la lista de corresponsalías y redacciones por una lista desplegable. De esta manera reducimos el alto de esa sección a 150 pixels como mucho, 1/4 parte de la actual.

Fig. 1. Una propuesta para las secciones con mucho contenido.

Es más, con una pequeña cookie podemos recordar la opción que eligió el usuario y mostrar por defecto la corresponsalía que le interesa cada vez que entra al sitio. Las posibilidades son muchas y sólo observando como actúan los usuarios se pueden sacar grandes ventajas.

Por otro lado, podemos repetir el mismo enfoque en El Campo Hoy y otras secciones largas, de esta manera estandarizando muchos de los bloques de información del sitio y reduciendo la altura total.

Sería bueno también agrupar algunas secciones para que se muestren horizontalmente —al mejor estilo The Onion, fijensé la sección Features—. En este caso, por ejemplo, El Espectáculo, Estrenos y Ranking de la TV, podría agruparse en una sola sección Espectáculos y mostrarse horizontalmente. Clickeando en las flechas de izquierda o derecha, el usuario puede hacer aparecer el contenido que desee a gusto.

Tipografía

El uso de una buena fuente es primordial para un diario o publicaciones con mucho contenido. Fuentes bien escogidas permite evitar gastos innecesarios en papel, meter más caracteres en espacios reducidos y aumentar la legibilidad de las notas.

Generalmente se considera que las fuentes con buen ojo medio —la altura de la x minúscula— son mas legibles. Por otro lado, como el ojo no analiza cada letra individualmente, sino la palabra entera, se cree que las letras con serif —las terminaciones de cada letra— aumentan la legibilidad de un texto, ya que cada serif produce la ilusión de continuidad en el texto. «Así como yo puedo leer tu letra, vos también vas a poder leer la mía» diría Spiekermann en la película Helvetica, refiriéndose a la continuidad de los trazos al escribir con la mano.

Cadena 3 usa una tipografía sans-serif, Tahoma, en todo el sitio. En cualquier caso, el sitio está tan mal maquetado que si uno no tiene Tahoma instalada en el sistema —como en mi caso—, ve la tipografía por defecto del navegador, generalmente Times New Roman. Si Cadena 3 quería usar una tipo sans-serif, tendría que, al menos, haber dado otra alternativa sans-serif a Tahoma. Esto se puede hacer muy fácilmente en CSS usando algo similar a font-family: Tahoma, Arial, sans-serif. En este caso, el navegador buscará Tahoma, si no está instalada probará con Arial, y por último, en el peor de los casos, con cualquier tipografía sans-serif.

Aunque Times es una fuente probada y que funciona, la mancha de gris que produce en pantalla y en cuerpos muy pequeños —como lo hace Cadena 3— es poco homogénea. Mejor hubiera sido usar una tipografía especialmente creada para la web, como Georgia, con poco contraste —el contraste es la diferencia entre los trazos verticales y horizontales de una letra— y mancha más homogénea, aún en cuerpos pequeños. Mejor aún hubiera sido aumentar aunque sea un punto el cuerpo de las notas, ya que realmente son ilegibles.

Pero nos limitemos a tipos sans-serif. Todavía me sigo preguntando porque usaron Tahoma en vez de algo universal como Helvetica, para Mac, y Arial, en Windows.

Optimizado para IE 4.0

A mí, que navego con Safari y vivo en 2008, me parece sumamente graciosa y hasta inocente la afirmación de arriba. Más allá de lo visual, me llamó muchísimo la atención que un sitio lanzado en éstos días no haya sido maquetado siguiendo estándares web, aunque sea mínimamente. Y no me refiero solamente a no usar tablas —de hecho el «no uses tablas!» suena más a un argumento de alguien que toca de oído más que al de alguien que realmente sabe usarlas en algun contexto determinado de la vida real, como en formularios—, sino, a un pobre entendimiento de CSS y HTML para maquetar.

El código del sitio abusa de estilos en linea y prácticamente no reusa ninguna clase de CSS. No hay una clase noticia para mostrar cada post, entonces, estilizar una nota es un proceso individual y repetitivo que incluye hacer encajar la nota dentro de una celda de una tabla y luego jugar con elementos hiperdeprecados como font.

Todo esto, claro, se repite para cada nota.

En el futuro, cuando Cadena 3 quiera cambiar el estilo de las notas —digamos, aumentar en 1px el cuerpo de la tipografía— va a tener un problema grande.

Éste es el código que se usa en el sitio para mostrar una nota:

<table width="30%">
<tr>
	<td>
		<p style="margin-top: 0; margin-bottom: 0"><a href="post_ampliado.asp?post=480"><font color="#001242" style="FONT-SIZE: 20px" face="Tahoma">Sismo en Catamarca</font></a></p>
		</td>
</tr>
<tr>
	<td>
		<p class="destacado" style="margin: 5px"><font color="#800000" face="Tahoma"><b>17:54</b></font>
		<font face="Tahoma" color="#333333">Según datos del Inpres, el movimiento telúrico se registró a las 16.26 y tuvo epicentro a 40 km de la capital de Catamarca. El temblor tuvo una intensidad de 3 a 4 gradosº  en la escala Mercalli y una magnitud de 4,5 en la escala de Richter.</font>
	</td>
</tr>

<tr>
	<td width="100%">
		<table border="0" width="100%" id="table1280" bgcolor="#F4F4F4">
			<tr>
				<td width="16">
					<a href="javascript:popup('enviar',480)"><img alt="Recomendar por mail" border="0" src="http://www.cadena3.com/images/iconomail.gif" width="16" height="17"></a>
				</td>
				<td width="30">
					<a href="javascript:popup('enviar',480)"><font face="Tahoma" style="FONT-SIZE: 11px" color="#737173">Enviar</font></a>
				</td>
				<td width="16">
					<a href="post_ampliado.asp?post=480"><img alt="Comentar la nota" border="0" src="http://www.cadena3.com/images/iconocomentar.gif" width="16" height="17"></a>
				</td>
				<td width="47">
					<a href="post_ampliado.asp?post=480"><font face="Tahoma" style="FONT-SIZE: 11px" color="#737173">Comentar</font></a>
				</td>
				<td>
					<p align="right"><font face="Tahoma" style="FONT-SIZE: 11px" color="#151672"><a href="comunidad.asp?comunidad=6">Sociedad</a>   </font>
				</td>
			</tr>
		</table>
	</td>
</tr>
<tr>
	<td background="http://www.cadena3.com/images/lineagris.jpg" height="15"></td>
</tr>
<table>
 

Como pueden ver, no hay una separación clara del contenido (la nota) y la presentación (lo visual). Tampoco hay semántica: Google entiende que Sismo en Catamarca es un párrafo, cuando debería ser un título y la lista de enlaces «Enviar», «Comentar», «Sociedad», no es una lista, es simplemente contenido tirado en una celda que dificilmente será leído por un lector de pantalla.

Más allá de eso, este pedazo de código ocupa 4KB y se repite muchas veces en la página. Ahora imaginen la cantidad de dinero mensual en hosting que está perdiendo Cadena 3 por no optimizar un poco su código.

Éste es un mejor enfoque para maquetar una nota:

<div class="post">
	<h3><a href="">Sismo en Catamarca</a></h3>
	<p><span class="hora">17:54</span> Según datos del Inpres, el movimiento telúrico se registró a las 16.26 y tuvo epicentro a 40 km de la capital de Catamarca. El temblor tuvo una intensidad de 3 a 4 gradosº  en la escala Mercalli y una magnitud de 4,5 en la escala de Richter.</p>

	<ul>
		<li class="enviar"><a href="">Enviar</a></li>
		<li class="comentar"><a href="">Comentar</a></li>
		<li class="categoria"><a href="">Sociedad</a></li>
	</ul>
</div>

El título de la nota es un título en HTML, H3, el contenido, un párrafo P, y la lista de enlaces, bueno, una lista de enlaces, LI. Cada nota es un DIV con clase post. En el archivo CSS se estila la nota a gusto.

En el hipotético caso de que Cadena 3 decida aumentar 1px de cuerpo para las notas, solo tendrá que cambiar 1 sola línea en este archivo y no miles en cada noticia. Ni hablar de la reducción en el peso del sitio, que contribuirá a todo cargue mucho más rápido que los 40 segundos actuales —en algunas conexiones—. Pueden ver cómo se estiliza la nota original y cómo quedaría la nueva propuesta funcionando.

Conclusión

Realmente hay mucho que mejorar en el nuevo Cadena3.com. Desde la gráfica, que en mi opinión es solamente correcta, hasta la maquetación, que ya vimos que es pésima.

Espero que a la gente de Cadena 3 le haya servido este post para poder mejorar el sitio en un futuro. No es una crítica infundada y con mala leche hacia los desarrolladores y diseñadores, después de todo, las decisiones son tomadas por otros y uno es un simple diseñador —y todos estamos bien conscientes de qué tan difícil es remar con un cliente necio—, pero solo en la diversidad de opiniones se puede construir algo mejor.

¿Que quiere decir esto? Que desde ahora —y solamente con las últimas versiones de Firefox, ni sueñen todavía su implementación en otros browsers— es posible enviar información sobre la URL en la cual está clickeando el usuario a un servidor remoto. Esto es, —siempre en teoría—, se podría trackear y hacer análisis estádisticos sobre la cantidad de enlaces clickeados, los destinos y demás información.

Esto ya se hacía antes, pero a través del redireccionamiento, lo cual, según Fried Fish, es un método tosco para implementar, que solamente obliga a cargar otra página para saber que destino vamos a visitar, con la consecuente pérdida de velocidad. Para poner un ejemplo de este método, cada vez que hacemos un click en algún anuncio de Google Adsense, el navegador tiene que redireccionar a otra página/server (que contabilizará nuestro click y le dará una moneda al sitio), para luego redireccionar a nuestro destino original (digamos, un anuncio de coches). Un método tosco, claro que sí, pero funciona.

Para esto, la gente de WHATWG está proponiendo saltearse ese paso, animando a usar un nuevo atributo ping, que justamente mande una notificación del URL al que estamos clickeando a un servidor remoto, en forma transparente y en background, sin necesidad de tener que redireccionar.

2 cosas que me llaman mucho la atención:

• La WHATWG se mueve y rápido. Hasta ahora el único organismo que se encargaba de “pushing the limits of the web” y de hacer los estándares de HTML, XHTML, y bla bla es la W3C. Pero como son lentos como una tortuga, algunas empresas como Apple, Firefox y Opera se unieron para hacer un nuevo grupo que los apure y genere propuestas de recomendaciones más rápidamente. Esto al parecer está dando resultado. Recordemos que hay un largo trecho desde que una recomendación se implementa en los navegadores (caso IE) y siempre hay baches que llenar.
• La rapidez de Firefox en mejorar el navegador. Estamos hablando de pura teoría, que tal vez usaremos dentro de un par de años … pero realmente me sorprende la velocidad y la atención que le están dando a grupos como el WHATWG.

Por otro lado, no hace falta preocuparse por la privacidad del atributo ping, porque:

• Por ahora solo esta implementado en Firefox, y en las nightly builds … digamos, solamente 2 o 3 locos de la cabeza pueden hacer uso del atributo :P
• Si algun sitio quiere saber en donde clickeaste, hay cientos de métodos —mas complicados pero que sirven— para saberlo. Lo único que hace este atributo es facilitar la vida a los desarrolladores.
• Es un atributo propuesto por el WHATWG … de ahí a que sea parte de alguna recomendación del W3C falta y mucho. Lo que quiero decir es que tal vez nunca sea una recomendación oficial.

Muy buena movida de Firefox, que realmente me sorprende por la implementación de proposed drafts … ¡en este caso de Enero de 2006!

Actualización: Un ejemplo práctico y bien geek: Imaginen un script para Greasemonkey que agregue un link a todas las páginas con el atributo ping apuntando a Delicious para guardar tus bookmarks sin necesidad de cargar Delicious y agregar los tags :) Mezclen eso con un poco de AJAX y vean que sale :P

Siguiendo con nuestra serie de artículos sobre desarrollo web orientado a estándares, en esta ocasión les explicaremos en que consiste XHTML, explicando paso por paso la estructura de un documento en este lenguaje.

El Extensible Hypertext Markup Language, o simplemente XHTML para los amigos, es una reformulación de HTML 4.01 pensada como una aplicación del lenguaje XML. Es decir, XHTML es una versión de HTML, con los mismos elementos y atributos, pero basada en la sintaxis y estructura de XML.

Al principio, HTML fue creado para el intercambio de documentos científicos a través Internet. Sin embargo, a medida que la web evolucionaba y se expandía más allá del campo científico/universitario, los requisitos de los desarrolladores web también crecían. La necesidad de un lenguaje de marcado para páginas web, que sea fácilmente extensible por medio de módulos y además interoperable con otras aplicaciones de XML, dio como resultado a la creación de la especificación XHTML 1.0.

Usar XHTML por sobre HTML tiene muchas ventajas importantes. El World Wide Web Consortium, entidad que se encarga de desarrollar especificaciones sobre las tecnologías que construyen la WWW, afirma que:

• XHTML es extensible. Esta es la principal ventaja sobre HTML. XHTML permite agregar nuevos elementos y atributos a través de la modularización, lo cual nos da la posibilidad de aprovechar las ventajas de otras tecnologías de desarrollo web, como MathML, y de las que se vayan a desarrollar en el futuro, como XForms.
• XHTML es accesible. Debido a su énfasis en la estructura de un documento y no en su presentación, XHTML es un lenguaje que tiene como objetivo el poder ser interpretado por cualquier dispositivo capaz de leer XML, ya sea un navegador o un teléfono celular.

Luego de esta breve introducción, pasemos entonces a ver el esqueleto de un documento XHTML, explicado en detalle paso por paso.

Anatomía de un documento XHTML

Si tenemos presente la estructura de un documento HTML, nos daremos cuenta que son muy similares a los documentos XHTML; de hecho, en XHTML no se han agregado elementos adicionales. Sin embargo existen un par de requisitos, que aunque no son complicados de entender ni de aplicar para el que está empezando en el diseño de sitios web, tal vez impliquen un cambio de mentalidad drástico para aquel que viene maquetando en HTML.

A continuación mostraremos la mínima expresión de un documento XHTML, para luego enfocarnos en aquellas diferencias propias de este nuevo lenguaje de marcado.


1. <?xml version="1.0" encoding="ISO-8859-1"?>
2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
4. <head>
5. <title>Documento simple en XHTML</title>
6. <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
7. </head>
8. <body>
9. <h1>Documento simple en XHTML</h1>
10.<hr />
11.<p>Este es nuestro <em>primer documento</em> en <acronym title="Extensible Hypertext Markup Language">XHTML</acronym>.</p>
12.</body>
13.</html>


Línea 1: La declaración XML. La primera línea indica al navegador que el documento que sigue está desarrollado conforme a la versión 1.0 de XML y que se basa en el juego de caracteres especificado en la norma ISO-8859-1. Es importante detenernos sobre este punto y aclarar que el World Wide Web Consortium recomienda, pero no obliga incluir ésta línea de código en todos nuestros documentos XHTML, puesto que está demostrado que muchos navegadores tienen problemas al momento de leer esta declaración, resultando en páginas que se muestran incorrectamente. Estos navegadores incluyen algunas versiones de los populares Internet Explorer y Netscape Navigator.

Es por esto que recomendamos no incluir esta declaración XML en nuestras páginas, por lo menos hasta que las versiones futuras de los navegadores más usados solucionen este problema. Un cuadro con información sobre los navegadores soportan esta declaración XML puede encontrarse en http://www.webstandards.org/learn/reference/prolog_problems.html.

Los lectores más despiertos se preguntarán entonces como especificaremos el tipo de contenido que estamos sirviendo y el juego de caracteres que usamos en nuestro documento XHTML. Para ello, agregamos la línea 6, la cual explicamos en detalle más adelante.

Línea 2: El DTD a usar. Un DTD o Document Type Definition, es simplemente una especificación de todos los elementos, atributos y entidades permitidos para un determinado tipo de documento XHTML o HTML. Esto significa que, según el DTD que estemos usando, tendremos a nuestra disposición un conjunto de elementos para usar al momento de codificar nuestras páginas web. Por ejemplo, el DTD de XHTML 1.0 en su versión estricta, elimina todos los elementos de presentación de un documento HTML. Esto quiere decir que sería inválido usar el elemento <center> en nuestros documentos XHTML con DTD estricto.

Esta declaración del DTD a usar en una página web, no es específica de XHTML; con HTML también debíamos especificar uno. Existen varias versiones de DTDs para XHTML, e incluso también podríamos crear un DTD propio para luego utilizar en nuestros documentos. El World Wide Web Consortium, define 3 tipos de DTDs, los cuales son:

• Strict. Es el DTD más rígido que podemos usar. En este DTD, todos los elementos de presentación , como <font> o <center>, son eliminados y por consiguiente no es posible utilizarlos en nuestros documentos. Por lo tanto, para controlar los elementos de presentación de nuestro documento, como la asignación de colores y el posicionamiento de elementos, deberemos utilizar CSS. La línea que especifica que un documento XHTML es estricto, es la siguiente:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

• Transitional. Es un DTD un poco más flexible que el anterior. Contiene algunos elementos de presentación, por ejemplo, el elemento <center>. Está pensando para aquellos desarrolladores que están haciendo el cambio hacia un DTD estricto, pero que todavía no tienen suficiente experiencia con CSS. Si deseamos especificar que nuestro documento XHTML es del tipo transicional, deberemos introducir la siguiente línea:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

• Frameset. Es el DTD que debemos incluir cuando estamos creando sitios web que incluirán frames o marcos. Para ello, la declaración DOCTYPE es la siguiente:
  
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">


Ahora bien, ya vimos que tenemos varios sabores de DTDs en XHTML. La pregunta del millón es, ¿Cuál deberíamos usar para nuestros sitios web? Aquel que nos asegure en un 100% la premisa de separación del contenido de un sitio de su presentación. Recordemos: El concepto clave detrás de todas estas nuevas tecnologías de desarrollo web es la separación del contenido de su presentación. Es por esto que el único DTD que nos garantiza alcanzar esta premisa, es el de XHTML estricto, el cual no incluye ningún elemento de presentación en su especificación, obligando a que todo el aspecto visual de nuestra web sea necesariamente controlable utilizando CSS.

Volviendo a nuestro ejemplo, a través de la declaración DOCTYPE en la línea 2, especificamos que el documento usará los elementos, atributos y entidades declarados en el DTD de XHTML 1.0 estricto. Recordemos que esta declaración DOCTYPE es sensible a mayúsculas y minúsculas y que además debe ir en la primera línea de nuestro documento, después de la declaración XML (si es que la estamos usando).

Línea 3: El elemento . En XHTML, ahora el elemento raíz requiere que especifiquemos obligatoriamente de:

• El espacio nominal de los elementos. En XML, evitamos la ambigüedad en los nombres de los elementos usados agrupándolos en espacios nominales. Al especificar el atributo xmlns apuntando al espacio nominal de XHTML le decimos al navegador que los elementos que siguen son de XHTML y no de otro lenguaje basado en XML, como por ejemplo MathML.
• El idioma. A través de la combinación de atributos xml:lang (propio de XML) y lang (propio de HTML), definiremos el idioma en el cual está escrito el texto de nuestro documento, en nuestro caso, español.

Línea 6: El tipo de documento y el conjunto de caracteres usado. Como habíamos nombrado anteriormente, la declaración XML nos servía para especificar el conjunto de caracteres usado por un documento. Pero recordemos que al incluir esta línea de código, también llamada el XML prolog, nos llevaba a tener problemas con la mayoría de los navegadores, por lo que decidimos omitirla. Ahora bien, ¿cómo le decimos entonces al navegador el juego de caracteres que estamos usando en nuestro documento? Es aquí en donde entra en escena el meta tag http-equiv, el cual especifica el tipo de contenido que estamos sirviendo (en nuestro caso text/html) y además el juego de caracteres usado (ISO-8859-1). Es importante recordar que si no vamos a poner la declaración XML de la línea 1, deberemos especificar obligatoriamente el tipo de contenido del documento y el juego de caracteres del mismo a través de este meta tag.

Líneas 9, 10 y 11: Diferencias con HTML. XHTML heredó de XML dos características interesantes, que a simple vista lo hacen parecer más estricto que HTML:

• El documento XHTML debe ser válido. Incluyendo la declaración DTD que deseemos, y limitándonos a sólo los elementos especificados en ese DTD, cumpliremos fácilmente con este requisito. De cualquier manera, podemos comprobar si nuestro documento es válido con la herramienta de validación provista por el World Wide Web Consortium, explicada en detalle mas adelante.
• El documento XHTML debe estar bien formado. Esto quiere decir que debemos abrir y cerrar los elementos de manera correcta y en orden. Un ejemplo de dos líneas de código XHTML mal formadas:
  <p>Este es nuestro <em>primer documento.</p></em>
<p>Este es nuestro <em>primer documento.</em>
  Y a continuación, la misma línea de código respetando esta restricción de XHTML (Noten que el primer elemento en abrirse es siempre el último en cerrarse):
  <p>Este es nuestro <em>primer documento.</em></p>

  Por otro lado, XHTML requiere que todos aquellos elementos que no tienen contenido, como <img /> o <hr />, deben cerrarse agregando una barra invertida al final. Por ejemplo, a continuación pueden ver el elemento <img /> en XHTML (noten el espacio obligatorio entre el nombre del elemento y la barra invertida):

  <img src="mi-imagen.png" alt="Mi imagen" />

Además de lo nombrado anteriormente, un documento XHTML:

• Tiene sus elementos y atributos escritos en minúsculas. Recordemos, XHTML es una aplicación de XML, el cual es sensible a las mayúsculas y minúsculas, por lo tanto, el elemento <p> no es lo mismo que el elemento <P>.
• Encierra los atributos de sus elementos entre comillas. Todos los atributos necesariamente deben ir entre comillas, incluso aquellos que son numéricos. Ejemplo:

  <acronym title="Extensible Hypertext Markup Language">XHTML</acronym>
<td colspan="2">

• No soporta minimización de atributos. En HTML, el siguiente código es válido:
  <option selected>
  En cambio, en XHTML, los atributos de un elemento deben ser escritos completamente, por lo cual, la línea anterior en XHTML quedaría como:
  <option selected="selected">

Como vemos, la estructura de un documento XHTML puede parecer, al principio, más estricta que la de un documento HTML. Esto es debido a que XHTML, al ser una aplicación de XML, hereda de este lenguaje su énfasis en la estructura del documento. La idea detrás de estas restricciones es que, una vez que tenemos la estructura de un documento bien formada, ya sea XML o XHTML, cualquier parser o navegador podrá entender el significado del mismo.

Validando nuestro código XHTML

Por validación entendemos la acción de verificar que nuestro documento XHTML cumpla con la sintaxis estándar especificada en un DTD. Ahora bien, si al parecer, una página web se muestra correctamente en un navegador, incluso sin especificar un DTD, ¿porqué entonces debemos validar nuestros documentos? Daremos dos razones que pueden ayudar a entender la necesidad de la validación:

• Lo que uno está viendo no es lo que otros ven. Tal vez nuestro sitio web puede estar mostrándose correctamente cuando lo probamos con nuestro navegador preferido, pero en la práctica, muchos navegadores interpretan un sitio de maneras diferentes. El único modo de asegurarnos que nuestro sitio web será mostrado de la forma en que deseamos en todos los agentes de usuario disponibles, es a través de la validación de nuestro código XHTML.
• Evitar el Quirks Mode. Por definición, cuando el navegador no encuentra una línea de código especificando un DTD a usar en el documento, entra en un estado que se llama Quirks Mode. En este estado, el navegador interpreta que la página web puede contener cualquier conjunto de elementos HTML y XHTML, desde elementos correctos hasta incorrectos, y por lo tanto, cambia su motor de renderizado de páginas al de corrección de errores. Este modo a “prueba de fallos” tiene varias deficiencias, una de ellas, es que hace más lento el proceso de carga de una página web, debido a que el navegador tiene que ir corrigiendo el código a medida que lee la página.

La validación de nuestros documentos XHTML se realiza a través de una herramienta de libre acceso, provista por el W3C, y disponible en http://validator.w3.org/. Simplemente ingresaremos la URL del sitio a verificar en un formulario, o bien, subiremos el archivo XHTML desde nuestra PC. Una vez especificada la fuente, la herramienta procesa el documento y devuelve la cantidad de errores encontrados, junto con una pequeña explicación de los mismos y la forma de corregirlos.

Conclusión

Aunque XHTML puede resultar un tanto estricto al principio, el proceso de conversión de HTML a XHTML no es complicado. Existen herramientas de libre uso, como HTML Tidy (ver recuadro “Herramientas útiles”) que “limpian” el código HTML, simplificando la conversión de grandes sitios y páginas web.

El mundo actual de desarrollo de soluciones pensadas para la web, nos muestra una clara tendencia hacia la estandarización y hacia al uso de XML como lenguaje universal de definición de datos. El lenguaje por defecto de marcado para páginas web, HTML, fue repensando con miras hacia XML. En nosotros radica aprovechar todo su potencial.

Excelente recurso encontrado en la lista Ovillo.