Muitas vezes me perguntei por que a análise estrita não foi escolhida ao criar HTML. Na maior parte do histórico da Internet, os navegadores aceitaram qualquer tipo de marcação e fizeram o possível para analisá-la. O processo degrada o desempenho, permite que as pessoas escrevam ininteligíveis e dificulta a descontinuação de recursos obsoletos.
Existe uma razão específica pela qual o HTML não é analisado com precisão?
O motivo é simples: na época dos primeiros navegadores gráficos, o NCSA Mosiac e o Netscape Navigator, quase todo o HTML foi escrito à mão. Os autores do navegador (o Netscape foi construído por pessoas ex-Mosaic) reconheceram rapidamente que recusar-se a renderizar HTML incorreto seria mantido contra eles pelos usuários, e voila!
Porque fazer as melhores suposições é a coisa certa a fazer, do ponto de vista de um navegador. Considere a situação: idealmente, o HTML que você recebe é completamente correto e específico. Isso é ótimo. Mas a parte interessante é o que acontece quando o HTML está não correto; já que estamos lidando com informações de uma fonte sobre a qual não temos influência, na verdade, temos que estar preparados para isso. Agora, quando isso acontece, o que podemos fazer? Temos duas opções: a) falhar e b) fazer o melhor esforço para recuperar do erro. Se falharmos, o usuário não terá nada além de uma mensagem de erro inútil, e não há nada que possa fazer sobre isso, porque eles não controlam o servidor. Se fizermos um esforço melhor, o usuário terá pelo menos o que poderíamos fazer com a página, e muitas vezes o palpite está correto.
O único problema real com isso é quando você precisa das mensagens de erro, que geralmente estão em uma situação de desenvolvimento - você quer ter certeza de que o HTML gerado está correto e porque "funciona no navegador X "não é equivalente a" correto ", não podemos simplesmente executá-lo através de um navegador e ver se funciona: não podemos dizer a diferença entre o HTML correto e o HTML incorreto que o navegador fixou para você. Este é um problema solucionável; existem plugins de navegadores que relatam violações de padrões, há o validador do W3C e muitas outras ferramentas similares.
Os autores de HTML e as ferramentas de criação produzem marcações ruins. Os navegadores fazem o melhor que podem por razões competitivas: os navegadores que não conseguirem processar a maioria das páginas da Web de maneira razoável serão rejeitados pelos usuários, que não se importarão nem um pouco com quem é a falha.
É diferente do que implementações de linguagem de programação fazem. Compiladores e intérpretes trabalham em código que pode ser assumido como sendo escrito por um programador, enquanto todos e seu irmão podem escrever HTML com treinamento mínimo ou sem. A marcação HTML é, de certo modo, um código, mas são dados em vez de instruções em linguagem de programação, e a (boa) tradição no software é ser tolerante com os dados.
XHTML, em princípio, impõe regras de análise estrita (XML), de modo que um documento XHTML servido com um tipo de conteúdo XML será exibido apenas se for bem formado no sentido XML - caso contrário, apenas o primeiro erro será comunicado ao do utilizador. Isso nunca se tornou popular em autoria na web - quase todo o “XHTML” é servido como texto / html e processado como sopa de tag tradicional de uma forma muito liberal, apenas com algumas novas excentricidades.
O mais curto seria que o HTML fosse baseado em outra linguagem de marcação não-hyperlink chamada SGML, frequentemente usada para documentação, manuais e afins.
De um artigo sobre o histórico do HTML:
Tim had mentioned that some of the early HTML documents were based on an old SGML language that CERN was already using:- We have included in HTML some tags from the SGML tagset used at and once supported at CERN [...] The HTML parser will ignore tags which it does not understand, and will ignore attributes which it does not understand of CERN-SGML tags.
[...] most of the early HTML tags were actually taken from the CERN SGMLGuid language, which itself was a variant of AAP (an early SGML language). For example, title, hn, p, ol and so on are all apparently taken from this language. The only radical change was the addition of the all important anchor () link, without which the WWW wouldn't have taken off.
Tomando nota da parte em negrito, basicamente, eles implementaram um subconjunto das tags disponíveis no sistema SGML com o qual eles estavam familiarizados, adicionando a nova âncora < a > tag, e escolhendo ignorar qualquer uma das muitas tags que eles não se importavam ou desejavam suportar por qualquer motivo (como tags para listas de bibliografia, xmp para "exemplo", tag "box" para desenhar uma caixa em torno de um bloco de texto, etc). Portanto, a maneira mais simples de fazer isso é perdoar as marcações que não são conhecidas pelo analisador e ignorar as marcações desconhecidas da melhor maneira possível, independentemente de a causa ser uma marcação incorreta digitada pelo usuário ou a forma mais rápida e fácil de converter documentos existentes. este novo formato HTML é adicionar alguns hiperlinks aos documentos SGML existentes e ignorar quaisquer tags que não sejam suportadas ou implementadas.
Isto é parcialmente um remanescente histórico da guerra dos navegadores
O IE e o netscape competiam para conquistar o mercado e continuavam lançando novos recursos que se tornavam cada vez mais "incríveis", e foram forçados a aceitar as páginas projetadas para o outro navegador.
Isso significa que o navegador aceita e ignora tags desconhecidas silenciosamente, depois que os comitês começaram a se envolver ... bem, você tem um comitê projetando coisas e como resultado muitas versões diferentes (com algumas especificações ambíguas) em que o navegador deseja suportar a maioria delas, e criar um analisador separado para cada versão seria um enorme inchaço. Por isso, é (relativamente) mais fácil usar um único analisador com modos diferentes.
Por outro lado, o netscape eo IE queriam que o html fosse acessível ao homem comum (como era a moda naqueles dias), o que significa tentar fazer o que o usuário queria que fosse feito em vez do que ele dizia fazer e tropeçar em cada tag.
Tornar o problema ainda pior é que há também vários sites "tutoriais" ensinando coisas erradas e achando que estão certos porque o que eles ensinam funciona.
Em última análise, isso significa que, se você criar um navegador com apenas uma análise rígida de HTML, 99% dos sites não funcionarão.
Bem, tentamos estabelecer uma boa opção estrita nos anos 2000, mas não deu certo porque as pessoas que seguiam as "melhores práticas" cegamente culparam os navegadores quando a marcação incorreta foi quebrada no modo estrito. E os fornecedores de navegadores não gostaram de ser culpados.
Eles alegaram que era porque queriam que a Web fosse mais acessível a não profissionais, mas ninguém estava sendo impedido de usar o HTML 4 em sua forma mais tolerante.
Dito isso, você ainda pode exibir HTML5 como XML se desejar um layout de estilo estrito. IMO pode ser uma boa maneira de colher os benefícios de fazer o layout ou o trabalho da interface do usuário em um modo mais restrito antes de passá-lo para outras pessoas que podem ou não desejá-lo como estrito, sem nenhum risco real (barrando o rasto do doctype porque eles realmente favorecem o modo peculiar - em 2017 (o tempo desta edição) eles deveriam ser filmados Então ainda está lá basicamente, mas faça alguma pesquisa Eu pareço lembrar que existem algumas ressalvas que nós não tivemos com XHTML que não o fizeram Simplesmente não espalhe a notícia de que é "a única maneira de fazer certo" ou os "twits" que compram esse tipo de conversa, vão armar a idéia, culpar os navegadores de novo, e eles vão levar os dentes da única alternativa estrita que nos resta. (edição de 2017: Eu não tenho idéia se isso ainda funciona - desistiu)