Artículos de Diseño Gráfico y Diseño y Desarrollo Web

RSS - Sindicar Contenidos
Xhtml 1.1 Strict Válido! CSS Nivel 2 Válido!  Nivel Doble-A de Conformidad con las Directrices de Accesibilidad Web (WAI)
Descarga FireFox gratis!
\n"; } } } lecturas();

Buena vida con XHTML

por Jeffrey Zeldman (Traducción al castellano autorizada).
Artículo Original en Inglés: Better Living Through XHTML - A List Apart
Fuente: pabloimpallari

Agradecimiento especial a Orlando Ignacio Romero Fernández y su equipo de Proyecto Web - Cuba por su ayuda en la traducción.

XHTML es el lenguaje de marcas estándar para los documentos web y el sucesor de HTML 4. Una mezcla de clásico (HTML) y del moderno (XML), este lenguaje híbrido se parece y trabaja semejante a HTML, pero está basado en XML, el "super" lenguaje de demarcación de la web, y le trae a las páginas web muchos de los beneficios de XML, los cuales son enumerados por la Guía de Estilo en Línea de la División de Bibliotecas de la Biblioteca Pública de Nueva York.

Si quieres que tu sitio web trabaje bien en los navegadores de hoy y en los dispositivos no tradicionales, y continúe trabajando bien en los navegadores del futuro, es una buena idea escribir los nuevos sitios en XHTML, y convertir las páginas viejas en XHTML cuando tu horario de trabajo lo permita.

El W3C, Consorcio para la Web, ha hecho esto fácil de hacer. Puedes aprender las reglas de XHTML más rápido que lo que te entregan una pizza mediana con aceitunas negras y champiñones frescos. Estas pocas y simples reglas ejemplifican el sentido práctico del W3C, para traer consistencia y XML bien formados a la web sin que diseñadores y desarrolladores atareados aprendan enteramente nuevas técnicas del lenguaje de marcas.

Pero como con cualquier transición, conseguirás mejores y más predecibles resultados si te preparas con anterioridad. Este artículo te ayudará en esto, al examinar herramientas que pueden ayudar en la conversión de XHTML y verificar que has hecho lo correcto. El artículo también aborda cambios en la forma que algunos navegadores muestran las páginas XHTML, esto puede desconcertarte si no estás preparado, y te ayuda a preparar la solución si es necesario.

Conocer antes de empezar

Si no lo has hecho aún, lee la Guía de Estilo online de la División de Bibliotecas de la Biblioteca Pública de Nueva Cork antes de leer este artículo.

La Guía de Estilo informa acerca del XHTML sin tener que enredarse en la literatura misteriosa del W3C, que incluye información valiosa sobre CSS (incluyendo Hojas de Estilo que puedes coger y usar en tus propios sitios), explica como trabajar con el Validator de W3C y ofrece trucos actualizados para los usuarios de Dreamweaver.

Este autor ayudó a la Biblioteca Pública de Nueva York a crear la Guía de Estilo y le agradece a la Biblioteca y al coordinador Web (co-creador de la Guía de Estilo) Carrie Bickner por querer hacer la Guía de Estilo accesible a toda la comunidad. La Guía de Estilo es frecuentemente actualizada para corregir errores y suministrar nueva información.

Tiempo de Tidy

El método más fácil de crear páginas XHTML válidas es escribirlas desde cero. Pero muchos trabajos de diseño son realmente rediseños y a menudo te encontrarás tú mismo cargado con la actualización de páginas viejas. La tarea de rediseñar proporciona la oportunidad perfecta para migrar hacia XHTML.

La herramienta gratuita HTML Tidy puede convertir velozmente tus HTML a XHTML. Nosotros recientemente lo usamos para hacer justo eso con el Reporte Diario en zeldman.com. Así mismo usamos Tidy para la conversión de CSS/XHTML de A List Apart el año pasado, y lo hemos usado satisfactoriamente en muchos sitios de clientes.

Tidy fue creado por el brillante entendido de las computadoras Dave Raggett y está ahora mantenido como software de código abierto por la comunidad de Source Forge, aunque algunas versiones son mantenidas individualmente como una actividad por amor.

