Direcionamento de versão: ameaça ou perigo?

Em janeiro, a notícia de que a Microsoft pretende incluir um mecanismo para direcionamento da versão do IE no IE8 gerou polêmica na web. (O site Pinceladas da Web reuniu links em inglês sobre o assunto). Aqui no Brasil, Diego Eis do site Tableless também deu sua opinião contra. Jeffrey Zeldman, um dos co-fundadores do Projeto Web Standards, esquentou a discussão mostrando-se a favor no artigo de sua autoria publicado na última Edição (n.253) do site A List Apart. Leia abaixo a tradução feita por mim.

Eu gostaria de viver em um mundo onde as pessoas não estivessem se matando por diferenças religiosas ou étnicas, e onde o direcionamento de versão não fosse necessário. Fazer design com padrões web deveria ser suficiente, e qualquer pessoa que trabalhe com web sites deveria saber como fazê-lo. Os navegadores deveriam estar quase que perfeitamente em conformidade com os padrões a esta altura, e se não estivessem, os seus fabricantes deveriam mudar para o ramo da música folk.

Mas os fabricantes, incluindo a Microsoft, possuem uma forma estranha de permanecer no mercado quando seus produtos gozam de uma fatia saudável do mercado (saudável para eles, se não necessariamente para o mercado). E mesmo companhias enormes – por exemplo, companhias como a Microsoft – ocasionalmente ouvem seus consumidores e tentam resolver os problemas relacionados aos seus produtos.

Para entender o direcionamento de versão – o que nós devemos tentar fazer, já que a Microsoft pretende implementá-lo e espera que pelo menos alguns de nós o aceitemos – vamos examinar dois grupos diferentes de consumidores a quem o navegador da Microsoft deve satisfazer.

Os rápidos e os mortos

Um grupo de consumidores – vamos chamá-los de designers e desenvolvedores instruídos – se esforça para criar sites semânticos, acessíveis e baseados nos padrões. Eles também, nós esperamos, objetivam ótimo design, conteúdo convincente e significante, interfaces usáveis e arquitetura do site semitransparente.

Para este grupo (acene se você fizer parte dele), o maior problema com o IE tem sido que a sua conformidade com os padrões web nunca alcançou aquela do Firefox, Safari e Opera. Particularmente, durante os longos e estranhos anos, enquanto um IE6 imutável mofava nos cantos, desenvolvedores instruídos reclamavam justamente que, toda vez que eles montavam um site seguindo os padrões, eles tinham que entrar e criar formas de contornar as deficiências do IE. Outros navegadores também possuíam falhas que necessitavam soluções alternativas, mas nada como a ladainha do IE.

Para satisfazer este grupo de consumidores, a Microsoft teve que atualizar significativamente a conformidade com os padrões de seu navegador – e então continuar atualizando-o, com freqüentes acréscimos. Com o IE7, a Microsoft começou a fazer isto. Com o IE8, ela irá mais fundo, particularmente no que concerne os scripts.

Mas a Microsoft possui outro grupo de consumidores, de forma alguma pequeno. Nós podemos chamá-los de não-iluminados. Alguns são desenvolvedores profissionais que deveriam ter ouvido sobre padrões web e acessibilidade a esta altura, mas que nem ouviram ou não se importam. Isto deve ser porque eles trabalham em companhias que restringem o seu acesso a livros, conferências e mesmo a sites não relacionados ao trabalho – companhias obscuras com regras desatualizadas e míopes sobre quais navegadores e plataformas devem e não devem ser suportados. Vamos ser caridosos: alguns destes desenvolvedores trabalham exclusivamente em intranets dependentes de uma plataforma. Outros sabem sobre os padrões web, mas trabalham em companhias que os forçam a criar layouts baseados em tabelas, a codificar para o CSS box model incorreto do IE5, e assim vai.

A Microsoft não pode abandonar estes construtores da web, nem pode se manter sem culpa por sua plataforma, no lugar de uma abordagem baseada nos padrões. Afinal, durante os velhos tempos ruins, companhias como a Microsoft e a Netscape ajudaram a criar desenvolvedores web mal informados, encorajando o pessoal de TI a desenvolver para suas plataformas proprietárias para web. Pode até mesmo haver divisões da Microsoft que ainda vendem este óleo de serpente, apesar da adoção generalizada dos padrões web pela companhia.

