Gerenciamento draconiano
Não cabe, aqui, entrar em detalhes sobre as diferenças entre as duas linguagens. Mas o fato é que, filosoficamente, elas representavam duas posturas totalmente divergentes.
Enquanto a HTML fazia tudo o que estivesse a seu alcance para absorver erros e desvios de programação e fazia todo o esforço possível para jamais deixar de exibir uma página, por mais mal formada que estivesse, a XHTML estrita funcionava de forma exatamente oposta.
Isto porque, de acordo com as exigências do grupo de trabalho XHTML, toda e qualquer página da Web programada na nova linguagem deveria ser “bem formada”, ou seja, obedecer estritamente às regras estabelecidas pelo padrão. E, embora estas regras fossem extremamente severas, não haveria mais leniência: de acordo com as normas da XHTML estrita, imediatamente depois de carregar a página e antes de exibi-la, o programa navegador deveria verificar sua rigorosa aderência aos padrões e, constatada qualquer “má formação”, refugar a página e exibir uma mensagem de erro. A isto se batizou de “gerenciamento draconiano de erros” (“draconian error handling“).
Para estarem em conformidade com o padrão XHTML estrito as páginas deveriam passar no teste de conformidade (e o próprio W3C oferecia uma página onde os desenvolvedores poderiam efetuar este teste mesmo antes de pôr a página no ar). Mas, se todos os programas navegadores adotassem este padrão de imediato, página nenhuma poderia ser exibida (minto: talvez algumas, mas certamente a porcentagem seria insignificante). E foi para permitir a acomodação necessária durante um período de transição que se criou o padrão “XHTML Transitional”, cujas páginas deveriam, sim, ser programadas seguindo as regras estritas do padrão, mas não seriam submetidas ao gerenciamento draconiano. Quer dizer: páginas mal formadas não seriam bem-vindas, mas seriam exibidas.
Mas não por todo o sempre. Pois o objetivo do grupo de trabalho que desenvolvia a XHTML 2.0 era fazer com que, futuramente, todas as páginas da Web obedecessem ao padrão estrito. E as que não obedecessem simplesmente não seriam exibidas.
É claro que teve gente que não gostou. E, de acordo com a velha norma que recomenda aos incomodados que se mudem, efetivamente se mudaram.
Mudaram-se e criaram um novo grupo de trabalho (“Working Group”) independente, fora do W3C, batizado de “Web Hipertext Application Technology Working Group”, ou WHATWG.
Que, por não pertencer nem ter qualquer ligação com o W3C e, por isto mesmo, não podendo criar uma nova versão da HTML (que, afinal, era um padrão e só quem tinha competência para desenvolver padrões nesta área era o W3C), continuou trabalhando no que seria uma evolução da boa, velha e tolerante linguagem, mas com um nome diferente: “Web Applications 1.0”. E puseram mãos à obra.
Tudo isto porque eles desconfiavam, e com boa dose de razão, que aquela história de “gerenciamento draconiano de erros” era muito boa para uma reunião de velhos acadêmicos acostumados aos rigores de suas disciplinas, mas na prática dificilmente iria vingar. Afinal o mundo da Web é quase caótico por sua própria natureza e ainda está para nascer quem consiga botar uma ordem em semelhante bagunça.
A Dell Technologies divulgou resultados trimestrais acima das expectativas de Wall Street. O desempenho foi…
A Sabesprev reduziu para 23 minutos o tempo médio de resolução de atendimentos após reformular…
Embora 30% dos CIOs apontem o desenvolvimento de talentos como um dos principais desafios de…
Por Tiago Morelli Durante mais de uma década, os chamados assistentes digitais foram apresentados como…
O avanço acelerado da infraestrutura necessária para sustentar a inteligência artificial começou a gerar tensões…
A Seal Networks anunciou um reposicionamento estratégico e passa a atuar como integradora de infraestrutura…