Por que a análise estrita não foi escolhida para HTML?

Muitas vezes me perguntei por que a análise estrita não foi escolhida ao criar HTML. Durante a 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 sem sentido e dificulta a interrupção de recursos obsoletos.

Existe um motivo específico para o HTML não ser analisado estritamente?

O motivo é simples: na época dos primeiros navegadores gráficos, o NCSA Mosiac e, mais tarde, o Netscape Navigator, quase todo o HTML era escrito à mão. Os autores do navegador (o Netscape foi criado por ex-mosaicos) reconheceram rapidamente que se recusar a renderizar HTML incorreto seria contra eles pelos usuários, e pronto!

Porque fazer o melhor palpite é a coisa certa a ser feita, da perspectiva de quem cria um navegador. Considere a situação: idealmente, o HTML que você recebe está completamente correto e conforme as especificações. Isso é ótimo. Mas a parte interessante é o que acontece quando o HTML não está correto; já que estamos lidando com informações de uma fonte na qual não temos influência, precisamos realmente estar preparados para isso. Agora, quando isso acontece, o que podemos fazer? Temos duas opções: a) falham eb) fazem o melhor esforço para se 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 não controla o servidor. Se fizermos o melhor possível, o usuário terá pelo menos o que poderíamos fazer da página e, geralmente, o palpite está correto.

O único problema real disso é quando você precisa das mensagens de erro, que geralmente estão em uma situação de desenvolvimento - você deseja garantir que o HTML gerado esteja correto e, como "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 corrigiu para você. Este é um problema solucionável; existem plugins para navegadores que relatam violações de padrões, há o validador W3C e muitas outras ferramentas semelhantes.

Os autores de HTML e as ferramentas de autoria produzem marcação ruim. Os navegadores fazem o melhor possível por razões competitivas: os navegadores que não conseguirem renderizar 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 culpa.

É bem diferente do que as implementações da linguagem de programação fazem. Compiladores e intérpretes trabalham em código que pode ser assumido como escrito por um programador, enquanto todos e seu irmão podem escrever HTML com o mínimo de treinamento ou sem ele. A marcação HTML é um código, em certo sentido, mas são dados, e não instruções de linguagem de programação, e a (boa) tradição em software é ser tolerante com os dados.

O XHTML, em princípio, impõe regras estritas de análise (XML), para que um documento XHTML fornecido com um tipo de conteúdo XML seja exibido apenas se for bem formado no sentido XML - caso contrário, apenas o primeiro erro será comunicado ao usuário. Isso nunca se tornou popular na criação na web - quase todo o "XHTML" é servido como texto / html e processado como uma sopa de tags tradicional de uma maneira muito liberal, apenas com algumas novas excentricidades.

O resumo seria que o HTML se baseava em outra linguagem de marcação sem hiperlink, chamada SGML, frequentemente usada para documentação, manuais e similares.

De um artigo sobre a história do HTML:

Tim mencionou que alguns dos primeiros documentos HTML eram baseados em uma antiga linguagem SGML que o CERN já estava usando: - Incluímos no HTML algumas tags do conjunto de tags SGML usadas no CERN e já suportadas no CERN. O analisador de HTML ignora as tags que não entende e ignora os atributos que não entende das tags CERN-SGML .

[...] a maioria das primeiras tags HTML foram realmente tiradas da linguagem CERN SGMLGuid, que em si era uma variante da AAP (uma linguagem SGML antiga). Por exemplo, título, hn, p, ol e assim por diante são aparentemente retirados desse idioma. A única mudança radical foi a adição do importante link anchor (), sem o qual a WWW não decolaria.

Tomando nota da parte que eu coloquei em negrito, basicamente, eles implementaram um subconjunto das tags disponíveis no sistema SGML com as quais estavam familiarizadas, adicionando a nova tag anchor <a> e optando por ignorar qualquer uma das muitas tags que não fizeram ' não se preocupe ou queira oferecer suporte por qualquer motivo (como tags para listas bibliográficas, xmp para "example", tag "box" para desenhar uma caixa em torno de um bloco de texto, etc.). Portanto, a maneira mais simples de fazer isso é perdoar a marcação que não é conhecida pelo analisador e ignorar a marcação desconhecida da melhor maneira possível, independentemente de a causa ter sido digitada pelo usuário com marcação incorreta ou a maneira mais rápida e fácil de converter documentos existentes para esse novo formato HTML é adicionar alguns hiperlinks aos documentos SGML existentes e ignorar as tags que não são suportadas ou implementadas.

Este é parcialmente um remanescente histórico da guerra dos navegadores

O IE e a netscape estavam competindo para conquistar o mercado e continuavam lançando novos recursos que se tornavam cada vez mais "impressionantes", e eram obrigados a aceitar as páginas projetadas para o outro navegador.

Isso significa que o navegador aceita e ignora as 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 dar suporte à maioria dos eles, e criar um analisador separado para cada versão seria um enorme inchaço. Portanto, é (relativamente) mais fácil usar um único analisador com modos diferentes.

Por outra parte, o netscape e o IE queriam que o html fosse acessível para o 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 todas as tags penduradas.

Para piorar o problema é que também existem vários sites "tutoriais" ensinando a coisa errada e pensando que estão certos, porque o que ensinam funciona.

Por fim, isso significa que se você criar um navegador com apenas html estrito, analisando 99% dos sites por aí simplesmente não funcionará.

Bem, tentamos estabelecer uma boa opção estrita nos anos mil, mas não deu certo porque as pessoas que seguiam as "melhores práticas" cegamente culparam os navegadores quando a marcação incorreta foi reduzida no modo estrito. E os fornecedores de navegadores não gostaram de ser responsabilizados.

Eles alegaram que era porque queriam a web mais acessível para não profissionais, mas ninguém estava impedido de usar o HTML 4 em sua forma mais branda.

Dito isto, você ainda pode servir HTML5 como XML se desejar um layout de estilo estrito. Na IMO, pode ser uma boa maneira de colher os benefícios de fazer o layout ou o trabalho da interface do usuário de maneira mais rigorosa antes de repassá-lo a outras pessoas que podem ou não querer que seja estrita sem riscos reais (exceto que rasgem o tipo de documento porque na verdade, eles preferem o modo peculiar - em 2017 (o tempo desta edição), eles devem ser filmados. Portanto, ainda está lá, basicamente, mas faça alguma pesquisa. Lembro-me de que havia algumas ressalvas que não tínhamos com o XHTML que não realmente impactam o trabalho do layout, mas não divulgue que é "a única maneira de fazer as coisas direito", ou os twits que se interessam por esse tipo de conversa irão dogpilar a idéia, culpar os navegadores novamente e eles vão morder os dentes fora da única alternativa estrita que nos resta. (2017 edit:

http://mathiasbynens.be/notes/xhtml5