Miopía standardista y la paradoja de los tipos de contenido

Sobre el sinsentido de atender irrestrictamente a los estándares web, la insuficiencia de validar y la paradojal utilización de los tipos de contenido.

Hace muuucho tiempo, este artículo iba a ser una discusión sobre los futuros estándares para HTML: XHTML 2 y HTML 5. Luego, pasó a ser una discusión sobre lo jodido que resulta el parser XML, el que en teoría, debería ser el que debe ser usado al elegir un DOCTYPE XHTML. Ahora, intento resumir algo de ello y apuntar a un tema que hace tiempo me está llamando a escribir algo: los mal-llamados y auto-denominados standardistas. Aquí vale la pena hacer inmediatamente una pausa para aclarar a qué me refiero con esto: históricamente, el movimiento pro-estándares surge en un momento en el que la guerra de los navegadores había llegado a un punto en el que, como medida de lograr ventajas competitivas, cada empresa implementaba mejoras propietarias, incompatibles con los demás productos del mercado. No sólo MSIE propiciaba esto, Netscape también hacía lo suyo.

El movimiento por los estándares tenía, en principio, una gran tarea: asegurar una experiencia común para usuarios de distintos navegadores, y es en ese contexto donde respetar un estándar web encuentra su sentido. La separación del contenido y la presentación, la disminución de los tiempos de carga, la ventaja de escribir menos (y mejor) código han sido quizás los mejores argumentos en esta pelea, que al cabo de largos años ya podríamos dar por ganada —qué mejor evidencia que el interés de los desarrolladores de Internet Explorer en aumentar su conformidad con los estándares… aun con una implementación todavía muy, muy mejorable.

Entonces, como vimos y aceptamos guiar nuestro trabajo por un estándar es bueno, muchos desarrolladores comenzaron a interesarse en desarrollar con estándares… pero nada más. Su nueva insignia de orgullo y admiración no sería “Optimizado para…”, sino HTML válido; validar se convirtió en un fin, y creo que a estas alturas decir que el solo hecho de pasar la prueba del validador de la W3 es cuando menos insuficiente, y en muchos casos, engañoso.

Fue entonces que muchos comenzaron a creerse el cuento de ser standardista, no como aquellos que tuvieron la visión suficiente para pensar en un estándar como una forma de mejorar la experiencia de los usuarios, sino fijándose casi exclusivamente en el validador, y sintiéndose autorizados de apuntar con el dedo a aquellos que no pasaban esta prueba.

Junto con ello, y dado que la separación de contenido y presentación es una de sus máximas, muchos despreciaron a HTML 4 por incluir elementos y atributos representacionales, ¡una verdadera herejía! XHTML 1.0 Transitional tampoco es mucho mejor, puesto que es básicamente lo mismo que HTML 4, por lo que las únicas alternativas dignas parecen ser XHTML 1.0 Strict o XHTML 1.1… y aquí es donde llegamos a la paradoja.

A cada documento, su tipo

Si ser standardista significa un respeto irrestricto a los estándares de la W3, ¿cómo es que tantos de ellos se han olvidado de servir su contenido como corresponde? Al parecer, simplemente se saltaron ese capítulo o bien, derechamente, lo ignoran. La cuestión es que todos aquellos que lucen orgullosos sus enlaces de XHTML 1.0 Strict, pero sirven su contenido como text/html caen en una estupenda contradicción, y es que servir XHTML como text/html no es solamente erróneo según los mismos estándares por los que juran lealtad, sino que incluso puede ser considerado “dañino”.

Vamos lentamente: cuando conectamos a un servidor y éste nos envía un archivo, junto con él recibimos una indicación que señala qué tipo de documento estamos descargando. Así, cuando descargamos una imagen GIF, se envía la cabecera Content-Type: image/gif, o Content-Type: image/jpeg cuando es un JPG. De acuerdo a esa información (el content type), el cliente decide qué hacer con el archivo; en estos dos ejemplos, y asumiendo que estamos utilizando un navegador gráfico, éste nos mostrará la imagen requerida —como nota aparte: utilizaré content type y media type como sinónimos.

Con las “páginas” (me refiero al X/HTML) pasa lo mismo: el cliente solicita el archivo, recibe la información del content type y la muestra. Sin embargo, entre estos dos pasos ocurre algo muy importante: se selecciona el “parser”.

A ver, a ver… ¿que qué cresta es un parser? Básicamente, es el encargado de interpretar un documento; en este caso, documentos escritos en lenguajes de marcado como XHTML y HTML. Si las cosas fueran como deberían (pretendamos que lo son), cualquier navegador debería ser capaz de parsear un documento HTML como HTML y un documento XHTML como XHTML de acuerdo a la declaración de su media type: text/html o application/xhtml+xml, respectivamente; si las cosas fueran como deberían, tendría que existir una estricta correspondencia entre el tipo de documento, el media type y el parser. Honrando a Murphy (el de [la ley->Ley de Murphy@wiki], no [el de las películas->Eddie Murphy@wiki]), las cosas no son como deberían.

