Buena vida con XHTML (2da parte y última)
Por Jeffrey Zeldman (Traducción al castellano autorizada).
Traducido por: Carlos Martínez Pérez. Ciego de Ávila. PROYECTOWEB. Cuba.
Revisado y Corregido por: Pablo Impallari. Argentina.
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. 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 © 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 revisar nuestro código y encontrar el error. Les agradecemos, corrigieron el error y volvimos a trabajar.
Si hubiéramos estado trabajando en un proyecto de un cliente en lugar de un sitio personal, no se habría subido la página hasta 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 es un recurso gratis mantenidos 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ú:
Y aquí está como Netscape 6.2/Mac lo consideró:
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 es arregla el menú. La segunda son los 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 IE5/Mac 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.
(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="algo.gif" /></td>
puede verse diferente a:
<td>
<img src="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="algo.gif" /></a></td>
... puede lucir diferente aunque en el navegador el funcionamiento es idéntico:
<td>
<a href="#algo">
<img src="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?
Artículo Original en Inglés: Better Living Through XHTML - A List Apart
Traducido también al Francés en Pompage.net |
Suscribirse al Boletín