Para nuestra conversión, usamos MacTidy 1.0b13, la más reciente versión de Tidy para Mac OS, desarrollado por Ferry Teague (El sitio de Ferry puede estar no disponible temporalmente cuando sigas estos links, porque el proveedor gratis de su sitio le permita transferir sólo x kbytes por hora. Si encuentras problemas, prueba después.)

Hay versiones en línea de Tidy así como también ejecutables descargables para Windows, Unix, distribuciones de varios Linux, Mac OS X y otras plataformas. Cada versión ofrece diferentes capacidades y por consiguiente incluyen diferente documentación.

Leer el manual

Como muchas personas ocupadas tendemos a evadir la lectura del manual, pero en este caso te instamos a que leas todas las palabras. Aunque algunas versiones de Tidy parecen rudimentarias y sus capacidades pueden parecer obvias, Tidy es una herramienta poderosa.

Para nuestra conversión del Reporte Diario, nosotros refrescamos nuestra memoria con un mero vistazo a la documentación de MacTidy, y esto probó ser un error.

En nuestro primer paso, usando configuraciones que no habíamos usado antes, Tidy convirtió nuestros caracteres codificados a no codificados, caracteres de teclado de una plataforma específica; transformó entidades Unicode que trabajan en todos los navegadores en entidades que deben trabajar en todos los navegadores pero no lo hicieron; y cambió los corchetes de comentarios (el < en <!-- por ejemplo) a caracteres codificados, por esta razón se provocaron errores en unas funciones de JavaScript.

El poder fue de Tidy, la falla fue nuestra. El mal uso de Photoshop, Illustrator, o Flash puede traer consecuencias similares y Tidy no puede ser culpado por los errores de sus usuarios. Así que hazte tres favores:

1. Lee el manual.

2. Mantén una copia de tu documento.

3. Lee el manual.

Aquellos que compartan nuestro problema por evitar la lectura del manual querrán conocer cuales configuraciones son correctas. Que pena, no hay configuraciones correctas únicas. La configuración adecuada depende del tipo de caracteres que pretendes especificar en el encabezado de página, el tipo de codificación que hayas puesto en la salida de tu editor de HTML (usualmente, pero no siempre, latin1) y otras variables. He aquí un consejo. Asegúrate de elegir Convertir HTML a XML si quieres generar XHTML. (Recuerda: XHTML es en realidad XML.)

Haz un tiempo para validar

La Guía de Estilo explica como trabajar con los Validators de (X)HTML y CSS del W3C. La validación toma sólo un poco de tiempo. Si no te interesas por este paso y tu XHTML o CSS contienen errores, tu sitio puede no funcionar correctamente. También puede lucir de forma diferente a lo que intentaste.

Con un XHTML y CSS válidos, los navegadores tenderán a mostrar tu sitio como esperabas, con las excepciones que serán discutidas debajo. Con XHTML o CSS no válidos, todas las apuestas están perdidas, y no podrás culpar a los navegadores. (Bueno, si puedes, pero no sería justo y no te hará nada bien.)

Si escribes tus lenguajes de marca a mano, a menos que seas perfecto, estarás cometiendo errores a cada rato. Si usas Macromedia Dreamweaver o Adobe GoLive tu sitio seguramente contendrá errores que los validators te ayudarán a resolver.

Tenemos toda la confianza que las versiones actualizadas de Dreamweaver y GoLive te ayudarán a escribir más contenidos web válidos, pero estas versiones no están todavía en el mercado, y aún cuando ellas estén disponibles necesitarás ir y pasarle la mano a tu XHTML. (Entre tanto, los usuarios de Dreamweaver podrán consultar los trucos de la Guía de Estilo, actualizada el 15 de febrero de 2002.)

A pesar de la forma que generes el XHTML, debes trabajar con los validators. Ellos son como consultantes no críticos de XHTML y CSS que señalan tus problemas sin pensar mal de ti.

Mensajes poco entendibles del Validator

Aún los mejores consultantes dan malos consejos. Ellos pueden también comer mucho ajo en el almuerzo, o usar tu máquina de Fax más de lo que quisieras. Los consultantes automatizados en validator.w3.org y jigsaw.w3.org/css-validator/ pueden ocasionalmente darte problemas inesperados.

