ademas la idea de los estandares es para presionar alas grandes empresas a q’ no hagan lo que se les pegue la gana y que cada quien muestre las paginas como quieran, fue por eso que se establecieron los standares, para que casi todos hagamos las cosas bien y cualquiera lo pueda entender y renderizar, pero sigue siendo una RECOMENDACION…

saludos desde cancun mexico

@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

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.

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 &