¿XHTML5 está muerto o es solo un sinónimo de HTML5?

87

Entonces, ¿qué pasó con XHTML5?

http://www.w3.org/TR/html5/

¿Esa página es un borrador para xhtml5 y html5? Entonces, ¿no hay diferencia entre estos doctypes?

W3C
fuente
1
Parece que a partir del 2014-12-08 que W3C todavía está trabajando en el estándar. w3.org/TR/html5 y w3.org/TR/html5/the-xhtml-syntax.html se actualizaron el 28-10-2014.
Russel Winder
66
¡Hoy en día, 2015, XHTML es un estándar W3C! ... Ver discusión actualizada
Peter Krauss
2
Aceptaste la respuesta incorrecta. La respuesta de vaxquis es la respuesta correcta.
JacquesB

Respuestas:

77

En 2012, al momento de escribir, estaba claro que W3C decidió abandonar XHTML por HTML 5. Esta decisión fue motivada por varias razones:

  • Solo unas pocas personas estaban realmente interesadas en XHTML. La mayoría de los sitios web fueron escritos en HTML simple.

  • Incluso menos realmente entendieron de qué se trata XHTML y cómo usarlo. Demasiados sitios web que pretendían servir XHTML usaban encabezados incorrectos, en lugar de Content-Type: application/xhtml+xml.

  • Incluso cuando comprenda completamente qué es XHTML y cuáles deben ser los encabezados, la cosa es realmente complicada con algunos navegadores malos que no aceptan / admiten el application/xhtml+xmltipo de contenido. Esto significaba que tenía que cambiar el encabezado de acuerdo con el navegador.

  • La parte XML de XHTML también causó algunas situaciones extrañas que los desarrolladores tuvieron que resolver. Uno es el INVALID_STATE_ERR: DOM Exception 11mensaje que aparece cuando asigna el texto que contiene caracteres HTML (como é) a un elemento dentro de la página XHTML. Cuando encuentra este error con su mensaje muy útil en una aplicación web grande después de hacer una solicitud AJAX, realmente no tiene idea de si es culpa de JQuery, AJAX u otra cosa.

  • Escribir código HTML 5 no significa mezclar etiquetas por todas partes. Si eres un apasionado de XML y XHTML, aún puedes escribir código HTML 5 que se verá muy cerca de XML.

  • En los primeros días de los teléfonos móviles, XHTML era interesante para los dispositivos móviles que no eran muy potentes. Analizar XML es mucho más fácil que HTML. Ahora, con dispositivos móviles de doble núcleo, realmente no importa si tienen que analizar XML válido o HTML sucio lleno de hacks y etiquetas mixtas.

La especificación de octubre de 2014 menciona la sintaxis XHTML . Por el momento, no está claro si existe algo como el nuevo lenguaje XHTML (no la sintaxis ), y si lo hay, cuál será la posición de XHTML, ni la adopción del nuevo estándar XHTML por parte de los principales navegadores.

Arseni Mourzenko
fuente
11
Creo que lo único que falta es su respuesta es una referencia al marcado políglota
yannis
2
Sin embargo, puede servir HTML5 como XML y obtener el beneficio de una sintaxis más estricta.
Erik Reppen
3
@ErikReppen pero perderá el beneficio de referencias de entidades como 
Mr Lister
44
Una terrible decisión. Descartamos las herramientas XSL que habrían estado disponibles con XML.
Mihai Danila
55
Esta afirmación es falsa. El W3C no ha abandonado XHTML en HTML5 La sintaxis, vocabulario y API XHTML
Rob
32

XHTML5 es sinónimo de "HTML5 serializado como XML".

Existen varias sintaxis concretas que se pueden usar para transmitir recursos que usan este lenguaje abstracto, dos de los cuales se definen en esta especificación.

...

La segunda sintaxis concreta es la sintaxis XHTML, que es una aplicación de XML. Cuando un documento se transmite con un tipo XML MIME, como application / xhtml + xml, los navegadores web lo tratan como un documento XML para que lo analice un procesador XML. Se recuerda a los autores que el procesamiento para XML y HTML es diferente; en particular, incluso los errores menores de sintaxis evitarán que un documento etiquetado como XML se represente por completo, mientras que se ignorarían en la sintaxis HTML. Esta especificación define la versión 5.0 de la sintaxis XHTML, conocida como "XHTML 5".

