Encerramos a coluna anterior comentando que não basta criar e transferir páginas da Web entre os servidores. Além disto, é necessário um programa para exibi-las, o chamado “navegador”. E que embora algumas versões deste programa já existissem para os sistemas operacionais usados pelos centros acadêmicos conectados via Internet, não havia uma que rodasse nas máquinas dos usuários comuns.
Então dois programadores do Centro Nacional de Aplicativos para Supercomputadores (NCSA) da Universidade de Illinois, Eric Bina e Marc Andreessen, que já haviam criado um programa navegador para uma distribuição de Unix, decidiram adaptá-lo para Windows. E em setembro de 1993 lançaram uma versão de seu Mosaic que rodava em Windows e tornou-se o primeiro navegador ao alcance do grande público. O fato foi tão importante para a disseminação da Internet que a Universidade de Illinois mandou fundir a placa comemorativa exibida na figura.
 |
Figura 1: Placa comemorativa da criação do Mosaic |
Nesta altura dos acontecimentos, mesmo ainda restrita aos meios acadêmicos e usando programas navegadores que rodavam apenas em Unix e suas diversas distribuições e muito antes da criação do W3C destinado a normalizá-la, a HTML já tinha sido objeto de duas revisões que resultaram nas HTML 2.0 e HTML 3.2 (não me perguntem por que, mas jamais houve a HTML 3.0).
Mas lidar com tudo isto era ainda muito simples. Particularmente porque, seja qual fosse a alteração, era relativamente fácil implementá-la. Afinal, na prática, havia apenas um programa navegador.
Foi então que Marc Andreessen resolveu faturar “algum” e em 1994 deixou o NCSA para fundar sua própria empresa, originalmente denominada Mosaic Communications, mais tarde Netscape para evitar disputas com o NCSA sobre o direito de usar o nome “Mosaic”. E lançou uma versão comercial de seu navegador.
Bem, as coisas estavam se complicando. E se complicaram ainda mais no ano seguinte quando a Microsoft lançou a primeira versão do Internet Explorer, então integrada ao sistema operacional Windows 95. E mais ainda em 1996, com o lançamento do Opera.
Depois o Netscape acabou virando Mozilla que virou Firefox, a Apple lançou seu Safari e recentemente a Google lançou seu Chrome. Uma consulta às < http://www.w3schools.com/browsers/browsers_stats.asp > estatísticas do W3Schools mostra que hoje estes cinco programas navegadores (Firefox, IE, Chrome, Safari e Opera, nesta ordem) são responsáveis por 99,7% dos acessos ao sítio da instituição.
Uma diversidade que, em princípio, não constituiria problema. Afinal, há dezenas de editores de texto, outros tantos programas de edição de imagens e coisa e tal, e ninguém se incomoda com isto: cada usuário escolhe o seu e temos conversado.
Mas acontece que cada um destes aplicativos adota seu próprio formato de arquivo (e converte os formatos adotados pelos demais, quando necessário). Já um programa navegador não pode fazer isto. Tem que receber um arquivo no formato HTML e mostrá-lo na tela (ou seja, compor sua imagem, ou “renderizar” a tela) exatamente como desejado por seu desenvolvedor. E, se não houver um mínimo de entendimento e padronização, cada programa exibirá a página de seu jeito. O que, do ponto de vista do programador que criou a página (e do usuário), seria um desastre completo.
Pois é justamente esta uma das mais importantes funções do W3C: fazer com que diferentes programas navegadores exibam páginas com o mesmo (ou, na prática, com quase o mesmo) aspecto.
A declaração da guerra
Por mais esforço que o W3C fizesse, a coisa estava virando bagunça. Particularmente levando em conta que até 2003 a Microsoft detinha quase 90% do mercado dos navegadores com as diversas versões de seu IE e não dava grande importância para normalizações, implementando as funções de renderização do jeito que melhor lhe aprazia. Foi a triste época dos sítios que exibiam o aviso: “Página melhor exibida no Internet Explorer” (hoje, quem se atreve a isso? A concorrência tem, de fato, suas vantagens...).
Esta época era um pesadelo para os programadores Web, que tinham que desenvolver suas páginas e, depois, testá-las em cada um dos programas navegadores disponíveis. E, quando descobriam que este ou aquele navegador (quase sempre o IE) exibia inadequadamente um ou outro detalhe, tinham que desenvolver os famosos “remendos” (“patches”) para resolver o problema (a bem da verdade, mesmo com toda a padronização e por mais eficaz que seja a atuação do W3C, as coisas hoje não são muito diferentes; é fato que cada vez menos intervenções são necessárias, mas de quando em quando ainda é preciso remendar aqui e ali).
 |
