IE8 - Version Targeting
Esse post é sobre um assunto que tem gerado bastante controvérsia na web durante as últimas semanas: a decisão da Microsoft em fazer com que o IE8 se comporte exatamente igual ao IE7.
Vou tentar resumir: em função da estratégia da Microsoft de aumentar o suporte aos web standards na migração do IE6 para o IE7, inúmeros sites que foram desenvolvidos em cima dos bugs do IE6 ficaram quebrados quando foram visualizados no IE7 (como ocorreu com os nossos CMAs). Para evitar que isso aconteça novamente na migração do IE7 para o IE8, a Microsoft incluiu um recurso para que os autores de páginas web declarem explicitamente qual a rendering engine que eles desejam usar. Para isso é necessário usar uma simples declaração na tag META, como por exemplo:
<meta http-equiv=”X-UA-Compatible” content=”IE=8″ />
É possível estender as informações sobre compatibilidade para outros browsers, definindo a sua prioridade:
<meta http-equiv=”X-UA-Compatible”
content=”IE=8;FF=3;OtherUA=4″ />
Ou seja, por padrão, o IE8 vai usar a engine do IE7 (caso o autor do documento não indique explicitamente que deseja usar uma engine de outra versão do IE ou mesmo de outros browsers). Como a tag META é do tipo HTTP-equivalent, o cabeçalho HTTP também pode ser configurado para se obter o mesmo resultado:
X-UA-Compatible: IE=8;FF=3;OtherUA=4
Para funcionar, é necessário que a tag META seja posicionada no HEAD do documento, o mais perto possível do topo. Ela pode ser precedida por outras tags meta e pelo elemento TITLE, mas deve ser colocada antes de todos os outros elementos — e não pode ser adicionada ao DOM via JavaScript.
Para a felicidade dos defensores do uso de web standards, a Microsoft prometeu que o IE8 vai passar no Acid Test, que é um teste desenvolvido pelo Web Standards Project para que os fabricantes de browsers possam testar o grau de compatibilidade dos seus produtos com os padrões da web. Portanto, se você deseja escrever um código que respeita os web standards, como fazem em grande parte o Firefox, o Safari e o Opera, você pode escolher usar a engine do IE8. Você pode escolher usar sempre a última versão do IE, basta usar a palavra-chave “edge” (isso evita que o autor do documento tenha que usar um valor como, por exemplo, “IE=1000″):
<meta http-equiv=”X-UA-Compatible” content=”IE=edge” />
É necessário dizer que a Microsoft desencoraja veementemente o uso dessa alternativa, porque ela não pode predizer os bugs de layout e scripting que podem ser introduzidos em uma nova versão do IE!! As atualizações na engine do IE8 não se limitam a questões de CSS e layout, mas são também relativas ao uso de scripts, o que pode tornar milhões de sites inúteis.
Na ausência de qualquer informação sobre “version-targeting”, o DOCTYPE será usado como proxy para decidir qual engine usar, da mesma forma que os browsers atuais usam DOCTYPE switching para decidir se entram em “Standard” ou “Quirks mode”. Agora, todos os DOCTYPEs do HTML4 e do XHTML1 ativarão o modo do IE7 por padrão. No futuro, dependendo do andamento dos fatos, os DOCTYPEs do HTML5 devem ativar os modos de renderização do IE9 ou IE10.
Apesar do benefício óbvio em oferecer uma garantia para que os desenvolvedores nunca mais sejam surpreendidos com o comportamento inesperado das novas versões de browser, essa iniciativa (chamada pela Microsoft de “don´t break the web”) tem sido alvo de críticas por parte de profissionais renomados. Eis alguns pontos negativos levantados por eles:
- essa abordagem fere os princípios do progressive enhancement, segundo o qual, os sites devem ser desenvolvidos para ser forward-compatible. Isto é, os sites devem ser desenvolvidos em uma única versão e de um jeito que, independentemente do comportamento que as novas versões de browser possam ter, as páginas são construídas para possibilitar que cada usuário tenha uma experiência tão rica quanto permitir o seu ambiente de trabalho. Isso é exatamente o contrário do que a Microsoft propõe com o “version targeting”. Por exemplo: um site foi desenvolvido para funcionar no IE8. Quando o IE9 for lançado com novos recursos, o site não vai poder tirar proveito deles, porque as páginas estarão bloqueadas para funcionar no IE8
- se os os autores continuarem a escrever seu código em cima dos bugs do IE7, um número ainda maior de documentos na web estará incompatível com os padrões seguidos por outros browsers. E na versão, digamos, 49 do IE, o comportamento padrão do browser ainda terá que ser o mesmo do IE7. Em seu artigo entitulado “They Shoot Browsers, Don’t They?” no “A List Apart”, Jeremy Keith diz que
o “version targeting” resolve o problema de quebrar a web da mesma forma que a decapitação resolve a dor de cabeça
- o “version targeting” é ruim para a indústria porque caminha na contra-mão da implementação de padrões abertos de interoperabilidade entre browsers e porque prejudica a concorrência, uma vez que, os fabricantes de novos browsers têm que oferecer suporte aos novos padrões que surgem e também ao enorme número de páginas já construídas em cima dos bugs do IE. Isso eleva os custos de lançamento de novos produtos, o que não é bom para o mercado nem para os consumidores, mas é bom para a Microsoft.
- o “version targeting” é ruim para os desenvolvedores porque eles não serão forçados a acompanhar a evolução da indústria e, portanto, não terão que melhorar suas qualidades na construção de sites. Paradoxalmente, eles terão que gastar mais tempo, dando suporte a múltiplas versões de browsers e fabricantes, o que não aconteceria se todos os navegadores adotassem os mesmos padrões
- o “version targeting” é ruim para a Microsoft porque, se o comportamento padrão da engine do Internet Explorer tende a ser sempre a mesma do IE7, então, porque se interessar por novas versões do IE?
- a coexistência de múltiplas engines aumenta o tamanho (em kbytes) dos browsers e o consumo de memória e, portanto, prejudica a instalação em dispositivos móveis. Também representa um enorme potencial para problemas de segurança, pois cada engine está exposta a um tipo de ataque. Além disso, cada engine tem que poder falar com a outra. Eu posso ter um documento em um modo com IFRAMES em outros modos. Esses documentos podem manipular o DOM do outro, o que gera um potencial problema de compatibilidade a ser resolvido. Por último, vale a pena ressaltar que, na verdade, você nunca pode dar um “freeze” na manutenção de uma versão. Se uma falha de segurança ou um “crasher bug” forem achados, você terá que corrigí-los. Multiplique isso pelo número de engines e a manutenção se tornará um fardo pesado.
Eu recomendo a leitura dos seguintes artigos de profissionais consagrados, todos publicados no último mês, para que vocês tenham uma visão mais ampla da questão:
February 21st, 2008 at 10:16 am
Excelente POST Dudão,
A minha pergunta é: O que a Globo.com vai escolher como padrão de implementação?
Outra dúvida apenas de o IE continuar sendo a grande maioria, o crescimento do FF esta absurda, depois que passamos a usar o Flash como padrão de vídeo no Globo Videos o browser da Mozilla deu um salto razoável em participação.
Minha dúvida para o pessoal de client-side é: Não é mais fácil fazer um site funcionar em FF (usando padrões) e depois adaptá-lo ao IE do que o contrario?
February 24th, 2008 at 3:11 pm
Eis que surge a pergunta óbvia e que eu não abordei no meu POST (alguém já disse que difícil é enxergar o óbvio. A frase não era exatamente essa, mas eu me reservo o direito de alterá-la um pouco aqui. Então, valeu pela pergunta Antonio!).
Em seu artigo “The browses of 2009″, John Resig, criador do jQuery, não inclui o IE8 na sua lista de browsers avaliados para 2009, porque ele ainda deve estar em versão beta ou porque a sua versão final deve estar sendo lançada. De qualquer modo, a audiência para essa versão do IE ainda não será relevante e, portanto, a relação custo-benefício será bastante baixa.
Durante um bom período de tempo ainda teremos que prestar suporte ao IE7 e também ao IE6. John estima que em 2009 a proporção deva girar em torno de 35% para o IE6 e de 45% para o IE7 (dados dos Estados Unidos??).
Eu acho que a transição para o chaveamento das páginas da Globo.com para o IE8 vai se dar lentamente, mas vai acontecer um dia. Se a promessa de que o IE8 vai passar no Acid2 Test for mesmo verdadeira (muitos duvidam da notícia), sua engine vai oferecer suporte aos mesmos padrões que a maioria dos outros grandes browsers oferecem (Safari, Opera e Mozzila têm anunciado que não adotarão a solução de “version targeting” do IE). E as próximas versões do IE devem seguir a mesma tendência. Então será mais fácil desenvolver e testar páginas que funcionem de forma muito semelhante em todos esses navegadores.
Até lá, o desenvolvimento continua do mesmo modo que vem sendo feito hoje. Vamos procurar seguir os padrões da web para que nossas páginas sejam “forward-compatible” e para tirar proveito dos novos recursos que a web oferece. Ao mesmo tempo, vamos ter que oferecer suporte ao IE6 e IE7, tendo em vista a enorme fatia da nossa audiência que usa essas versões. Eu concordo com você: sim, é uma boa estratégia desenvolver as páginas seguindo padrões (que FF, Safari e Opera seguem, em grande parte) e depois adaptá-las ao IE6 e IE7, usando hacks e “feature detection”. E vamos esperar que um dia essas versões do IE fiquem obsoletas.
De qualquer modo, ainda há tempo suficiente pra analisar que abordagem adotarão os outros grandes portais. Cautela e estudo da concorrência nunca fizeram mal. Muita gente boa ainda não quer se pronunciar a respeito, ou está esperando o lançamento do IE8 para fazer uma análise mais segura.
Quem viver verá.
February 24th, 2008 at 4:06 pm
Atualizei o POST e acrescentei mais alguns pontos que a crítica tem levantado como possíveis problemas na adoção do “version targeting”. Também incluí mais um link como referência (o último).