Por que não XHTML5?


53

Então, HTML5 é o grande passo em frente, me disseram. O último passo adiante que demos conhecimento foi a introdução do XHTML. As vantagens eram óbvias: simplicidade, rigidez, capacidade de usar analisadores e geradores de XML padrão para trabalhar com páginas da Web e assim por diante.

Que estranho e frustrante, então, que o HTML5 revele tudo isso: mais uma vez, estamos trabalhando com uma sintaxe não padrão; mais uma vez, temos que lidar com a bagagem histórica e a complexidade da análise; mais uma vez, não podemos usar nossas bibliotecas, analisadores, geradores ou transformadores XML padrão; e todas as vantagens introduzidas pelo XML (extensibilidade, namespaces, padronização etc.) perdidas pelo W3C por uma década, por boas razões.

Tudo bem, temos o XHTML5, mas parece que ele não ganhou popularidade como a codificação HTML5. Veja esta pergunta SO , por exemplo. Até a especificação HTML5 diz que HTML5, não XHTML5, "é o formato sugerido para a maioria dos autores".

Eu tenho meus fatos errados? Caso contrário, por que eu sou o único que se sente assim? Por que as pessoas estão escolhendo HTML5 em vez de XHTML5?


6
+1 Vejo que não sou o único frustrado com a perda de todas as vantagens de XML no HTML5.
Arseni Mourzenko

Buzinando boa pergunta, bem colocado.
Konrad Rudolph

11
Espero não ser o único que está satisfeito com a perda de todas as desvantagens do XML no HTML5. Por exemplo, vamos comparar o HTML5 válido com o XHTML válido. HTML5: <!DOCTYPE html>Hello World, XHTML:<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>
zzzzBov

@zzzzBov, você definitivamente não é o único que está feliz, e foi por isso que fiz essa pergunta em primeiro lugar. Além disso: você não escreveria seriamente <!DOCTYPE html>Hello World, escreveria ? Tente isso neste validador .
Jameshfisher

11
@eegg, aparentemente você ainda não leu a especificação em tags de início opcionais , porque eu seriamente ia escrever <!DOCTYPE html>Hello World!, como é perfeitamente HTML5 válido. Documentos mais curtos significam menos sobrecarga de largura de banda, o que equivale a economias significativas para grandes empresas (você viu o que o Google envia para www.google.com?).
zzzzBov

Respostas:


25

Eu recomendaria ler Como chegamos aqui? . Mark Pilgrim fornece um excelente e breve histórico de HTML até HTML5.

Essencialmente, porém, meu entendimento é que muitas páginas da Web nem aproveitam o "X" do XHTML porque não especificam o tipo MIME adequado para ele.


18
Sim. Meu resumo dessa história seria: "Ei, ninguém está em conformidade com a especificação. Talvez possamos fazer com que eles se conformem com a especificação, especificando que as pessoas podem cometer os erros que desejarem. Então, finalmente, todos os nossos documentos estarão livres de erros e compatível com os padrões ". De nada adianta escrever uma especificação com a suposição inicial de que ninguém respeita as especificações.
Jameshfisher 23/06

11
@eegg, sua última linha mostra sua ignorância da realidade. Muitas coisas boas já vieram do pressuposto de que ninguém é perfeito . Em vez de dizer a especificação, "se você cometer algum erro, tudo está quebrado", ao invés disso, "se você cometer [esse tipo de erro], então [este resultado] é o que deve acontecer". Quantos livros estariam em nossas prateleiras se eles tivessem 100% de ortografia, pontuação e gramática corretas para serem publicados?
zzzzBov

6
@zzzzBov, sua analogia com os livros publicados é estranha. Por que um analisador de HTML deve perdoar mais do que um analisador para [qualquer outro idioma aqui], onde um erro de sintaxe é encontrado com uma mensagem de erro? Imagine o caos em que estaríamos se nossos compiladores C tentassem ao máximo reinterpretar silenciosamente a sintaxe quebrada.
Jameshfisher

@eegg, posso imaginar o que aconteceria se um analisador de qualquer outro idioma reagisse aos erros de sintaxe de uma maneira mais indulgente: gastaríamos menos tempo caçando colchetes extraviados e sem pontos e vírgulas e mais tempo digitando o código funcional. Não estou dizendo que bons programadores ainda não tornariam seus programas bem-formados, mas certamente ajudaria programadores medíocres a escrever código de trabalho. Um Cprograma provavelmente acabaria parecendo muito mais semelhante a um Pythonprograma, pois os pontos e vírgulas e colchetes poderiam desaparecer principalmente, e o que restaria seria o código importante.
zzzzBov

“O recurso solicitado /past.htmlnão está mais disponível neste servidor e não há endereço de encaminhamento.”
Marco

6

Se você produzir html5 compatível com xml e enviá-los com xml como tipo mime, o analisador xml será usado em todo o bom jazz;)

EDIT: veja isso para mais algumas informações: http://wiki.whatwg.org/wiki/HTML_vs._XHTML


Defina "bom jazz". AFAIK não há vantagem em analisar HTML como XML. Gerar e transformar são outras questões, essas podem ser convenientes, mas a análise por si só não oferece vantagens, apenas desvantagens (torna os erros cosméticos fatais).
Joeri Sebrechts

