O XHTML5 está morto ou é apenas um sinônimo de HTML5?


87

Então, o que aconteceu com o XHTML5?

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

Essa página é um rascunho para xhtml5 e html5? Portanto, não há diferença entre esses doctypes?


1
Parece que, em 08/12/2014, o W3C ainda está trabalhando no padrão. w3.org/TR/html5 e w3.org/TR/html5/the-xhtml-syntax.html foram atualizados em 2014-10-28.
Russel Winder

6
Hoje em dia, 2015, XHTML é um padrão W3C! ... Veja discussão atualizada
Peter Krauss

2
Você aceitou a resposta errada. A resposta do vaxquis é a resposta correta.
precisa saber é o seguinte

Respostas:


77

Em 2012, no momento da redação deste documento, ficou claro que o W3C decidiu abandonar o XHTML para HTML 5. Essa decisão foi motivada por vários motivos:

  • 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 fingiam servir XHTML usavam cabeçalhos errados, em vez de Content-Type: application/xhtml+xml.

  • Mesmo quando você entende completamente o que é XHTML e quais devem ser os cabeçalhos, a coisa é realmente complicada com alguns navegadores ruins que não aceitam / suportam application/xhtml+xmltipo de conteúdo. Isso significava que era necessário 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 INVALID_STATE_ERR: DOM Exception 11mensagem exibida quando você atribui o texto que contém caracteres HTML (como é) a um elemento dentro da página XHTML. Quando você encontra esse erro com sua mensagem muito útil em um aplicativo Web grande depois de fazer uma solicitação AJAX, você realmente não tem ideia se é culpa do JQuery, AJAX ou qualquer outra coisa.

  • Escrever código HTML 5 não significa misturar tags ao redor. Se você é apaixonado por XML e XHTML, ainda pode escrever um código HTML 5 que parecerá muito próximo a XML.

  • Nos primeiros dias 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 HTML. Agora, com dispositivos móveis de núcleo duplo, não importa se eles precisam analisar XML válido válido 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 a nova linguagem XHTML (não sintaxe ) e, se houver, qual será a posição do XHTML, nem a adoção do novo padrão XHTML pelos navegadores principais.


11
Eu acho que a única coisa que sua resposta está faltando é uma referência à marcação poliglota
yannis

2
Você pode servir HTML5 como XML, no entanto, e obter o benefício de uma sintaxe mais rígida.
precisa

3
@ErikReppen, mas você perderá o benefício de referências de entidade como 
Mr Lister

4
Uma decisão terrível. Jogamos fora as ferramentas XSL que estariam disponíveis com XML.
Mihai Danila

5
Esta afirmação é falsa. O W3C não abandonou o XHTML no HTML5 A sintaxe, o vocabulário e as APIs do XHTML
Rob

32

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

Existem várias sintaxes concretas que podem ser usadas para transmitir recursos que usam essa linguagem abstrata, duas das quais são definidas nesta especificação.

...

A segunda sintaxe concreta é a sintaxe XHTML, que é uma aplicação de XML. Quando um documento é transmitido com um tipo XML MIME, como application / xhtml + xml, é tratado como um documento XML pelos navegadores da Web, para ser analisado por um processador XML. Os autores são lembrados de que o processamento para XML e HTML é diferente; em particular, mesmo pequenos erros de sintaxe impedirão que um documento rotulado como XML seja renderizado completamente, enquanto eles seriam ignorados na sintaxe HTML. Esta especificação define a versão 5.0 da sintaxe XHTML, conhecida como "XHTML 5".

Além disso, há um bom documento sobre a escrita de poliglotas HTML5 (páginas que podem ser serializadas como HTML5 e XML regulares) aqui:

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

E um validador mesmo!

http://html5.validator.nu/

Atualmente, raramente é chamado XHTML5 (e provavelmente ainda mais raramente), pois ainda é basicamente HTML5, mas ainda está lá.

Simplificando: todas as alterações nas especificações do HTML5 também são implícitas e correspondentes ao XHTML5.


10

HTML5 é um padrão de fato e de direito ! XHTML está lá, como padrão também.

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

Recomendação W3C 28 de outubro de 2014

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

XHTML partes e notas importantes:


Compreendendo e usando

Como resumido por LF Sikos