Además, hay un buen documento sobre cómo escribir políglotas HTML5 (páginas, que se pueden serializar tanto como HTML5 como XML normal) aquí:

http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5

¡Y un validador incluso!

http://html5.validator.nu/

Raramente se llama XHTML5 hoy en día (y probablemente aún más rara vez se usa), ya que básicamente sigue siendo HTML5, pero todavía está allí.

En pocas palabras: cada cambio a la especificación HTML5 también es un cambio implícito y correspondiente a XHTML5.

vaxquis
fuente
10

¡HTML5 es un estándar de facto y de jure ! XHTML está allí, como estándar también.

HTML5: vocabulario y API asociadas para HTML y XHTML

Recomendación del W3C 28 de octubre de 2014

El título del estándar contiene la cadena "y XHTML" , por lo tanto, estamos hablando de una decisión final de W3C de fusionar HTML y XHTML en un solo estándar ; y este estándar muestra cómo serializar un archivo HTML en un archivo XHTML y viceversa.

XHTML partes y notas importantes:


Comprender y usar

Como lo resume LF Sikos

XHTML5 es la serialización XML de HTML5. La sintaxis se describe en la especificación HTML5. Sin embargo, uno no debe confundirse ya que XHTML5 es como una aplicación de XML. En otras palabras, HTML5 y XHTML5 tienen un vocabulario idéntico pero diferentes reglas de análisis.

Los documentos HTML5 también pueden ser documentos XML válidos. Este marcado a menudo se denomina lenguaje "políglota". Es el lenguaje de superposición de documentos que son documentos HTML5 y XML al mismo tiempo. Las serializaciones HTML5 y XHTML5 son compatibles entre sí. Sin embargo, XHTML5 tiene una sintaxis más estricta. Además, algunas partes de XHTML5 no son válidas en HTML5, por ejemplo, instrucciones de procesamiento.

Entonces, estrictamente hablando (y enfatizado por @vaxquis) "XHTML es solo una sintaxis para la serialización XML", no hay DTD u otro tipo de esquema XML .

A algunas personas no les gusta decir "XHTML5 es XHTML". La pregunta debe dividirse en una mini-pregunta frecuente sobre "cuándo puedo usarla como XHTML". Este es un WIKI, corríjalo si hay algún "malentendido" ...


Preguntas más frecuentes

¿Puedo usar XHTML5 como la "versión 2014 del estándar XHTML"?

Hay algunos problemas en una "conversión de HTML5 a XHTML5 / XHTML5 a HTML5 perfecta y genérica", debe hacer "elecciones personales" e información perdida. Como el contexto serán diferentes respuestas:

  • Hablando libremente : SÍ. Hay muchos ejemplos (simples) donde el mapeo es perfecto y reversible.

  • Estrictamente hablando : NO. Consulte también el comentario de @vaxquis a continuación y las respuestas anteriores en esta página. Algunos problemas típicos:

¿Puedo usar (sin miedo) la serialización XHTML5 con XSLT, XPath, etc.?

Sí tu puedes. Incluso serializando fragmentos.

¿Puedo validar XHTML5?

Sí, pero no tan rápido y fácil como los viejos DTD ... Ver validadores complejos, como validator.nu

¿Puedo usar XHTML5 como salida no terminal en una cadena XSLT?

Sí tu puedes. Vamos a explicar lo que puedes.

Algunos marcos, como Cocoon , usan " cadenas XSLT ". Las salidas HTML5 y XHTML5 se pueden usar como "última salida en la cadena" ... Por supuesto, en pasos intermedios, HTML5 no se puede usar porque no es XML, pero se puede usar XHTML5.

El problema anterior de validación reaparece aquí: no existe una convención fuerte, por lo que, a veces, aparece menos claridad de la "estructura estándar XHTML". En esa situación, debe prestar atención en las "convenciones de usted mismo" y ser coherente.

Cuando uso DOMDocument de una página HTML5, ¿puedo usar un saveXML()método?