3
@Joeri O fato de ser muito mais fácil analisar é uma vantagem em meu livro, por várias razões (a análise rigorosa facilita a localização de erros, o melhor suporte a ferramentas porque as ferramentas são mais fáceis de escrever, a higienização mais fácil das entradas, etc.).
Konrad Rudolph

Você também pode fornecer algumas funcionalidades indisponíveis no html padrão, como micin xhtml com outros conteúdos xml, e geralmente usar todas as funcionalidades xml, namespaces, por exemplo. O analisador html pode corrigir códigos fonte incorretos - erros cosméticos, como você os chama -, mas essas correções têm um preço. O preço é que o navegador precisa saber o que é provável encontrar no código, limitando assim as funcionalidades disponíveis.
deadalnix

3

O HTML5 é a conclusão lógica e inevitável dos navegadores que adotam a lei de Postel ("Seja liberal no que você aceita").

Uma vez que um navegador com participação de mercado suficiente adota esse princípio, outros são forçados a seguir o exemplo, não apenas sendo liberal ao aceitar conteúdo não conforme, mas também tornando-o da mesma maneira que seus concorrentes. O HTML5 é o resultado lógico dessa situação: os fornecedores do navegador decidiram que, como não rejeitarão nenhum conteúdo como inválido (pelo menos, não no nível HTML - o Javascript é outro problema!), Eles também podem ficar sentados ao redor do tabela e concorde com uma interpretação para qualquer coisa que o autor do conteúdo possa lançar sobre eles. Nesse ambiente, eles não reagiram gentilmente com os geeks dos padrões, dizendo-lhes que, se tivessem rejeitado conteúdo mal formado desde o início, não teriam entrado nessa confusão.

Assim, você e eu podemos gritar do lado de fora e dizer aos fornecedores de navegadores e seus usuários que o mundo seria um lugar melhor se não tivessem acreditado em John Postel, mas o estrago está feito e é muito difícil desfazê-lo.


3
A história da negligência concorrente dos navegadores é verdadeira o suficiente. Mas eis a questão: é por isso que os geeks dos padrões existem. Se todos os navegadores aplicassem a linha reta e estreita desde o início, organizações como o W3C não precisariam estar aqui para manter as coisas sob controle. O ponto principal dos padrões é o controle de danos; para o organismo de padrões ceder e aceitar desleixado, derrota seu próprio objetivo.
Jameshfisher

11
@eegg: HTML5 redefine as regras de análise para tornar todas as entradas válidas e ainda ter consequências previsíveis. Se erros de sintaxe forem impossíveis, toda uma classe de erros será descartada desde o início. A capacidade do XML de apresentar erros de análise é uma falha de design e deve ser reconhecida como tal.
Joeri Sebrechts

11
@ Joeri, sua posição parece ser a das especificações do HTML5, levada à sua conclusão lógica insana. "O HTML5 redefine as regras de análise para tornar todas as entradas válidas" - isso não acontece. O conceito de analisar erros ainda existe. "Se erros de sintaxe são impossíveis, toda uma classe de erros é descartada desde o início" - talvez isso seja paródia? Essa lógica é o que parafrasquei sarcasticamente no meu comentário para a resposta da @pthesis. Sim, a classe de erros de sintaxe é removida, para ser substituída por uma classe maior de erros de correção de sintaxe do navegador .
Jameshfisher

2

A especificação HTML5 foi realmente bastante aprimorada em relação à especificação HTML4. Em particular, o tratamento de condições de erro e marcação inválida é realmente padronizado, o que significa que todos os navegadores que implementam corretamente o padrão tratam a marcação inválida da mesma maneira.

O HTML é escrito por humanos com mais frequência do que nunca (geralmente em conjunto com algum tipo de linguagem de modelos), e os humanos cometem erros. Desde que todos os navegadores lidem com erros de sintaxe da mesma maneira, a regra "seja liberal no que você aceita" é perfeitamente aceitável.

Há realmente pouca vantagem na produção de XML válido, já que ferramentas e bibliotecas para lidar com HTML estão (quase) tão prontamente disponíveis, e o HTML é mais fácil para humanos escrever do que XML.


Sobre a especificação HTML4 , sim. Mas o que quero dizer é que o XHTML1.1 melhorou nisso. Ferramentas / bibliotecas para lidar com HTML tendem a ser como BeautifulSoup - enquanto ferramentas maravilhosas, elas devem morrer junto com as páginas que foram feitas para analisar.
Jameshfisher 27/06

1

Você nunca obterá os benefícios de um analisador mais simples ou de ferramentas XML padrão no lado do cliente.

Existem bilhões de páginas na web em HTML, algumas delas escritas por pessoas mortas há muito tempo, portanto nunca serão atualizadas para XML. Então, se você quer criar um agente de usuário geralmente útil que você tem de ser capaz de analisar HTML antigo de qualquer maneira. Indiscutivelmente, o XHTML introduz apenas complexidade adicional, pois requer um novo modo de análise, além da análise de HTML que você já tem que suportar.

No lado do servidor, você ainda pode tirar proveito das ferramentas XML, por exemplo. gerando XHTML usando XSLT. Mas se você não estiver usando especificamente uma cadeia de ferramentas XML, não há benefício em usar a sintaxe XML em vez de apenas HTML.

(Você não está certo de que o HTML é uma sintaxe "não padrão". A sintaxe do HTML é especificada em detalhes meticulosos na especificação do HTML5, portanto, é tão padrão quanto a sintaxe XML.)

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.