| |
Año 3 - Boletín Nro 57 - jueves 8 de abril de 2004 |
Buena vida con XHTML (1ra parte)
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.
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. (CONTINUARA)
Artículo Original en Inglés: Better Living Through XHTML - A List Apart |
ProyectoWeb - Buena vida con XHTML
|
|
Suscribirse al Boletín