E os profissionais que não sabem que não deveriam fazer isto, não são mais do que um visco no balde dos criadores de web não-iluminados. Existem milhões de pequenos empresários, professores de escolas, pastores, técnicos, etc. que criam web sites todos os dias, armados com softwares vagabundos e nada mais. Tais sites são raramente modelos de ótimo design, boa escrita ou usabilidade passável, e eles quase nunca são escritos em XHTML válido ou escritos para especificações do nível daquelas do CSS da Bert and Håkon.

Este grupo de consumidores não-iluminados não realiza testes nunca, ou testa somente na versão do IE que veio com seus computadores. Você e eu podemos não nos importar com estes milhões de autores de web rudimentares, embora nós adorássemos convertê-los ao design baseado nos padrões, mas a Microsoft, sendo uma corporação e tudo o mais, não pode dispensá-los. Para satisfazer aos não-iluminados, a Microsoft deve assegurar que, à medida que o IE se torne mais conforme, ele não “quebre” os sites mal escritos que eles criam. (Quebrar está entre aspas porque alguns podem argumentar que um site, que é carregado incorretamente, mas ainda funciona, não está necessariamente quebrado).

Satisfazer a ambos os grupos não é nenhuma novidade. Os navegadores descobriram como fazê-lo em 2000 – notadamente, implementando-se a declaração do DOCTYPE, inventado por Todd Fahrner do Projeto Web Standards. Mas o velho truque não funciona mais, pelo menos não para o IE.

Montando dois cavalos com um atrás

Quando a conformidade do IE virou a página adiante com o IE7, ao menos temporariamente satisfazendo o primeiro grupo de consumidores da Microsoft, os sites mal escritos criados pelo segundo grupo de consumidores pararam de funcionar corretamente, deixando os desenvolvedores não-iluminados profundamente irritados.

Do lado de fora, para os leitores do ALA e outros standardistas, a atualização do IE7 cheirava a vitória, seguida com triunfos futuros garantidos. Mas dentro da Microsoft, aparentemente, o dano para milhões de web sites mal escritos não foi considerada uma casualidade aceitável do progresso. Se o time do IE da Microsoft tivesse que permanecer empregado e continuar a aperfeiçoar a conformidade com os padrões do navegador, uma nova forma deveria ser encontrada para proteger o trabalho de desenvolvedores não-iluminados.

“Nós não podemos quebrar a web” se tornou o mantra. (Eu sei disso porque, em um jantar de uma conferência recente, eu estava sentado próximo a algumas pessoas da Microsoft que ficavam falando isso).

Absurdo, mas correto: a aceitação por padrão

A declaração do DOCTYPE permitiu que os fabricantes de navegadores suportassem adequadamente os designs baseados nos padrões, e ao mesmo tempo não quebrassem sites escritos sem aptidão. Mas como Aaron Gustafson do Projeto Web Standards explicou na Edição n. 251, a presença de um DOCTYPE completo no cabeçalho de um documento (X)HTML não indica mais de forma confiável que o desenvolvedor sabia o que ele estava fazendo e que a página deveria ser carregada no modo dos padrões.

O Firefox, o Opera e o Safari não têm problemas com isso – não porque eles sejam moralmente superiores que o seu competidor com base em Redmond, mas porque há quase nenhum desenvolvedor não-iluminado por aí compondo seus sites para as peculiaridades do Firefox, Opera e Safari. Da mesma forma, ninguém codifica para as linguagens de script fora dos padrões que o Firefox, Opera e Safari suportam – porque o Firefox, Opera e Safari suportam JavaScript/ECMAScript e ponto.

Em contraste, zilhões de pessoas que não sabem que não deveriam de forma alguma, adaptam sites para o quirks do IE6. É por isso que o IE7 “quebrou” sites antigos. E é por isso que, ao compor um novo comutador, a Microsoft deve construir o seu padrão para proteger desenvolvedores não-iluminados. Assim foi como eles chegaram ao aparente absurdo de que o IE42 agirá como o IE7 a não ser que um desenvolvedor instruído neutralize deliberadamente este comportamento padrão, inserindo um elemento meta opcional no cabeçalho do documento (ou usando um HTTP header e deixando a sua programação pura).