Ante todo, esto tiene que ver con el lenguaje que los validators usan para reportar los errores. Escritos por y para entendidos, los validators a veces dan "ayuda" que pueden confundir. Algunas veces desearíamos que los validators pudieran decir, "Oye, tonto, olvidaste cerrar la etiqueta <p>" en lugar de las cosas enigmáticas que a veces dicen.

¿Por qué tan complicado, compadre?

Para ser justos, los enigmáticos mensajes de los validators son a menudo el resultado de limitaciones de software. El validator no es el software del año!!. Si olvidaste cerrar una etiqueta, el validator posiblemente no podrá saber que tenías la intención de cerrarla y de esta manera puede reportar un error más abajo en la página en lugar de en el punto real del problema. El validator puede apuntar de forma inapropiada a una etiqueta anidada que está, en efecto, debidamente anidada - pero si una anterior no lo está, esto lanza al validator en un ciclo de errores.

Como creador, eres responsable de tus propios errores, tanto si son generados (posiblemente en forma indebida) por una herramienta o hechos a mano. Conociendo sobre la tendencia de los validators de XHTML de reportar errores de anidamiento más abajo de donde realmente ocurren puede ayudarte a entender los reportes de error confusos y recuperarte rápidamente.

Otros problemas frecuentes

Muchos editores de HTML usados comúnmente generan doctypes con URIs relativas, tales como:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">

Estos URI generalmente provocan errores de validación de CSS que son casi imposibles de entender para los mortales. Nos hemos roto la cabeza ante mensajes como este:

org.xml.sax.SAXException: Por favor, arregle su sistema de identificador (URI) en el DOCTYPE

El poco conocido Preguntas Frecuentes del validator de CSS traduce estas expresiones a un Inglés legible y explica como solucionar los problemas. En el ejemplo anterior la solución es usar un doctype con una URI absoluta, tal como:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Compartiremos importantes consejos sobre doctypes un poco más adelante en este artículo.

Otro problema común que no molesta a los validators - pero hace estragos en los navegadores más viejos y también en algunos nuevos como IE6 - tiene que ver con el prólogo opcional de xml que precede al doctype y la declaración del espacio de nombres. De nuevo, mira las directivas de XHTML de la Guía de Estilo para más detalles, junto con la solución.

Otros problemas comunes de validación (y soluciones) son cubiertas en ¡Libertad, Igualdad y Validez! de Eric Meyer en Netscape DevEdge. (Netscape pudo haber movido el artículo citado desde que Buena vida a través del XHTML fuera publicado.)

Bugs del validator

Los validators son el producto de la ingeniería humana y de este modo, como todo software, contiene algunos errores. Puedes reportar esos errores cuando los encuentres (más adelante te diremos como), pero puede sentirse miedo de hacerlo, dado que es más probable pensar que tu XHTML tenga defectos a desconfiar que un poderoso programa creado por expertos puede estar mal. Pero todo puede ser posible.

En nuestro reciente encuentro con Tidy, usando preferencias incorrectas, obtuvimos una página web que no estaba correcta, y decidimos arreglar el error a mano. Sin darnos cuenta, pasamos por alto un error.

Obedeciendo nuestras preferencias imprudentes, Tidy había convertido nuestro &copy; símbolo del copyright al carácter del copyright de teclado de Macintosh. Este carácter no es admisible para la web. Corrimos la página resultante a través del validator de W3C y la pasó excelente.

Después intentamos validar nuestra hoja de estilo, pero el validator de CSS del W3C nos dijo que no lo podía hacer por un error en nuestro XHTML: "Un carácter XML no válido (Unicode: 0xa9) fue encontrado en el contenido del documento."

Trampa 22 (Situación completamente ilógica)

Desafortunadamente, no pudimos buscar y reemplazar "0xa9" puesto que 0xa9 no era un texto en nuestro documento. (Esto pasa por estar el símbolo de copyright en Unicode, pero a menos que te sepas los caracteres Unicode de memoria, los mensajes de los validators no son útiles.)