Figura 2: O novo padrão |
Entrementes, a HTML evoluiu. Em dezembro de 1997 o W3C publicou a versão 4.0, cujo maior avanço em relação às anteriores foi separar o conteúdo da forma. Quer dizer: as informações contidas em cada página, ou seu conteúdo, continuaram a ser trabalhadas na linguagem HTML, mas tudo o que tinha a ver com a forma (como tipo de fonte, disposição na página, cores e coisas que tais) passou a ser incluído nas chamadas “folhas de estilo em cascata”, ou CSS (“Cascading Style Sheets”). Se você quiser ter uma ideia do que isto significa e como é possível separar completamente conteúdo de forma, visite o sítio <http://www.disquepiropo.com.br/ > “Disque Piropo”, desenvolvido por este seu criado que usou a desculpa de publicar uns comentários bestas que fazia em um programa de rádio que já não existe mais para mostrar como se pode formatar um sítio inteiro usando as CSS. Quer ver? Pois visite o < http://www.disquepiropo.com.br/ > “Disque Piropo”, clique em “CSS” no canto superior direito, leia o conteúdo da página (que por isto mesmo se chama “Leia antes de clicar”), clique no atalho “COM CSS / SEM CSS”, navegue pelo sítio em ambas as situações e veja como, no que toca ao conteúdo, não há uma vírgula a mais ou a menos – mas em compensação, repare como a forma faz diferença (até os menus de cortina foram criados usando pura padronização CSS). Se você tem algum interesse pelo tema, garanto que vai gostar.
Enquanto isto, no mundo do desenvolvimento de páginas Web, tudo corria na santa paz.
Pois não é que quando tudo parecia nos conformes, em junho de 2004 o W3C realizou o “Workshop on Web Applications and Compound Documents” no qual, em votação aberta, a maioria de seus participantes decidiu abandonar a HTML assim sem mais nem menos?
Explicar o porquê desta decisão em detalhes não cabe aqui. E, na verdade, nem sei se é explicável. O que eu posso fazer é tentar resumir e, ainda assim, dentro de minha própria perspectiva.
Pois acontece que, no que toca a linguagem de programação, a HTML pode ser considerada uma linguagem muito “frouxa”. Quer dizer: ela tem padrões, sim, e a eles efetivamente adere. Mas é incrivelmente tolerante a erros. Aceita palavras chave em maiúsculas ou minúsculas, determina que certas estruturas devem ser “fechadas” mas aceita páginas onde elas aparecem “abertas”, em suma: do ponto de vista de um programador a HTML é uma zorra.
Funciona, mas é uma bagunça.
Alguns membros do W3C acharam isto intolerável. E propuseram que não somente os padrões fossem mudados, mas que fosse mudada a própria linguagem de programação. E que as páginas da Web não fossem mais programadas usando a linguagem HTML, mas sim uma variante do padrão XML (eXtensible Markup Language) criada especialmente para a Web e que foi batizada de XHTML.
Em 2004, com base nesta decisão, o W3C criou o XHTML Working Group, um grupo de trabalho que imediatamente reformulou o que seria a versão 4.01 da HTML e a transformou na XHTML 1.0. Como as diferenças entre ela e a velha HTML eram significativas, criou também a versão “XHTML Transitional” para acomodar o período de transição. E imediatamente pôs mãos à obra no desenvolvimento da XHTML 2.0.
E a HTML? Bem, no que dizia respeito ao W3C, tinha morrido.
Foi a declaração da guerra dos padrões...
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.
 |
