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, no el de las películas), 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, 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

Publicaciones relacionadas

  • http://www.cuatroxl.com acido69

    buen articulo!!! :P

  • http://www.noth.es noth

    Un árticulo genial!! y completamente de acuerdo en todo, yo puede decirse que sea un standirsta de esos que comentas, y siempre hago las páginas en xhtml 1.0, las válido y demás

    Cuando miré que doctype usar me dí cuenta de lo que tu comentas y que debería usar el html 4 stritc (para obligarme a no usar elementos deprecated) pero tampoco me gusto el que me permitiriera no cerrar los elementos etc.. con lo que algun error me sería más difícil de encontrar.

    Mi solución el xhtml 1.0 strict, pero lo que tu dices se te escapa un & y la liaste, el problema no es una página estática si no las dinámicas.

    Así que uso el xhtml 1.0 enviado como text/html y aunque se que es un error explicale al cliente que no se ve porque se ha escapado un & :)

  • http://escuriola.es Elesku

    Muy buen artículo, me ha gustado con sus ejemplos y tal, aunque al final me he perdido y no me ha quedado claro quien es el malo maloso de la película…

  • http://www.webmasterlibre.com Alma

    Hace tiempo un amable norte americano me envió un correo al blog con un enlace a un artículo de este estilo. Después de mucho meditarlo he decidido utilizar html 4.01 estricto para los sitios web y dejar el xhtml para los escasos sitios donde debo servirlo como xml.
    Soy de esas que tiene esperanza en lo que salga del HTML 5, pero supongo que seguirá siendo todo una cuestión de simples preferencias.

  • http://www.estandaresyaccesibilidad.com/ Tu nombre

    Por fin alguien publica esto en español.. Gracias.. Muy bueno!

  • quique

    aver, hay algunos conceptos erroneos de tu parte sin desmerecer obviamente lo que haz expuesto recientemente
    xhtml = html + estandarizacion
    html = xhtml – estandarizacion

    por lo tanto como conclusion xhtml no es otro lenguaje de maquetado de etiquetas sino que una version optimizada y ordenada de representar elementos correctos.

  • http://www.yukei.net Felipe Lavín Z.

    @acido69, @Tu nombre: gracias!

    @noth: y no solamente cuando se escapa un &, que como ponía en el post, basta recibir un ping/trackback en otra codificación para que no se vea nada. Como ponen por ahí, probablemente la solución más “coherente” (en términos de apego a los estándares) sea utilizar HTML 4 Strict, servido como text/html, lo que no está exento de problemas, como que algunos frameworks javascript (y creo que en puntual, con mootools pasa esto) requieren (no tengo idea porqué) de un DOCTYPE XHTML

    @Elesku: no diría que hay un malo de la película, lo que sí es que hay muchos sobre- y mal-entendidos… y al final, al menos para mí, lo que debería quedarnos es que trabajar con estándares no nos hace “mejores”, no es una forma de trabajar, es la forma de trabar, no solo porque es “la forma correcta”, sino también porque es una forma rápida y directa de hacer las cosas, o como pone Jeff Croft, otorga grandes ventajas… y ahí donde no las proveen, es necesario buscar otras soluciones. Al final, se trata de trabajar con estándares, sí, pero de una forma esencialmente pragmática, no dogmática.

    @Alma: de hecho, HTML 5 es otro gran tema, del cual parte este post y del que aun no acabo de formarme una opinión ya que entre el primer y el último borrador que ví habían implementado cambios notables, no así en XHTML 2, donde (como quizás se puede desprender de mi post) para mí el mayor problema es que con él sí que se debería utilizar un content type application/xhtml+xml y el parser XML… aparte, claro, del “pequeño gran detalle” de que no otorga backwards compatibility. A la rápida, creo que si el equipo de HTML 5 tuviera no solo sus metas sino también sus principios más definidos, la discusión ya se habría resuelto hace tiempo a su favor, aunque lo más probable es que en la práctica nos encontraremos con la coexistencia de ambas recomendaciones.

    @quique: creo que no entiendo lo que planteas, ya que hasta donde sé (y lo que puedo ver en los documentos de la W3), XHTML 1.0 es una reformulación de HTML 4 como aplicación XML 1.0, pero HTML 4 también tiene el “rango” de especificación

    En realidad, si fuéramos rigurosos con la terminología, ni HTML ni XHTML son “estándares”, ambos son “especificaciones” a las que la W3 otorga la calidad de “recomendaciones”.

    La optimización a la que haces mención, hasta donde puedo ver, no se produce con la especificación de XHTML 1.0 propiamente tal (aunque ya entonces hay un trabajo de ordenamiento y que implica una mayor rigurosidad en la utilización del marcado), sino con la modularización de XHTML, donde los elementos y atributos se clasifican en módulos abstractos, pero en verdad no se trata de un nuevo lenguaje, sino, como dices, la ordenación y optimización del mismo… el mismo XHTML 1.0, que en el fondo es el mismo HTML 4…

    En otras palabras, no creo que HTML no sea “estandarizado”, sino más bien que XHTML ha sido “ordenado y optimizado” para funcionar como XML… lo cual, a todo esto, viene a reafirmar la contradicción que implica servirlo como text/html

  • http://escuriola.es Elesku

    Una cuestión que me viene ahora a la cabeza es cuando utilizas un CMS, en estos casos muchas veces no puedes elegir con que trabajar, pese a que te esfuerces en hacer las cosas bien, dependes de cómo han construido el núcleo o los módulos o los plugins que utilices… ¿Dónde estaría la solución para hacer las cosas de la mejor forma posible? O quizá de intentar hacerlo lo menos mal…

  • http://www.ultimorender.com.ar/funkascript/ manuel

    Hola! Un detalle, sobre la definición de standardista… que creo que lo aclarás más abajo en un comment, te referís al standardista dogmático de Jeff Croft (lo que Molly directamente llama podrido). No está de más aclarar que hay standardistas mucho más pragmáticos (ver mismo artículo de Molly). Y considerar que tal vez sin algunos de estos dogmáticos (o evangelistas muy cabezaduras) ni siquiera estaríamos hablando de este tema ;)

  • Pingback: ESTANDARÍZATE » Miopía estándarista