body - meta html

¿Qué problema resuelve XHTML estrictamente? (13)

Realmente no entiendo la fascinación con XHTML estricta. JavaScript en línea normalmente requiere un nido de escapes para hacer que sea compatible con XHTML y semi-retrocompatible con MSIE 5 y 6. Luego está el problema de no ser lo suficientemente OCD en la entrada del usuario para asegurarse de no perder ningún personaje ilegal . Simplemente parece más esfuerzo que su valor. No importa que casi todos los desarrolladores con los que trabajé se olviden de asegurarse de que el tipo de contenido devuelto por el servidor se reinicie para páginas XHTML de texto / html a application / xhtml + xml.

Desearía saber el nombre del blogger, pero alguien más señaló que la mayoría de los sitios web supuestamente compatibles con XHTML y los paquetes de código abierto no se deben a ese último problema, olvidando configurar correctamente el encabezado de tipo de contenido.

Estoy buscando entender por qué XHTML es útil, o construir lo suficiente de un arsenal de argumentos para evitar que sea utilizado en futuros proyectos en los que tenga influencia.

Lo único que he visto resuelto por XHTML es el "problema" de los usuarios que usan Safari: no sé si el error todavía está allí, pero cuando se nos pidió por última vez escribir en XHTML, nos encontramos con un error que hizo XHTML inutilizable con Safari. En XHTML, la siguiente URL no está permitida en las etiquetas de anclaje, porque el ampersand no se escapa:

http://www.example.com/page.php?arg1=val1&arg2=val2

entonces lo que tienes que hacer es reemplazarlo con & amp; Me gusta esto:

http://www.example.com/page.php?arg1=val1&arg2=val2

pero Safari convierte & amp; a & # 38; así que obtienes esta URL:

http://www.example.com/page.php?arg1=val1&arg2=val2

... y el símbolo hash termina la URL en lo que respecta a PHP. Sé que hay hacks feos que te permiten pasar dos variables de otras maneras, pero si XHTML te va a obligar a usar hacks feos, entonces es mejor que lo hagas sin él.

Personalmente, me gustó el concepto de XHTML: mucho más limpio que la mayoría de HTML que podemos ver, más fácil de analizar y validar. Como todos, comencé a codificar páginas XHTML. Por cierto, no veo un problema con JavaScript en línea, no hay necesidad de escapes si pones el código en CDATA. Y IE5 afortunadamente está un poco fuera del panorama del navegador, como Netscape 4, que nos obligó a escribir / > lugar de /> , algo que aún veo en XML puro alguna vez ...

Ahora, he leído varios artículos, como el vinculado por Bruno, que tiene muchos buenos argumentos en contra de su uso en la mayoría de los casos . Básicamente, dice que la mayoría de los navegadores no solo están listos para XHTML estricto (servido como XML), no tiene mucho sentido para el servidor XHTML como HTML, y de todos modos no es tan útil en la mayoría de los sitios.

Mire los argumentos anteriores: son perfectamente válidos, y es genial poder colocar MathML o SVG directamente en la página, para transformar XML con un analizador XSLT, para procesar la página con un analizador XML.

Pero, ¿con qué frecuencia haces eso? El análisis de la página suele ser el problema de los usuarios finales, que pueden utilizar un buen analizador de HTML. Y dada la cantidad de navegadores capaces de administrar MathML, SVG o XSLT, es más una necesidad de Intranet que de Internet.

Puede tener un comercio electrónico o un blog o foro, que arroja buenas páginas XHTML. Y las personas que escriben las descripciones, artículos o mensajes insertan <p><p><p> para omitir algunas líneas, cuando no es <p/> o algún otro constructo exótico ...

Creo en XHTML, pero creo que ya no lo usaré para las páginas pequeñas que hago para mi sitio. Usaré HTML 4 con un código bien escrito (atributos entre comillas, etiquetas de cierre incluso si es opcional, etc.).
Y, después de todo, si W3C está trabajando en HTML 5, es por una razón: HTML todavía tiene un Live Adelante, de lo contrario hubiera sido asesinado a favor de XHTML 2.

Este es un problema estándar global

No se trata solo de xHTML, sino de todos los estándares del mundo. Necesita aclarar las cosas, de una versión a otra.

xHTML es cuadrado y empuja codificadores para agregar valor semántico al código. Es totalmente compatible con XML y por lo tanto más fácil de analizar, estilizable, etc.

Recuerde que un código no es solo para codificadores, también para máquinas. En 10 años, las personas que creen navegadores o bibliotecas no querrán implementar las mismas reglas de complejos para el procesamiento de HTML anterior, sino que esperarán algo tan limpio como sea posible.

El motor de búsqueda necesita algo en lo que confiar para construir enlaces semánticos entre los valores, por lo que es mejor si solo hay una manera fácil de hacerlo.

Y no estoy hablando de lectores de pantalla ...

Estándar, es sobre todo, ir hacia una única solución abierta que se ajuste a las necesidades de todos. No solo por agregar nuevas características brillantes.

¿Tiene que analizar su HTML con un programa, o para algunas pruebas? Entonces, usa XHTML.

Para todo lo demás, HTML 4.01 (estricto, suelto, de transición, lo que sea) es perfectamente "estándar" y menos "problemático".

