Em 2012 no momento em que escrevo, ficou claro que o W3C decidiu abandonar o XHTML pelo HTML 5. Essa decisão foi motivada por várias razões:

• Apenas poucas pessoas estavam realmente interessadas em XHTML. A maioria dos sites foi escrita em HTML simples.

• Menos ainda realmente entenderam o que é XHTML e como usá-lo. Muitos sites que pretendiam servir XHTML usaram cabeçalhos errados, em vez de Content-Type: application/xhtml+xml .

• Mesmo quando você entende perfeitamente o que é XHTML e quais devem ser os cabeçalhos, o problema é realmente complicado, pois alguns navegadores de baixa qualidade não aceitam / suportam application/xhtml+xml tipo de conteúdo. Isso significava que você precisava alterar o cabeçalho de acordo com o navegador.

• A parte XML do XHTML também causou algumas situações estranhas que os desenvolvedores tiveram que resolver. Uma é a mensagem INVALID_STATE_ERR: DOM Exception 11 que aparece quando você atribui o texto contendo caracteres HTML (como é ) a um elemento na página XHTML. Quando você encontrar esse erro com sua mensagem muito útil em um aplicativo da Web grande depois de fazer uma solicitação AJAX, você realmente não tem idéia se é culpa do JQuery, AJAX ou qualquer outra coisa.

• Escrever código HTML 5 não significa misturar tags por toda parte. Se você é apaixonado por XML e XHTML, ainda é possível escrever código HTML 5 que parecerá muito próximo do XML.

• Nos primórdios dos telefones celulares, o XHTML era interessante para os dispositivos móveis que não eram muito poderosos. Analisar XML é muito mais fácil que o HTML. Agora, com dispositivos móveis dual-core, realmente não importa se eles precisam analisar XML limpo limpo ou HTML sujo cheio de hacks e tags mistas.

As especificações de outubro de 2014 mencionam a sintaxe XHTML . No momento, não está claro se existe algo como a nova linguagem XHTML (não sintaxe ), e se houver, qual será a posição de XHTML, nem a adoção do novo padrão XHTML pelos navegadores tradicionais.

XHTML5 é um sinônimo para "HTML5 serializado como XML".

There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification.

...

The second concrete syntax is the XHTML syntax, which is an application of XML. When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is treated as an XML document by Web browsers, to be parsed by an XML processor. Authors are reminded that the processing for XML and HTML differs; in particular, even minor syntax errors will prevent a document labeled as XML from being rendered fully, whereas they would be ignored in the HTML syntax. This specification defines version 5.0 of the XHTML syntax, known as "XHTML 5".

• citados no link ; note que também se diz "Esta seção não é normativa".

Além disso, há um bom documento sobre como escrever poliglotas em HTML5 (páginas, que podem ser serializadas como HTML5 e XML comuns) aqui:

link

E um validador mesmo!

link

Ele raramente é chamado de XHTML5 atualmente (e provavelmente ainda mais raramente usado), já que ele é basicamente ainda HTML5, mas ainda está lá.

Simplificando: cada alteração na especificação HTML5 também é uma alteração implícita e correspondente a XHTML5.

HTML5 é de facto e de jure padrão! O XHTML está lá, como padrão também.

HTML5 - Um vocabulário e APIs associadas para HTML e XHTML

Recomendação W3C de 28 de outubro de 2014

O título do padrão contém a string "e XHTML" , portanto, estamos falando de uma decisão final do W3C para mesclar HTML e XHTML em um único padrão ; e este padrão mostra como serializar um arquivo HTML em um arquivo XHTML e vice-versa.

XHTML partes e notas importantes:

• o tipo MIME é application/xhtml+xml
• 2.2.4. Interações com XPath e XSLT
• 9. A sintaxe XHTML

Entendendo e usando

Como resumido por LF Sikos

XHTML5 is the XML serialization of HTML5. The syntax is described by the HTML5 specification. However, one shouldn’t be confused since XHTML5 is as an application of XML. In other words, HTML5 and XHTML5 have identical vocabulary but different parsing rules.

HTML5 documents might also be valid XML documents. This markup is often referred as a “polyglot” language. It is the overlap language of documents which are HTML5 and XML documents at the same time. HTML5 and XHTML5 serializations are cross-compatible. However, XHTML5 has a stricter syntax. Furthermore, some parts of XHTML5 are not valid in HTML5, e.g., processing instructions.

Então, estritamente falando (e enfatizado por @vaxquis) "XHTML é apenas uma sintaxe para serialização XML", existem não DTD ou outro tipo de esquema XML .