La correspondencia entre el tipo de documento y el media type pocas veces es efectiva, de hecho, la mayoría de las veces nos encontramos con que los documentos XHTML son servidos como text/html lo cual es permitido (como en May) pero no recomendado en XHTML 1 y derechamente desincentivado (como en Should Not) para XHTML 1.1 en adelante —lo pueden ver mejor explicado en en este documento de la W3 y la definición de “Should Not” en este memo.

¿Y cuál es el problema con servir XHTML como text/html? —se estarán preguntando. La respuesta no muy simple, pero por suerte a algunas personas ya se les ocurrió una forma un poco más digerible de presentarla; intentaré una traducción (por pésima que resulte), aunque de todos modos recomiendo la lectura del artículo completo:

Por qué utilizar text/html para XHTML está mal

Lo que generalmente pasa a los autores que deciden enviar XHTML como text/html es lo siguiente:

  1. El autor escribe XHTML que hace suposiciones que sólo son válidas para navegadores HTML 4 o tag soup, y no para navegadores XHTML, y lo sirve como text/html [las suposiciones se listan más abajo en este artículo]
  2. El autor encuentra que todo funciona bien
  3. El tiempo pasa
  4. El autor decide servir el mismo contenido como application/xhtml+xml porque, después de todo, es XHTML
  5. El autor encuentra que el sitio se estropea horriblemente [las razones se listan más abajo en el artículo]
  6. El autor culpa a XHTML

Sending XHTML as text/html Considered Harmful

Atención ortodoxos, servir XHTML como text/html es simplemente no seguir el estándar —cito: El media type text/html es primariamente para HTML, no para XHTML. En general, este media type NO es conveniente para XHTML (W3.org: XHTML Media Types, énfasis del original).

Quizás estén pensando “bueno, entonces la solución es simple: servir XHTML como application/xhtml+xml… pero eso no es tan simple: entonces debería ser interpretado como XML, y esto conlleva a las complicaciones (el “horrible estropeamiento”) inherentes al parser XML. La cuestión es la siguiente:

XML tiene un manejo de errores definido muy precisamente (a diferencia de HTML): cuando el parser encuentra algo inesperado, simplemente se detiene y muestra un error. Esto significa dos cosas: hace que el editar documentos XML sea más cercano a “programar de verdad” (si cometes un pequeño error [el programa] no se compila), y como no se necesita código para el manejo de errores, los parsers se hacen a la vez más rápidos y más fáciles de escribir. Como pueden imaginar, los programadores se sintieron en casa.

Why XHTML is a bad idea

Algo así:

XML Parsing Error

XHTML.com: Serving XHTML as XML

Como decía antes, si las cosas fueran como deberían, y XHTML fuera servido como application/xhtml+xml e interpretado como XML, un gran porcentaje de las páginas actuales se verían como la imagen anterior: bastaría que la codificación no correspondiera (por ejemplo, indicar ISO-8859 en vez de UTF-8), que existieran etiquetas anidadas incorrectamente, nombres de elementos en mayúsculas o un ampersand (&) no codificado para que no se viera más que una pantalla amarilla indicando amablemente el error… ¡incluso un trackback de un blog con una codificación distinta bastaría para producir un error!

The advantages of XHTML

When sent as application/xhtml+xml, XHTML has several advantages:

  1. XHTML content will be able to be mixed-and-matched with content from other well-known namespaces (in particular, MathML). This is the main advantage for content authors.
  2. Browsers will immediately catch well-formedness errors (though other errors still won’t be caught).
  3. Tools interacting with XHTML documents are guaranteed a well-formed document.

However, none of these apply when an XHTML document is sent as text/html, and since authors feel their pages should be readable on the most popular Web browser, which does not support application/xhtml+xml, there is basically no point in using XHTML at the moment.

Sending XHTML as text/html Considered Harmful

¿Qué queda entonces? Aun respetando los estándares, una solución sería utilizar XHTML 1.0 Transitional, que puede ser servido como text/html, y en consencia interpretado como HTML… ¡pero ni siquiera el HTML servido como text/html es interpretado como HTML!

Mientras que HTML 4.01 es formalmente un formato de documento basado en [SGML->@en.wiki], los únicos clientes que realmente tratan al HTML de esta forma son los validadores. Los navegadores, por otra parte, tratan al HTML como si fuera sopa de etiquetas [tag soup]— tratan hacer sentido de, y mostrar, incluso el documento más horriblemente estropeado según su mejor habilidad.

Digital Web Magazine – HTML5, XHTML2, and the Future of the Web

En resumen:

  • Servir XHTML como text/html es incorrecto según la W3
  • Servir XHTML como text/html impide cualquier beneficio de la utilización de XHTML
  • Servir XHTML como application/xhtml+xml produce que se interprete como XML, por lo que si tu código no es perfecto, tus visitantes no verán nada
  • Si aún quieres servir XHTML como text/html, podrías hacerlo con el DOCTYPE XHTML 1.0 Transitional…
  • …pero será interpretado como HTML…
  • …pero HTML es interpretado como tag soup