Estricto tiene la intención de formalizar la separación entre el contenido y el estilo haciendo que sea más difícil mezclar los dos. Elliotte Rusty Harold tiene una buena reseña sobre XHTML en uno de sus libros, aquí está el extracto relevante sobre '' Por qué XHTML ''.

XHTML es útil porque es mucho más fácil crear una hoja de estilo de transformación simple o rodar su propio analizador para ello, que para HTML.

XHTML es, por definición, XML, a diferencia del HTML.

Esto significa que puede hacer funky cosas útiles con ella, como validar y analizar fácilmente (ya que sabe que es XML y por lo tanto puede utilizar la gran cantidad de herramientas disponibles).

Además, a los geeks les gusta hacer las cosas "más correctas" ;-)

XHTML hace que HTML sea ortogonal con todas las demás estructuras basadas en xml de nuestro universo, lo que tiene dos beneficios principales.

Los patrones de diseño que usamos al tratar con xml se pueden aplicar a html.

Herramientas de software ídem.

XHTML le permite una representación avanzada como SVG (Scalable Vector Graphics), que a su vez es un XML, pero puede incorporarse fácilmente en XHTML a través de la extensión de espacio de nombres XML sin <embed> u <object>. Desafortunadamente, solo Firefox y Safari lo admiten. Lo siento, usuarios de IE6.

Para más información sobre SVG en http://en.wikipedia.org/wiki/Svg

XHTML tiene las ventajas de xml. Pero entonces, ¿por qué la variante estricta?

Veo algunas similitudes con las funciones en desuso. Todavía puede usar esta versión, pero posiblemente se eliminen la próxima versión. Entonces veo la versión de transición como uso obsoleto. Todavía funciona y funcionará para un par de versiones, pero si quiere construir para el futuro, use la versión estricta.

XHTML1 vs HTML4 y Strict vs Transitional son problemas completamente ortogonales.

XML podría no dar ninguna ventaja enorme a los navegadores de hoy, pero en el extremo del servidor es más fácil procesar documentos usando XML que intentar analizar el desastre que es SGML de la vieja escuela, excepto HTML4 en realidad.

Restringirse a [X] HTML Strict no logra nada en sí mismo, aparte de simplemente desanimar el uso de técnicas antiguas y menos fáciles de mantener que de todos modos no debería usar.

El javascript en línea normalmente requiere un nido de escapes de ratas para hacerlo compatible con XHTML

Puedes escaparte sin escapes siempre que no uses los caracteres <o &. Y ''// <[CDATA ['' no es mucho peor que ''<! -'' en los viejos tiempos.

En cualquier caso, mantener el scripting externo es mucho más manejable; no quieres hacer nada significativo en línea.

Luego está el problema de no ser suficiente con el TOC a la entrada del usuario para asegurarse de no perder ningún carácter ilegal.

Los caracteres fuera de banda son exactamente tan inválidos en HTML4 Transitional como en XHTML1 Strict.

Si aceptas el HTML enviado por el usuario y no lo revisas / escapas con suficiente peine fino para evitar errores de buena formación, tienes problemas mucho más grandes que simplemente cumplir con un doctype. Dejará que los ataques de inyección pasen por alto y hará que su sitio sea vulnerable a los agujeros de seguridad de secuencias de comandos entre sitios.

olvidándose de asegurarse de que el tipo de contenido devuelto por el servidor se restablece para páginas XHTML de texto / html a aplicación / html + xml.

No es ''olvidar'', es deliberado: no hay mucho sentido en servir application / xhtml + xml hoy. Para dar cuenta de IE, debes olfatear UA y luego asegurarte de que entiendes las diferencias de CSS y JavaScript que aparecen en ambos modos de análisis ... puedes hacerlo para demostrar tu destreza técnica, pero realmente no te da nada .

Servir XHTML como HTML heredado puede no ser el ideal, pero le permite mantener la sintaxis de XML más sencilla y procesable (y la posible interoperabilidad con otros lenguajes XML como SVG) sin dejar de ser navegable.

La gente se queja de los errores de buena formación, pero tener esos errores recogidos de inmediato para que los corrijas es mucho mejor que dejarlos allí en silencio, listos para tropezar con un futuro navegador.

hay una gran publicación sobre el uso de XHTML @ Cuidado con XHTML .

Espero que ayude, Bruno Figueiredo

XHTML 1.0 Strict intenta resolver cuatro problemas:

XML es tecnología W3C y HTML4 no lo estaba usando. No es tu problema.
Estricto busca ser más teóricamente puro que Transicional cuando se trata de presentacionalismo. Pero esto no es un problema XHTML vs. HTML .
El analizador XML es supuestamente más simple. (No del todo cierto, el código para tratar con la parte DTD es bastante complejo.) Estos días, usted obtiene los analizadores XML y HTML listos para usar , por lo que este no es su problema. (Aparte: el argumento del móvil es completamente falso ).
application / xhtml + xml (aunque no es válido XHTML 1.0 Strict!) le permite mezclar otros vocabularios. Si desea utilizar MathML o SVG en línea hoy, esta es la razón principal para usar application / xhtml + xml hoy. Sin embargo, la dirección que está tomando el trabajo HTML5 es hacer posible el uso de MathML y SVG en text / html.