Los validators de CSS proporcionan referencias de Línea y Columna para el error y esto puede ser conveniente para localizar el problema si ellos acotaron algo. Pero las referencias no acotaron nada dado que el validator de CSS no edita tu XHTML.

El validator de W3C edita tu XHTML, con referencias a Líneas, pero sólo si el piensa que tu XHTML no es válido. Y como he dicho, el validator de W3C consideró nuestro XHTML válido.

De esta manera nos encontramos en una Trampa 22. Un validator dijo que nuestra página estaba bien, el otro nos proporcionó reportes de error que no pudimos usar.

Temporalmente frustrados, subimos la página de todas formas y en una hora, los lectores del Reporte Diario, incluidos Mark Howells, Zeke Runyon y Dylan Foley se habían puesto a revisart nuestro código y encontrar el error. Les agradecemos, corrigieron el error y volvimos a trabajar.

Si ubieramos estado trabajando en un proyecto de un cliente en lugar de un sitio personal, no hubieramos subido la página hasta que encontrar y corregir el error. En la mayoría de los casos, es mejor salir del Editor de HTML, dar un paseo y volver después con la mente clara.

Reportando Bugs del validator

Tales problemas son realmente raros (y en nuestro caso, ellos pueden haber sido prevenidos consultando el manual de usuario de Tidy en primer lugar), pero aparecen. Un amigo nuestro, quien ha sido llamado "el gran diseñador web", rutinariamente pone caracteres del teclado de Windows dentro de su código. Los errores en el lenguaje de marcas ocurren; los errores de los validators (a veces) ocurren.

Si piensas que el validator de XHTML del W3C tiene errores, visita la página feedback. Para reportar posibles errores del validator de CSS escribe a www-validator-css@w3.org. (La dirección de correo electrónico escrita en la página ReadMe no es funcional porque está incompleta.). Si el validator tiene de verdad una falla - o tienes una razón fuerte para pensarlo - se amable y considerado al reportar el error.

Los validators del W3C son un recurso gratis mantenidos como una actividad por amor por individuos conocedores. Mostrar petulancia, si bien algunas veces es aceptable, ofende el trabajo duro de las personas o (más probable) le hagan preguntarse a ellos por qué te comportas tan groseramente y los incites a lanzar tu nota a la basura.

XHTML y los navegadores

Ahora tienes una página XHTML válida. ¿Se muestra de la forma que se va a usar? En algunos navegadores recientes no es así - pero puedes arreglarlo rápidamente.

Después de convertir el Reporte Diario de HTML 4.0 transicional a XHTML 1.0 transicional, nuestra página no fue de ninguna forma diferente a la versión anterior, excepto por el cambio en el doctype y la reglas asociadas al lenguaje de marcas.

Pero IE6 y Mozilla/Netscape 6 decidieron mostrar la página de forma diferente.

He aquí lo que IE6 le hizo a nuestro menú:

Internet Explorer 6

Y aquí está como Netscape 6.2/Mac lo consideró:

Nestcape 6

Vista de un Reporte Diario del 2002 para ver como el menú se debe mostrar.

Arreglar la fisura

Para arreglar estas fallas imprevistas en IE6 y Mozilla/Netscape 6, nosotros le adicionamos dos reglas a la hoja de estilos del encabezamiento de página:

img {display: block;}

.inline {display: inline;}

La primera regla arregla el menú. La segunda arregla problemas de diseño (disposición) causados en alguna otra parte por la primera regla. Donde quisimos mostrar imágenes, adicionamos un atributo class="inline" a la etiqueta img. Problema resuelto.

¿Si el lenguaje de marcas (la estructura) y el aspecto visual (el diseño) son dos cosas diferentes para el W3C, por qué estos navegadores cambiaron nuestra presentación y cómo trajimos a colación las reglas de CSS que resolvieron el problema?

Interpretaciones estrictas y rarezas ocasionales

Por una razón, como se nota en el Reporte Diario (del 26 de Enero), los expertos discrepan en cómo estándares como CSS deben ser interpretados. En particular, ellos discrepan en qué estilos (si hay alguno) debe ser aplicado por defecto a las imágenes que no han sido estilizadas por los diseñadores.

