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.)
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.
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.
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.
Usuarios que han visto este tema también han visto...
- Maneras de aprender de los visitantes
- Principios generales del diseño web
- Web mining en el diseño de sitios web
- Tagging, Folksonomies y Tag clouds
- Principios básicos de la interacción de Alistair Sutcliffe.
- Versión imprimible de este documento
- Enviar por e-mail este documento
Información legal | Política de Privacidad | Contacte con nosotros
Otro proyecto de Factoría de Internet. Copyright© 2003-2008 Factoría de Internet S.L.. Todos los derechos reservados.