Tem que funcionar assim, ou não funciona de forma alguma – por mais absurdo que isto possa soar e por mais maluco que isto deixe Jeremy Keith e muitos outros web designers inteligentes. (E por mais maluco que isto tenha me deixado pelas primeiras sete horas depois que eu ouvi sobre isto).

Se o IE8 agir como IE8 por padrão, então o IE8 pode quebrar os web sites do grupo dois (e não apenas quebrar entre aspas: estamos falando de scripts aqui). A quebra de milhões de sites não é aceitável para os chefões da Microsoft e para os criadores daqueles web sites. É para evitar este quebra-quebra que os desenvolvedores do navegador da Microsoft vieram com este novo comutador. Para realizar seu papel, o novo comutador deve funcionar da mesma forma que a declaração do DOCTYPE funcionava originalmente: ou seja, ele é ativado quando o desenvolvedor instruído o aceita, de outra forma ele é desativado por padrão.

Com a declaração do DOCTYPE, “desativado por padrão” significa “no modo (fora dos padrões) quirks.” Com o direcionamento de versão isto significa “da mesma forma que o IE7 exibia este conteúdo”. O comportamento é o mesmo em ambos os casos: se você quiser exibição aperfeiçoada, você aceita.

Esta declaração é realmente necessária?

Você pode questionar esta idéia, o que poderia ter facilitado a transição para o IE7, será necessário nas futuras versões do IE, já que a parte mais difícil da transição para uma maior conformidade com os padrões já aconteceu. E isto é verdade no que concerne o CSS . Para a maior parte, qualquer site que é exibido aceitavelmente no IE7 não deve “quebrar” no IE8.

É claro que, nunca se pode ter certeza com hipóteses; mesmo se o script não fosse um problema, é possível que qualquer versão do IE quebrasse algo, e aquele direcionamento de versão é uma idéia eternamente boa, em virtude de que ele oferece um mecanismo para evitar quebras por qualquer razão. No entanto é verdade que, para muitos web designers baseados em CSS, o caso para criar um novo comutador agora parece ser menos urgente do que teria sido logo antes da introdução do IE7.

Ainda assim, mesmo se o direcionamento de versão fosse meramente o tributo que os desenvolvedores da Microsoft tivessem que pagar aos seus senhores corporativos para obter permissão para continuar aperfeiçoando a conformidade com os padrões do IE, qual seria o prejuízo? O elemento meta é válido e o seu uso é opcional. O HTTP header é fácil e deixa o seu código puro.

O JavaScript aperfeiçoado necessita que você aceite

Mas o direcionamento de versão não está sendo introduzido para proteger designers sem qualificação ou semi-qualificados dos avanços adicionais de CSS que serão oferecidos no IE8. Pois o IE8 promete retificar o seu suporte ao DOM (realmente o corrigindo) e eliminar JScript conflitante. Para programadores de JavaScript baseado nos padrões, não intrusivo, isto é ótimo. Mas muitos programadores e milhões de sites fora dos padrões, feitos só para IE não estão prontos para isso. Estes programadores e sites precisam da proteção de um comutador.

Perguntas? Você na primeira fila:

“Mais uma vez, nós estamos sendo solicitados a fazer adaptações especiais para a Microsoft. Porque esta companhia chata não torna a sua conformidade com os padrões tão precisa quanto a do Firefox? Por que eles jogam o ônus sobre os desenvolvedores”?

Nos Adaptamos à Microsoft assim como nossos ancestrais se adaptavam ao Império Romano. Como um homem mais sábio do que eu disse, “A César o que é de César”.

E na verdade, o Mozilla ofereceu direcionamento de versão opcional, primeiro quando o Firefox 1.5 introduziu suporte para JavaScript 1.6, e depois, quando o Firefox 2.0 fez o mesmo para o Javascript 1.7. Em ambos os casos, você tinha que explicitamente aceitar. A comparação é a favor do Mozilla, pois eles direcionavam para versões de linguagem de script, não para versões de navegador. Mas embora o Mozilla tenha feito isto de forma mais limpa, ambos os fabricantes de navegadores ofereceram direcionamento, e pela mesma razão: para proteger os desenvolvedores de comportamentos não intencionados à medida que o suporte para script de seus navegadores melhorava.