El artículo de Eric Meyer Tablas, Imágenes y Fisuras misteriosas explica como los expertos de CSS de Mozilla interpretan las etiquetas de imagen sin estilo en relación al cuadriculado implícito en todas las páginas web y dan una salida para aquellos que no quieren que se añada espacio extra en sus diseños web. El asunto principalmente afecta la "combinación" de diseños que usan una amalgama de viejas tecnologías del diseño (tablas) y nuevas (CSS). (Netscape pudo haber movido el artículo citado desde que Buena vida a través del XHTML fuera publicado.)

Estricto vs. Estricto

Un artículo de Meyer declara que Mozilla y sus navegadores hijos, Netscape 6, sólo hacen esto con documentos (X)HTML con doctypes estricto. Pero esto puede ser sin querer, como parece sugerir que el espacio extra se aplica a imágenes sólo en HTML estrictos o XHTML estrictos. Una mirada a las listas de correo de diseño web muestra que esta es la interpretación popular de la palabra "estricto" en este contexto.

En efecto, lo que Meyer y sus colegas quieren decir con "doctypes estricto" es doctypes "completo" (o válido), esto es cualquier documento - incluso HTML 4.01 transicional - que incluya un URI completo. (Meyer no está abusando de la palabra estricto; es sólo que la palabra tiene significados diferentes en contextos diferentes.)

En la práctica, hemos encontrado que Netscape 6.x aplica su interpretación experta del CSS a algunos documentos HTML 4.01 transicional con doctypes completo y a los otros no. Esto puede ser porque Mozilla es aún un Beta, por lo tanto Netscape 6.x no está terminado, o esto puede indicar un principio fundamental que hemos obviado.

Precisamente para nuestro propósito actual, Mozilla/NN6 siempre aplica esta interpretación de CSS - y por consiguiente, este espacio extra - a páginas escritas en XHTML (estricto o transicional). En el momento que conviertes tu XHTML, las imágenes contenidas dentro de las tablas le harán a tu diseño lo que Alemania le hizo a Polonia.

Los doctypes y la presentación

La mayoría de los navegadores adaptables utilizan la presencia o ausencia de un doctype completo para iniciar la presentación de los estándares adaptables o los compatibles con la versión anterior ("modo raro"), respectivamente, una práctica primeramente sugerida (hasta donde sabemos) por Todd Fahrner en 1998 e implementada primero por IE6/Win en Marzo del 2000.

Mozilla/NN6 sigue este patrón, como lo hace IE6/Win. IE6 también incluye una propiedad DOM que dice si el modo estándares-adaptables está activo para un documento dado.

Cuando estás en modo "estándar" el navegador asume que sabes lo que estás haciendo y muestra tu página por la especificación del W3C. En el modo "raro" el navegador supone que haz hecho un trabajo anticuado, probablemente una página no válida, y la muestra como debería hacerlo un navegador más viejo. Tú controlas que rumbo toma el navegador para incluir o excluir un doctype XHTML completo.

Mira el artículo Prepara tu sitio con el DOCTYPE correcto para aprender cual doctype debes usar para tu proyecto web.

Nota agregada por Pablo Impallari: En este sitio estamos usando:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//ES" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Notar el //ES en lugar del //EN dado que estamos usando el castellano.

(Hay una excepción de esta regla: Mozilla/NN6, en común con MSIE, tratan las páginas de HTML 4.0 - incluso aquellas con doctypes completo- en modo "raro" compatible con la versión anterior. Si no estás del todo listo para XHTML, pero estás escribiendo HTML y CSS válidos y quieres que el navegador muestre tu página correctamente, elige un doctype HTML 4.01. Por supuesto, nosotros te exhortamos que uses XHTML en lugar de eso.)

Después de convertir en XHTML, si las imágenes comienzan a invadir los bordes de los objetos vecinos, tendrás que tomarte algunos minutos para agregar reglas a tus hojas de estilo. Cada diseño es diferente, por lo que no hay una regla única o una colección de reglas que resuelvan todos los problemas, pero el artículo de Eric Meyer y las reglas de estilo que usamos y hemos listado arriba te proporciona un punto de partida, y este trabajo extra no te tomará mucho tiempo.