Algumas pessoas não gostam de dizer "XHTML5 é XHTML". A questão deve ser dividida em um mini-FAQ sobre "quando eu posso usá-lo como XHTML". Este é um WIKI, por favor, corrija se houver algum "mal-entendido" ...

FAQ

Posso usar o XHTML5 como a "versão 2014 do padrão XHTML"?

Existem alguns problemas em uma "conversão perfeita e genérica de HTML5 para XHTML5 / XHTML5 para HTML5", você deve fazer "escolhas pessoais" e perder informações. Como o contexto será respostas diferentes:

• Loose falando : SIM. Há muitos exemplos (simples) em que o mapeamento é perfeito e reversível.

• Estritamente falando : NO. Veja também @vaxquis comentário abaixo e respostas antigas nesta página. Alguns problemas típicos:

  • link
  • ... por favor, melhore com mais exemplos ...

Posso usar serialização XHTML5 (sem medo!) com XSLT, XPath, etc.?

Sim, você pode. Até mesmo serializando fragmentos.

Posso validar o XHTML5?

Sim, mas não tão rápido e fácil quanto os antigos DTDs ... Veja validadores complexos, como validator.nu

Posso usar o XHTML5 como saída não terminal em uma cadeia XSLT?

Sim, você pode. Vamos explicar o que você pode.

Alguns frameworks, como o Cocoon , usam " Cadeias XSLT ". As saídas HTML5 e XHTML5 podem ser usadas como "última saída da cadeia" ... É claro que, em etapas intermediárias, o HTML5 não pode ser usado porque não é XML, mas o XHTML5 pode ser usado.

O problema acima validação reaparece aqui: não há uma convenção strong, então, algumas vezes, menos claridade de "estrutura padrão XHTML" aparece. Nessa situação, você deve prestar atenção em "você mesmo convenções" e ser consistente.

Ao usar o DOMDocument de uma página HTML5, posso usar um método saveXML() ?

Sim. Essa é uma situação típica em que as recomendações de serialização são usadas. O XML será válido, o código XHTML5 é mapeado a partir do estado HTML5 e DOM original ... Mas, em algumas estruturas, algumas informações podem ser perdidas, como comentado acima.

Sim, infelizmente, o XHTML desapareceu.

Adicionando mais um motivo à ótima resposta da MainMa:

Quando o XHTML foi criado, ele deveria ser usado pelo WebApps para fornecer conteúdo estruturado que seria entendido por softwares que não são de navegador, e que não teriam analisadores de HTML de tag-soup. Para ScreenReaders XHTML ainda é ótimo, mas para qualquer outro tipo de software, WebServices se encaixam nessa necessidade, e eles usam principalmente XML ou JSON. O próprio SOAP tem seu próprio XML Schema, mais simples que o XHTML e orientado a operações.

Desde que eu saiba, não há nem mesmo 1 WebApp no mundo que sirva a mesma mensagem HTTP para navegadores e outros clientes. Mesmo a arquitetura REST, que deveria servir a mesma representação de um conteúdo em vários tipos de conteúdo com base na preferência do cliente, não é usada para servir navegadores XHTML / feed.

No Java EE, por exemplo, usando o Eclipse, podemos implantar um arquivo war exclusivo contendo Servlets + JSPs para servir HTML, junto com o Axis2 para servir um WebService. É simplesmente mais fácil desenvolver softwares separados destinados a navegadores e WebService do que ter um software exclusivo e complexo que sirva a todos eles.

A principal razão para o REST ser rejeitado é exatamente a complexidade (e era para ser simples!) de desenvolver um servidor que serve o mesmo conteúdo para qualquer tipo de cliente sem saber nada sobre ele. E também é difícil lidar com a necessidade da Web de evoluir rapidamente, além de manter uma definição estável que não forçaria clientes não-navegadores a serem atualizados toda vez que uma XHTML muda, diz para manter o XHTML válido quando for construído por muitos módulos diferentes.

Da mesma forma, é muito difícil desenvolver um cliente sem navegador que analise um documento XHTML, mesmo que seja válido, por causa de todos os elementos XML que servem para estruturar o layout renderizado pelo navegador, e não para reter conteúdo.

Se os adotantes do REST já reclamarem da complexidade XML do SOAP, que é muito mais simples que um XHTML destinado a um navegador, imagine como é difícil lidar com XHTML para vários tipos de cliente, servidor e cliente.

Na prática: use HTML, como se desejar, para criar Web sites para navegadores e qualquer tipo de solução WebService para clientes que não sejam navegadores.

MAS, também acho que o XHTML5 deve ser criado. O XHTML 1.1 (ok, 1.0, 1.1 está inutilizável) ficará desatualizado com o HTML5, e ainda precisamos de um validador que aceite elementos do HTML5 e valide a integridade do XML.