XHTML5 é a serialização XML do HTML5. A sintaxe é descrita pela especificação HTML5. No entanto, não se deve confundir, pois o XHTML5 é como um aplicativo de XML. Em outras palavras, HTML5 e XHTML5 têm vocabulário idêntico, mas regras de análise diferentes.

Os documentos HTML5 também podem ser documentos XML válidos. Essa marcação geralmente é chamada de linguagem "poliglota". É a linguagem de sobreposição de documentos que são documentos HTML5 e XML ao mesmo tempo. As serializações HTML5 e XHTML5 são compatíveis entre si. No entanto, o XHTML5 possui uma sintaxe mais rígida. Além disso, algumas partes do XHTML5 não são válidas no HTML5, por exemplo, instruções de processamento.

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

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


Perguntas frequentes

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

Existem alguns problemas nas "conversões perfeitas e genéricas de HTML5 para XHTML5 / XHTML5 para HTML5", você deve fazer "escolhas pessoais" e informações perdidas. Como o contexto terá respostas diferentes:

  • Falando mal : SIM. Existem muitos exemplos (simples) em que o mapeamento é perfeito e reversível.

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

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

Sim você pode. Mesmo serializando fragmentos.

Posso validar o XHTML5?

Sim, mas não tão rápido e fácil que os DTDs antigos ... 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.

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

O problema acima de validação reaparece aqui: não existe uma convenção forte; portanto, às vezes, menos clareza da "estrutura padrão XHTML" aparece. Nessa situação, você deve prestar atenção nas "convenções de si mesmo" e ser consistente.

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

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.


Não. XHTML é apenas uma sintaxe para serialização XML do HTML5, que é um tópico que eu já abordei na minha resposta há um ano. Não há "mesclagem", porque ela já foi "mesclada" pelos rascunhos iniciais do W3C / WHATWG HTML5 depois de arquivar o XHTML 2.0; Você está entendendo mal o contexto aqui. Além disso, XPath e XSLT estão apenas tangencialmente relacionados ao assunto; Além disso, como é um tipo MIME conhecido "parte e / ou nota XHTML"? Além disso, você basicamente não pode serializar HTML em XHTML - a solução proposta é escrever poliglotas serializando como ambos, não "re-serializando".
vaxquis

hum ... @vaxquis, ok, editei, por favor ajude. E aqui, nos comentários, vamos falar no mesmo idioma: você usa "falando estritamente" e eu usei "fala mais ampla" na introdução ... Agora podemos apontar no texto da resposta o que você deseja corrigir.
Peter Krauss

9

Sim, infelizmente, o XHTML se foi.

Adicionando mais um motivo à grande 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, que não teriam analisadores HTML de sopa de tags. Para o ScreenReaders, o XHTML ainda é ótimo, mas para qualquer outro tipo de software, os WebServices atendem a essa necessidade e usam principalmente XML ou JSON. O próprio SOAP possui seu próprio esquema XML, mais simples que o XHTML e orientado à operação.

Desde que eu saiba, não há nem 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 de guerra exclusivo contendo Servlets + JSPs para servir HTML, junto com o Axis2 para servir um WebService. É simplesmente mais fácil desenvolver softwares separados voltados para navegadores e WebService do que um software complexo e exclusivo que atende a todos.

O principal motivo 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 de evolução rápida da Web, além de manter uma definição estável que não force os clientes que não são de navegador a serem atualizados toda vez que um XHTML for alterado, diga-o para manter o XHTML válido quando ele for criado por muitos módulos diferentes.

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

Se os adotantes de REST já reclamarem da complexidade XML do SOAP, que é MUITO mais simples que um XHTML para um navegador, imagine como é difícil lidar com o XHTML para vários tipos de clientes, servidores e do lado do cliente.

Na prática: use HTML, como XML, se desejar, para criar WebSites 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 é inutilizável) ficará desatualizado com o HTML5, e ainda precisamos de um validador que aceite os elementos do HTML5 e valide a conformidade do XML.


1
Talvez eu esteja um pouco atrasado, mas como o XHTML 1.1 não pode ser usado em comparação com o 1.0? Se alguma coisa, seu DTD contém mais elementos. A menos que você esteja falando sobre conjuntos de quadros e coisas assim?
Sr. Lister

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.