¿Y yo? Uso XHTML como text/html… y no me quita el sueño.

Lecturas

Inspiración: diseños de tumblelogs

He estado trabajando en algunas ideas para rediseñar mi tumblelog, y como siempre, antes de lanzarme de lleno, he querido darme algunas vueltas para observar otros diseños de tumblelogs (lógicamente, distintos a los que están disponibles en Tumblr).

Así que, veamos qué es posible encontrar…

Continue reading “Inspiración: diseños de tumblelogs”

Eufemismo

Un eufemismo es una palabra o expresión aceptable o menos ofensiva que sustituye a otra considerada vulgar, de mal gusto o tabú, que puede ofender o sugerir algo no placentero al oyente. También puede ser la sustitución de nombres secretos o sagrados, para evitar revelar éstos a los no iniciados. Algunos eufemismos tienen la intención de ser cómicos. A menudo, el propio eufemismo pasa a ser considerado vulgar con el tiempo, para ser sustituido de nuevo.

Eufemismo (Wikipedia en español)

Análisis de Vuelos Baratos

Este es un análisis patrocinado por Zync.es

Ayer recibí una oferta para una análisis pagado de Vuelos Baratos, un buscador de vuelos baratos que he visto publicitado en varios weblogs de habla hispana pero que en verdad nunca antes se me había ocurrido visitar, principalmente porque no he tenido la necesidad de buscar vuelos baratos. Trataré de analizar este sitio como una aplicación web más, ya que creo que solo desde este punto de vista puedo decir algo al respecto; así que vamos allá…

vuelosbaratos.png El sitio es básicamente un agregador de ofertas de viajes de diversas fuentes —según ellos, “cientos”: aerolíneas de bajo costo, tradicionales y agencias de viaje, a lo que se suma un “comparador multi-transporte” (tren, bus, ferry) para España y algunos destinos de Europa.

Mi primera impresión es un que se trata de un sitio bastante bien organizado, diría que casi “ideal” para concentrarnos en lo que nos interesaría al ingresar. En su portada encontramos un formulario para comparar precios de vuelos que está bien, pero no es increíble: las ubicaciones tienen auto-completado con AJAX, pero la selección de fechas no, lo que desentona un poco.

Al buscar, debemos pasar por una pantalla intermedia en la que van aparaciendo algunos datos tipo ¿Sabías qué? que no es precisamente algo que me llene de gusto… el tiempo de espera para ver los resultados es considerable (alrededor de 10 segundos), algo bien fuera de tono con la web de hoy en día. Cuando finalmente aparecen, los resultados están ordenados por precio de menor a mayor, y junto al precio final nos muestra la información de origen y destino, disponibilidad, compañía, horarios de salida y llegada, número de escalas y operador (es decir, a través de qué medio se ha encontrado la oferta). Además, podremos refinar nuestra búsqueda y cambiar la moneda de referencia, lo que resulta bastante práctico. También en la página de resultados hay una pestaña con un mapa (de Google Maps) que señala la ubicación del aeropuerto.

Además de esta modalidad “típica” de búsquedas, existe un calendario de ofertas que básicamente sirve para comparar el precio de los vuelos en diversas fechas, ideal si tienes flexibilidad en tus fechas y quieres ahorrar unos pesos.

En general, el sitio me ha parecido bastante bien, es algo que usaría de necesitarlo; sin embargo, me quedan algunos detalles que dejan de encantarme: además de la demora en presentar los resultados (que mencioné anteriormente), el diseño en general no me atrae mucho, y en especial sus colores me dejan un gusto a añejo que no me calza. La utilización de AJAX es interesante, pero creo que se le podría sacar más provecho… y si ya están en eso, podrían probar a dar más estilo a los formularios con algo como FancyForm.

Y para cerrar, una recomendación: ¡atención a la letra chica!, que ya lo saben, a veces lo barato cuesta caro

Esquema taxonómico de WordPress

Una forma gráfica de representar el nuevo esquema de taxonomías presente en WordPress 2.3 y las relaciones entre las diversas tablas

Me pidieron actualizar el código de un proyecto realizado con WordPress que usaba consultas directas a la base de datos para seleccionar posts de una determinada categoría. Como el esquema de categorías ha cambiado desde la versión 2.2 a la 2.3, tuve que aplicarme y estudiar cómo funcionan las categorías/tags en la nueva versión. Por suerte, encontré dos posts muy buenos al respecto:

Pero leer lleva tiempo (sobre todo si es una cuestión técnica que no manejo tanto), por lo que pensé que debía haber una forma más sencilla de representarlo… y gracias a Bubbl.us, tenemos esto:

Esquema de taxonomías de WordPress

También lo pueden ver en una versión Flash