Entonces, ¿qué pasó con XHTML5?
¿Esa página es un borrador para xhtml5 y html5? Entonces, ¿no hay diferencia entre estos tipos de documentos?
En 2012 en el momento de redactar este documento, quedó claro que W3C decidió abandonar XHTML para HTML 5. Esta decisión fue motivada por varias razones:
Solo algunas personas estaban realmente interesadas en XHTML. La mayoría de los sitios web estaban escritos en HTML simple.
Incluso menos entendieron realmente de qué se trata XHTML y cómo usarlo. Demasiados sitios web que pretendían servir XHTML utilizaban encabezados incorrectos, en lugar de Content-Type: application/xhtml+xml .
Incluso cuando entiendes completamente qué es XHTML y cuáles deben ser los encabezados, la cosa es realmente complicada con algunos navegadores de mierda que no aceptan / apoyan el tipo de contenido application/xhtml+xml . 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. Un mensaje es INVALID_STATE_ERR: DOM Exception 11 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 realizar una solicitud AJAX, realmente no tiene idea de si es culpa de JQuery, AJAX o algo más.
Escribir código HTML 5 no significa mezclar etiquetas por todas partes. Si le apasiona XML y XHTML, aún puede 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 los dispositivos móviles de doble núcleo, realmente no importa si tienen que analizar XML limpio y limpio o HTML sucio lleno de hacks y etiquetas mixtas.
La especificación de octubre de 2014 menciona sintaxis de XHTML . Por el momento, no está claro si existe algo como el nuevo lenguaje XHTML (no sintaxis ), y si existe, cuál será la posición de XHTML, ni la adopción del nuevo estándar XHTML por parte de los navegadores principales.
XHTML5 es un sinónimo de "HTML5 serializado como XML".
Hay varias sintaxis concretas que pueden usarse 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 MIME XML, como application / xhtml + xml, los navegadores web lo tratan como un documento XML y lo analiza un procesador XML. Se recuerda a los autores que el procesamiento para XML y HTML difiere; en particular, incluso los errores de sintaxis menores evitarán que un documento etiquetado como XML se presente completamente, mientras que se ignorarán en la sintaxis HTML. Esta especificación define la versión 5.0 de la sintaxis XHTML, conocida como "XHTML 5".
También, hay un buen documento sobre cómo escribir políglotas HTML5 (páginas, que pueden ser serializadas como HTML5 y XML normales) aquí:
Y un validador incluso!
Raramente se llama XHTML5 en la actualidad (y probablemente aún se usa menos), ya que básicamente sigue siendo HTML5, pero sigue ahí.
En pocas palabras: cada cambio a la especificación HTML5 también es un cambio implícito, correspondiente a XHTML5.
HTML5 es un de facto y de jure estándar! XHTML está ahí, como estándar también.
Recomendación W3C 28 de octubre de 2014
El título del estándar contiene la cadena "y XHTML" , por lo que estamos hablando de una decisión final del W3C de combinar 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:
application/xhtml+xml
Como se resume en LF Sikos
XHTML5 es la serialización XML de HTML5. La sintaxis es descrita por 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, en las instrucciones de procesamiento.
Entonces, estrictamente hablando (y enfatizado por @vaxquis) "XHTML es solo una sintaxis para la serialización XML", hay no DTD u otro tipo de esquema XML .
A algunas personas no les gusta decir "XHTML5 es XHTML". La pregunta debe dividirse en una mini-FAQ sobre "cuándo puedo usarla como XHTML". Este es un WIKI, corríjalo si hay algún "malentendido" ...
Hay algunos problemas en las "conversiones de HTML5 a XHTML5 / XHTML5 a HTML5" perfectas y genéricas ", debes hacer" elecciones personales "e información perdida. Como el contexto serán diferentes respuestas:
Hablando suelto : SÍ. Hay muchos ejemplos (simples) donde el mapeo es perfecto y reversible.
Estrictamente hablando : NO. Vea también el comentario de @vaxquis a continuación y las respuestas anteriores en esta página. Algunos problemas típicos:
Sí, puedes. Incluso serializando fragmentos.
Sí, pero no tan rápido y fácil como los antiguos DTD ... Ver validadores complejos, como validator.nu
Sí, puedes. Vamos a explicar lo que puedas.
Algunos marcos, como Cocoon , usan " Cadenas XSLT ". Las salidas de HTML5 y XHTML5 se pueden usar como "última salida de 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 vuelve a aparecer aquí: no hay una convención fuerte, por lo que, a veces, aparece menos de la "estructura estándar de XHTML". En esa situación, debe prestar atención en "sus propias convenciones" y ser coherente.
saveXML() ? Sí. Esta es una situación típica donde se utilizan las recomendaciones de serialización. El XML será válido, el código XHTML5 se asignará desde el estado original de HTML5 y DOM ... Pero, en algunas estructuras, se puede perder cierta información, como se comentó anteriormente.
Sí, lamentablemente 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 se entendería por software que no sea de navegador, que no tendría analizadores HTML de sopa 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, utilizan XML o JSON. SOAP tiene su propio esquema XML, más simple que XHTML y orientado a la operación.
Mientras sé, no hay ni siquiera una aplicación web en el mundo que sirva el mismo mensaje HTTP para los navegadores y otros clientes. Incluso la arquitectura REST, que estaba destinada a servir a la misma representación de un contenido en varios tipos de contenido según las preferencias del cliente, no se utiliza para servir a los navegadores XHTML / feed.
En Java EE, por ejemplo, al utilizar Eclipse podemos implementar un archivo de guerra único que contiene Servlets + JSP para servir HTML, junto con Axis2 para servir a un Servicio Web. Simplemente es más fácil desarrollar software separado para navegadores y servicios web que tener un software único y complejo que sirva a todos.
La razón principal por la que se rechazó REST es exactamente la complejidad (¡y estaba destinada 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 una rápida evolución, además de mantener una definición estable que no obligue a los clientes que no utilizan navegadores a actualizarse cada vez que cambia un XHTML, dígalo para mantener el XHTML válido cuando está construido por muchos módulos diferentes.
De la misma manera, es muy difícil desarrollar un cliente sin 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 representado por el navegador, y no para mantener contenido.
Si los adoptantes de REST ya se quejan de la complejidad XML de SOAP, que es mucho más simple que un XHTML destinado a un navegador, imagine lo difícil que es manejar XHTML para múltiples tipos de clientes, servidor y cliente.
En la práctica: use HTML, similar a XML si lo desea, para crear 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 es inutilizable) quedará desactualizado con HTML5, y todavía necesitamos un validador que acepte los elementos de HTML5 y valide el formato XML.
Echa un vistazo a xHTML5.me. ** ¡Nota final! ** Todavía dudo que Google mantenga muchas páginas html actualizadas. No quiero que otras personas cuenten esto. Dicho esto, sigue siendo genial ver una nueva superficie de herramientas para XHTML, pero con el tiempo a medida que crecen las páginas wiki, ¡también debería crecer la cantidad de proyectos que piensan en XHTML! De lo contrario, tendré que apagar y volver a HTML normal nuevamente, lo que probablemente esté bien ... a través de la bajada lenta de Smartphone... Lee mas