Espacios en blanco y la presentación

A través del artículo de Eric Meyer se documenta por qué Mozilla/Netscape actúa así. No estamos seguros por qué IE6/Win cambió la presentación cuando actualizamos el doctype de nuestra página a XHTML. (Ambas versiones el viejo HTML 4.01 transicional y el nuevo XHTML 1.0 transicional - usaron doctypes completos.)

Pensamos que esto tiene que ver con el modo en que algunos navegadores manejan los espacios en blanco. Cada una de las dos etiquetas de abajo tiene un funcionamiento equivalente, pero por causa de sus diversos usos (o no uso) de espacios en blanco, pueden mostrarse diferentes en navegadores que intenten analizar espacios en blanco en el lenguaje de marcas.

De esta manera:

<td><img src="/articulos/algo.gif" /></td>

puede verse diferente a:

<td>
<img src="/articulos/algo.gif" />
</td>

El segundo ejemplo - el del espacio en blanco en el lenguaje de marcas - puede resultar un error no deseado en tu página web.

Así mismo ocurre en el ejemplo de abajo. La primera etiqueta (que no tiene espacios en blanco)...

<td><a href="#algo"><img src="/articulos/algo.gif" /></a></td>

... puede lucir diferente aunque en el navegador el funcionamiento es idéntico:

<td>
<a href="#algo">
<img src="/articulos/algo.gif" />
</a>
</td>

¿Por qué ocurre esto? El "error del espacio en blanco" era un problema conocido en las versiones anteriores a la 3.0 del Netscape Navigator. Cuando Microsoft decidió construir un navegador para competir, los ingenieros imitaron mucho el comportamiento del Netscape - incluyendo algunos de sus errores. Nuestra suposición es que MSIE6 continúa copiando esos errores del viejo Netscape.

Independientemente de por qué IE6 se comporta así, nuestras reglas tradicionales (display: block) arreglan el problema en ese navegador también. Alguna versión de (display: block) probablemente resuelva tu problema en Mozilla/NN6 e IE6.

Buena vida con XHTML

Cuando son debidamente usados, los estándares del W3C acentúan la accesibilidad y prometen durabilidad a largo plazo (a la cual le llamamos "compatibilidad adelantada") para cada documento publicado en la red. Si quieres alcanzar la mayor audiencia por el mayor tiempo posible, tienes que trabajar con los estándares de la web, y cuando preocupa la estructura del documento el XHTML es el camino.

Mientras que algunos estándares del W3C tienen la intención de ayudar a lograr tareas complejas, XHTML y las hojas de estilo son para todos y el W3C ha hecho esfuerzos para asfaltar el camino hacia XHTML.

Las reglas del XHTML toma minutos aprenderlas y los beneficios de este lenguaje son inmensos. Es fácil escribir un XHTML e igualmente fácil convertir HTML a XHTML a mano. Tidy puede ayudar a automatizar el proceso siempre y cuando te tomes unos minutos para leer la documentación antes de oprimir el botón.

Los validators en línea te ayudan a garantizar que tu XTHML y CSS son válidos, aunque los reportes de error pueden algunas veces confundirte y en raras ocasiones el validator puede portarse mal.

Después de la conversión a XHTML, puedes necesitar ajustar tu hoja de estilo para compensar la presentación de las imágenes que por defecto traen algunos navegadores, particularmente cuando están dentro de tablas, pero cuando haces esto como parte de tu trabajo se convierte en costumbre. Y como los nuevos navegadores continúan ganando mercado, nosotros haremos menos y menos diseños que trabajen con tablas y más a través de CSS.

Con un poco de atención XHTML ayudará a que los sitios funcionen mejor en más navegadores y dispositivos, de esta manera alcanzaremos un gran número de lectores, en la actualidad y en los años por venir. ¿Qué más quieres preguntar?

Traducción por el equipo de Proyecto Web (Cuba) y Pablo Impallari (Argentina).

Traducido también al Frances en Pompage.net

Scour Design - Todos los Derechos Reservados - Carlos Carmona