Figura 3: HTML5 e CSS3 |
E o tempo provou que tinham razão. O novo padrão não vingou. Os desenvolvedores dos programas navegadores não mostraram grande entusiasmo em aderir (e sem sua adesão, não há padrão que vá para frente), a comunidade de desenvolvedores também não ficou propriamente deslumbrada com ele e, em outubro de 2006 o próprio Tim Berners-Lee, no artigo < http://dig.csail.mit.edu/breadcrumbs/node/166 > “Reinventing HTML”, reconhecia: “A experiência dos últimos anos tornou algumas coisas muito claras. É necessário evoluir a HTML incrementalmente. A tentativa de fazer o mundo mudar para XML incluindo aspas em torno de valores de atributos, barras inclinadas em rótulos vazios e ‘namespaces’, tudo ao mesmo tempo, não funcionou” (Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work).
Então Berners-Lee, no legítimo exercício de sua posição de “manda-chuva” do W3C (procurei sua posição oficial, mas a < http://www.w3.org/Consortium/ > página do W3C diz apenas que a instituição é “liderada” por ele – exatamente nestes termos: “led by Web inventor Tim Berners-Lee”), convidou os componentes do WHATWG para participar do W3C, instituindo assim o W3CHTML Working Group. Com o objetivo de retomar o desenvolvimento da HTML.
A primeira providência do W2CHTML WG foi rebatizar as “Web Applications 1.0” para HTML5. Assim mesmo, sem espaço separando o “HTML” do “5”.
 |
Figura 4: HTML5 afinal... |
Já no que toca à XHTML, parece que se foi em boa hora: em outubro de 2009 o XHTML Working Group foi extinto pelo W3C (veja a justificativa < http://www.w3.org/2009/06/xhtml-faq.html > aqui) e, pelo menos por enquanto, não se fala mais nela.
Ou seja: a guerra dos padrões (ou, pelo menos, a grande batalha dos padrões) acabara de se encerrar. E com um lídimo vencedor.
Hoje, embora a versão HTML5 ainda não tenha sido oficialmente liberada, sabe-se muito sobre os novos recursos que ela implementará. Já há diversos livros publicados sobre ela, alguns bastante didáticos sugerindo exemplos de implementações de páginas que utilizam os novos recursos e quase todos contendo meios e modos para que estas páginas não apareçam “quebradas” mesmo nos programas navegadores que ainda não implementaram suporte para seus recursos.
E a HTML não está evoluindo sozinha. As CSS jamais pararam de evoluir (mesmo porque não haveria razão para que parassem, já que a XHTML também se apoiava fortemente em seu uso). Durante todos estes anos o grupo que trata de seu desenvolvimento, alheio à guerra dos padrões que afinal não os afetava, continuou trabalhando com empenho no desenvolvimento da nova versão, a CSS3. E, como os padrões são abertos e as discussões são públicas, as versões mais recentes dos programas navegadores também já suportam grande parte de seus novos recursos.
Quer dizer: embora não liberadas oficialmente, a HTML3 e as CSS3 já estão com a bola toda.
E quais são os programas navegadores que as suportam e em que medida este suporte é feito?
Bem, até recentemente a grande exceção era o IE. Pois todos os demais programas navegadores de alguma importância (ou seja: Firefox, Chrome, Safari e Opera), assim como todos aqueles desenvolvidos ou adaptados para os dispositivos móveis como tabletes (“tablets”) e telefones espertos (“smartphones”), praticamente sem exceção, já oferecem suporte se não a todas, certamente à maioria dos novos recursos tanto da HTML5 quanto das CSS3.
E agora, com o suporte oferecido pelo IE9, o quadro se completa.
Quer dizer: quem quiser programar páginas web usando HTML5 e CSS3, sinta-se à vontade.
E bom proveito.
E se houver interesse em saber quais foram os recursos acrescentados às novas versões e como eles influenciarão a criação de páginas Web, favor manifestá-lo nos comentários.
B.
Piropo