Não-standardistas têm escrito Jscript há anos. Enquanto que as mudanças de CSS no IE7 possam ter quebrado o layout de um site, as melhorias do JavaScript do IE8 podem facilmente tornar um site inútil. O suporte real ao DOM é o que muda o jogo. Habilitado por padrão, ele colocaria muitos sites no chão. Isto quebraria a web, e não entre aspas. Proporcionar uma maior conformidade do IE8 na base da aceitação é a única forma de deixar que todos ultrapassem o obstáculo do script.

Mas enquanto a aceitação protege os programadores antiquados de uma mudança maior no ambiente de script, também oferece benefícios únicos mesmo para o standardista mais duro-na-queda.

O ônus não está mais sobre o desenvolvedor

O que é realmente novo é que ao não optar pelo direcionamento de versão da Microsoft (não incluindo o HTTP header opcional ou o elemento meta), você terá que pular o teste nas versões futuras do IE. Se o seu site funcionar no IE7 hoje, ele funcionará no IE47, conforme a promessa da Microsoft. Ele funcionará no IE47 mesmo se o IE47 for um desastre sangrento do ponto de vista dos padrões. Enquanto o IE47 suportar adequadamente a configuração padrão do direcionamento de versão, o seu site funcionará tão bem no IE47 quanto no IE7.

Esta é a exata definição de “compatibilidade para frente”, embora esta não seja a rota que eu esperava que nós fôssemos tomar quando eu cunhei a frase “compatibilidade para frente” quando formulava os benefícios do design baseado nos padrões.

Vire o outro lado da moeda e eis o que você vê:

O sistema é opcional. A escolha é nossa se incluímos ou não o elemento meta opcional (ou o HTTP header) que dispara o direcionamento de versão. Portanto, de fato, os desenvolvedores não vão mais ser solicitados a se adaptar à Microsoft – pelo menos não além das conhecidas manchas do IE7. Ao invés, a Microsoft se comprometeu a se adaptar a nós.

Esta é uma grande chance e um benefício para qualquer um que tenha lutado para fazer seu trabalho baseado nos padrões funcionar ou se comportar direito no IE. O IE de hoje é anos-luz mais conforme com os padrões do que as versões antigas com as quais lutamos. A Microsoft prometeu aperfeiçoar a conformidade para sempre. Se nós aceitarmos, nós podemos esperar o mesmo nível de suporte para script no IE que nós temos dos navegadores que nós amamos. Suporte aperfeiçoado e previsível aos padrões em todos os navegadores. Não é tudo o que nós queríamos?

Ao mesmo tempo a Microsoft está proporcionando um mecanismo pelo qual nenhum designer ou desenvolvedor será novamente surpreendido por uma nova versão do IE que se comporta inesperadamente. Se eu não optar permanentemente pelo direcionamento de versão, eu nunca terei que aprender outra peculiaridade do IE ou alternativa. Isto não é provavelmente o que eu ou minha agência faríamos, mas é uma opção viável. (E se bastante de nós fizesse isto, o Internet Explorer gradualmente perderia porção do mercado , o que faria algumas pessoas felizes).

Se eu aceitar no meu servidor de teste, eu posso testar sites velhos em novas versões do IE adicionando um elemento meta. Se o site velho não funcionar, eu removo o elemento – e para o meu cliente, o site velho funciona bem em um novo navegador.

Designers e desenvolvedores deveriam estar abrindo champanhes, se abraçando uns aos outros e chorando de alegria. O IE não enche mais. Script não intrusivo, para todos os navegadores, sem nenhum trabalho extra para o IE (salvo o trabalho de incluir um elemento meta ou um HTTP header), logo será uma realidade. Nenhuma versão do IE nos surpreenderá novamente com exibições ou comportamentos inesperados.

A pílula azul

O direcionamento de versão é um alucinógeno. Ele abala a fé agnóstica de nossos navegadores. O seu comportamento padrão, embora benéfico para desenvolvedores capacitados e não-capacitados da mesma forma, vai contra as nossas expectativas e parece errado. E apresenta pelo menos uma charada de Esfinge: ou seja, como o IE8 pode passar o Acid 2 se o IE8 se comporta como o IE7 por padrão? Você pode levar semanas nela e não chegar a nenhuma resposta lógica. Me chame de Lewis Carroll, mas eu não ligo.

Traduzido com a permissão da Revista A List Apart e do(s) autor(es).