Si. Esta es una situación típica en la que se utilizan las recomendaciones de serialización. El XML será válido, el código XHTML5 se asigna del estado original de HTML5 y DOM ... Pero, en algunas estructuras, se puede perder cierta información, como se comentó anteriormente.

Peter Krauss
fuente
no. XHTML es solo una sintaxis para la serialización XML de HTML5, que es un tema que ya cubrí en mi respuesta hace aproximadamente un año. No hay "fusión", porque ya estaba "fusionada" por los primeros borradores W3C / WHATWG HTML5 después de archivar XHTML 2.0; Estás malinterpretando el contexto aquí. Además, XPath y XSLT solo están relacionados tangencialmente con el asunto; Además, ¿cómo es un tipo MIME conocido como "parte y / o nota XHTML"? Además, básicamente no se puede serializar HTML en XHTML: la solución propuesta es escribir la serialización de políglotas como ambas, no "volver a serializarla".
vaxquis
hum ... @vaxquis, ok, edité, por favor ayuda. Y aquí, en los comentarios, hablemos en el mismo idioma: usted usa "hablando estrictamente" y yo usé "hablar más amplio" en la introducción ... Ahora podemos señalar en el texto de la respuesta lo que desea corregir.
Peter Krauss
9

Sí, desafortunadamente XHTML se ha ido.

Agregando 1 razón más a la gran respuesta de MainMa:

Cuando se creó XHTML, estaba destinado a ser utilizado por WebApps para servir contenido estructurado que sería comprendido por software que no sea del navegador, que no tendría analizadores HTML de etiquetas. Para ScreenReaders, XHTML sigue siendo excelente, pero para cualquier otro tipo de software, los servicios web se ajustan a esa necesidad, y en su mayoría usan XML o JSON. SOAP tiene su propio esquema XML, más simple que XHTML y orientado a operaciones.

Por lo que sé, ni siquiera hay una aplicación web en el mundo que sirva el mismo mensaje HTTP tanto a los navegadores como a otros clientes. Incluso la arquitectura REST, que estaba destinada a servir la misma representación de un contenido en múltiples tipos de contenido según las preferencias del cliente, no se usa para servir navegadores XHTML / feed.

En Java EE, por ejemplo, usando Eclipse podemos implementar un archivo war único que contiene Servlets + JSP para servir HTML, junto con Axis2 para servir un Servicio Web. Simplemente es más fácil desarrollar softwares separados destinados a navegadores y WebService que tener un software único y complejo que les sirva a todos.

La razón principal por la que se rechaza REST es exactamente la complejidad (¡y estaba destinado a ser simple!) De desarrollar un servidor que sirva el mismo contenido para cualquier tipo de cliente sin saber nada al respecto. Y también es difícil manejar la necesidad de la Web de evolucionar rápidamente, junto con mantener una definición estable que no obligue a los clientes que no son navegadores a actualizarse cada vez que cambie un XHTML, dígalo para mantener el XHTML válido cuando está construido por muchos módulos diferentes.

Del mismo modo, es muy difícil desarrollar un cliente que no sea de navegador que analice un documento XHTML, incluso si es válido, debido a todos esos elementos XML que están destinados a estructurar el diseño renderizado por el navegador y no a contenido.

Si los usuarios de REST ya se quejan de la complejidad XML de SOAP, que es MUCHO más simple que un XHTML para un navegador, imagine lo difícil que es manejar XHTML para múltiples tipos de clientes, servidores y clientes.

En la práctica: use HTML, similar a XML si lo desea, para construir sitios web para navegadores, y cualquier tipo de solución de servicio web para clientes que no sean navegadores.

PERO, también creo que XHTML5 debe ser creado. XHTML 1.1 (ok, 1.0, 1.1 no se puede usar) quedará desactualizado con HTML5, y aún necesitamos un validador que acepte elementos de HTML5 y valide la buena formabilidad de XML.

Hikari
fuente
1
Tal vez llego un poco tarde, pero ¿cómo es inutilizable XHTML 1.1 en comparación con 1.0? En todo caso, su DTD contiene más elementos. ¿A menos que estés hablando de marcos y cosas así?
Sr. Lister