Ian Hickson realizó un pequeño experimento y lo publicó en la lista de distribución de la W3C, lo traduzco:
Hice un pequeño estudio recientemente comprobando únicamente los errores sintácticos de documentos HTML, y los resultados fueron que de 667.416 archivos testeados, 626.575 tenían errores sintácticos. Más del 93%.
Sólo errores sintácticos en el HTML, no comprobé el CSS, el contenido, los errores semánticos (por ejemplo IDs duplicados — 86.461 documentos del espacio muestral contenían IDs duplicados ), u otro tipo de errores.
Si incluimos estos, encontraremos que la mayoría de las paginas contienen algún tipo de error que dispara la alerta. Así que algún tipo de UI estaría continuamente diciéndonos esta pagina tiene errores. Esto no sería un buen UI para la mayoría de los usuarios, a los que simplemente no les importa.
Ante lo que Tim-Berners Lee, el padre de la Web, concluía con que el movimiento para una Web bien formada con XHTML ha fallado:
Tengo algunas cosas claras con el paso de los años. Necesitamos evolucionar HTML de manera incremental. En intento de que todo el mundo cambiara a XML, incluyendo el entrecomillado del valor de los atributos, las barras para cerrar las etiquetas vacías y los espacios de nombre, todo a la vez no funcionó. La mayoría de gente que publicaba en HTML no movió un dedo, en gran medida porque los navegadores no se ajustaron al nuevo sistema. Algunas comunidades si que dieron el paso y están disfrutando de los frutos de los sistemas bien formados, pero no todos. Es importante mantener HTML de manera incremental, así como continuar la transición al mundo de los documentos bien formados, y enfatizar ese mundo.
Posiblemente sea por eso que ahora mismo hay 63 errores de validación en la pagina principal de Google. Nos guste o no, vivimos en un mundo mal formado. Los navegadores no son compiladores, y siempre han sido, tolerantes por diseño.
A tu navegador no le importa si tu HTML está bien formado. Tus usuarios/clientes ni siquiera saben lo que es HTML, así que tampoco les importa si esta bien formado o no. ¿Entonces, por qué te debería importar?
La mayoría de los problemas que presenta este artículo vienen de la primera gran guerra de los navegadores de Internet disputada entre Netscape y Microsoft a mediados de los 90. Echarle las culpas a Microsoft sería muy fácil pero realmente es tan culpable uno como otro porque ambos se dedicaron a inyectar en la web funcionalidades incompatibles entre sí. El hecho de que HTML por aquel entonces, ni era formal ni estaba ampliamete probado, no hizo más que empeorar la situación.
Los navegadores no son compiladores, pero quizá si deberían serlo ya que procesan un lenguaje formal y como tal está regido por una gramática y una semántica que definen su construcción y significado unívocamente. Actualmente un navegador se programa dos veces: una bien, respetando el lenguaje y otra mal para corregir ese 93% de errores. Esta situación hace que el renderizado de documentos no sea óptimo bajo casi ninguna circunstancia y los navegadores empleen dos métodos de renderizado: standard compliance y quirks mode. ¿Cuantos parches críticos recibe IE a lo largo del año para corregir hacks a través de código mal formado? Muchos.
Replanteemos la situación. Si yo escribo en C y olvido un punto y coma, el compilador me dirá que tengo un fallo; si olvido inicializar una variable entera o hago algo raro con un puntero me dirá “tu código, aunque puedo compilarlo, es posible que dé problemas” y sabré que efectivamente si porto el código a otra maquina u otro compilador aquello no va a funcionar.
A tu compilador no le importa que tu código devuelva 5.000 warnings. Tus usuarios/clientes ni siquiera saben lo que es un warning. ¿Entonces, por qué te debería importar? Si tu código devuelve 5.000 warnings no tienes perdón de $DEITY, deberías considerar aprender a programar en lugar de hacer Crtl+C Crtl+V desde Google, porque me juego el cuello a que semejante aberración es imposible de mantener.
¿A tus clientes/usuarios les importa estar bien posicionados en los buscadores? ¿Te importa a ti?
El código mal formado funciona más o menos bien en la mayoría de los navegadores porque las empresas han invertido mucho tiempo y dinero en el manejo de estas situaciones. Lo han hecho porque los usuarios así lo demandan. Pero no esperes que los parsers que utilizan los robots buscadores actuen de la misma manera que tu navegador favorito (de echo no lo hacen).
Si olvidas las comillas alrededor de una URL, posiblemente el robot no sepa que tiene que indexarla, o quizá sí. ¿Cómo prodríamos estar seguros? ¿Quieres correr el riesgo? Si tu código es válido no te tienes que preocupar de estas cosas.
Un documento HTML mal formado es prácticamene imposible de depurar, es una escopeta de feria que puede estallar en tu cara en cualquier momento: Javascript, CSS, AJAX, todas esas tecnologías esperan un documento bien formado para aplicarle cambios. Si tu árbol XML está cojo nada va a funcionar o como poco tendrás increíbles dolores de cabeza para saber qué demonios anda mal y cómo corregirlo para que funcione bien en todas las plataformas.
Un documento HTML mal formado o con una semántica pobre es infinitamente más complicado de modificar y mantener mediante scripts PHP, JSP, ASP o la tecnología que utilices. ¿Habéis intentado modificar mediante PHP un layout hecho con tablas?
Esto no va de ser más cool, más 2.0, de lucir camisetas con tags XHTML. Esto va de producir más, con mayor calidad, simplificar el mantenimiento e intercomunicación entre aplicaciones.
Jeff Atwood también habla del tema, aunque parece no tenerlo tan claro como yo 
menéame
