Tem havido um bem-vindo ressurgimento de interesse em tipografia para web durante o último ano ou quase, com muitos artigos e palestras em conferências oferecendo técnicas e teoria. Freqüentemente, é reafirmada a noção de que boa tipografia requer controle apurado do tamanho da fonte e da altura da linha. Mas esta é a web: uma mídia especial onde o leitor pode ter tanto controle quanto o designer – isto implica em que o texto na web, embora se incline à vontade do designer, também deve ser redimensionável de forma confiável através dos navegadores e plataformas.

Neste artigo, nós vamos reconciliar a necessidade de precisão do designer com a necessidade de redimensionar o texto de imediato do usuário, chegando a uma boa prática que satisfaça designers e usuários e que funcione através dos navegadores e plataformas.

Nós vamos alcançar nosso destino pelo método tradicional de tentativa e erro. Mais do que aprovando o trabalho pioneiro de 2002 de Owen Brigg, eu criei um caso base com seis iterações e 161 capturas de tela. Siga-me, você não vem?

A suíte de teste

O conteúdo usado para testes foi um layout de duas colunas com o corpo principal à esquerda e uma barra lateral à direita. O texto foi configurado com Arial para adicionar consistência através dos sistemas operacionais e plataformas.

Os navegadores usados para teste foram Safari 2, Firefox 2 e Opera 9.5α rodando no Mac OS x Tiger, juntamente com o Internet Explorer 6 (IE6) e o Internet Explorer 7 (IE7) rodando no Windows XP com o Cleartype ativado. É óbvio que essa não é uma lista completa de navegadores, sistemas operacionais, ou mecanismos de renderização, mas cobre a maioria dos usuários por aí hoje.

Cada sistema operacional e navegador foram rodados usando suas configurações padrões. Toda iteração foi testada para ver como cada navegador renderizava o texto nos tamanhos pequeno, médio, grande e muito grande, junto com níveis de zoom de página de 90%, 100%, 110% e 120%, onde aplicável.

Caso base

Primeiro era necessário certificar que os navegadores proporcionassem uma linha de base consistente a partir de onde iniciar. O caso base mostra que em cada navegador, o tamanho padrão do texto é de 16px quando nenhum estilo foi aplicado (outro além dos padrões do navegador), e o texto é escalonado razoavelmente de forma consistente através do quadro.

Tamanho do texto em pixels – iteração 1

O tamanho padrão do texto do caso base é um bom lugar para começar, mas para a maioria das pessoas (designers, clientes, e seus clientes) 16px é muito grande para o texto principal. Em nosso exemplo, o texto principal foi reduzido para 14px, com o texto da barra lateral configurado em 12px. Essa primeira iteração somente faz isso, configurando as fontes em pixels:

.bodytext p {
font-size:14px;
}
.sidenote {
font-size:12px;
}

O resultado é que o Safari e o Firefox ainda redimensionam o texto, enquanto que o IE6 e o IE7 não. O texto pode ser redimensionado no Opera e no IE7 usando-se a ferramenta de zoom da página, que amplia o layout da página, com os textos e imagens dentro.

Tamanho do texto em ems – iteração 2

Embora a fatia de mercado de navegadores se diferencie de site para site, e as estatísticas de fatia de navegadores são desenhadas na areia, é seguro afirmar que o IE6 é ainda usado por muitas pessoas. Portanto, configurar os textos em pixels impediria que muitas pessoas o redimensionassem. Também há um argumento que diz que os usuários do IE7 deveriam ser capazes de redimensionarem o texto sem serem forçadas a usar o controle de zoom.

A próxima unidade a se tentar para dimensionamento de texto são os ems. O em é uma unidade tipográfica verdadeira, recomendada pelo W3C, e proporciona a ausência de keywords de precisão. Trabalhando a partir do padrão de 16px, os seguintes estilos deveriam proporcionar os tamanhos de textos desejados:

.bodytext p {
font-size:0.875em; /* 16x.875=14 */
}
.sidenote {
font-size:0.75em; /* 16x0.75=12 */
}

Os resultados mostram que, através de todos os navegadores, o texto na configuração média do navegador é renderizada de forma idêntica aos textos configurados em pixels. Eles também demonstram que os textos dimensionados em ems podem ser redimensionados através de todos os navegadores. Porém o IE6 e o IE7 inaceitavelmente exageram os tamanhos pequeno e grande dos textos redimensionados

O body dimensionado em porcentagens – iteração 3

Uma forma de se consertar o redimensionado exagerado do texto no IE6 e no IE7 é dimensionar o body usando-se porcentagem. Portanto, mantendo-se os sem em nosso conteúdo, os seguintes estilos foram testados:

body {
font-size:100%;
}
.bodytext p {
font-size:0.875em;
}
.sidenote {
font-size:0.75em;
}

Os resultados mostram que a diferença entre as configurações para maior e menor no IE6 e no IE7 não é mais exagerada, significando que agora nós temos todos os navegadores renderizando os textos num tamanho idêntico em sua configuração média e redimensionando o texto de forma consistente.

Configurando a altura da linha em pixels – iteração 4

Artigos recentes sobre tipografia, tais como “Configurando texto na Web para um grid base” (A List Apart, abril 2007), enfatizam que boa tipografia requer um grid vertical, isso quer dizer um ritmo vertical sólido conseguido com uma altura de linha calculada consistente. A principal implicação é que a altura da linha deve ser a mesma, não importando o tamanho do texto (para que a altura da linha, ou o grid vertical permaneçam consistentes, não importando o tamanho da fonte).

Para nosso exemplo, uma altura de linha adequada é de 18px, logo, isso é adicionado ao body assim:

body {
font-size:100%;
line-height:18px;
}
.bodytext p {
font-size:0.875em;
}
.sidenote {
font-size:0.75em;
}

Os resultados mostram que a altura de linha de 18px é herdada por todo o texto na página – note como o texto da barra lateral possui o mesmo ritmo regular que o corpo principal. Especificando-se uma unidade (neste caso, px) ao configurar a altura da linha permite que o valor seja herdado em toda página. Se uma altura de linha sem unidade fosse especificada, o multiplicador seria herdado, resultando em alturas de linha renderizadas proporcionalmente ao tamanho do texto, portanto quebrando o ritmo vertical.

Infelizmente, os resultados mostram que a altura de 18px não é escalonada pelo IE6 e IE7 quando o texto é redimensionado, significando que as configurações maiores parecem achatar o texto.

Configurando a altura da linha em ems – iteração 5

Quando os pixels falharam antes, nós nos voltamos para os ems. Repetindo a lógica nos proporciona os seguintes estilos:

body {
font-size:100%;
line-height:1.125em; /* 16×1.125=18 */
}
.bodytext p {
font-size:0.875em;
}
.sidenote {
font-size:0.75em;
}

Os resultados agora mostram redimensionamento preciso e consistente do texto e da altura da linha através de todos os navegadores. Perfeito. Ou quase.

O problema de monoespaço do Safari – iteração 6

Os observadores entre vocês devem ter percebido uma pequena falha nas capturas de tela do Safari: a fonte monoespaçada incluída no texto do body é renderizada de forma inconsistente. Para textos configurados em pixels, o Safari renderiza a fonte monoespaçada no mesmo tamanho que o texto de largura proporcional ao seu redor. Quando o texto é configurado em ems, porém, o Safari renderiza o texto monoespaçado muito menor que o texto ao redor. A inconsistência parece se originar nos tamanhos de texto padrões do Safari, que são 16px para “fontes padrões” e 13px para “fontes de largura fixa”. O Safari 3α em OS X não parece sofrer esse problema.

Você poderia decidir que texto monoespaçado subdimensionado no Safari é algo com que você e seus leitores podem viver, e como o Safari 3 é incluído no OS X Leopard e na última atualização do Tiger, não será muito longe o dia que o problema provavelmente desaparecerá. Para os controladores nervosos que não podem esperar, uma forma de contornar esse problema é enviar textos dimensionados em pixels para o Safari.

O seguinte código anexa um comentário condicional revelador de nível anterior para os nossos estilos, para que os pixels sejam enviados para todos os navegadores, exceto IE6 e IE7 (note a sintaxe [if !IE], instruindo o IE/Win a ignorar o código a seguir).

<style type="text/css">
body {
font-size:100%;
line-height:1.125em;
}
.bodytext p {
font-size:0.875em;
}
.sidenote {
font-size:0.75em;
}
</style>
<!--[if !IE]>-->
<style type="text/css">
body {
font-size:16px;
}
</style>
<!--<[endif]-->

Os resultados mostram o texto e a altura da linha redimensionados de forma consistente através de todos os navegadores, incluindo o texto monoespaçado do Safari 2.

Os comentários condicionais são controversos, com muitos delatores e defensores, mas eu acredito que a abordagem é apropriada nesse caso, já que estamos usando uma função do navegador (comentários condicionais) para contornar um comportamento do navegador (não redimensionamento de pixels). Também se deve notar que, para maior clareza, o código listado acima apresenta as regras de CSS dentro dos elementos style; a boa prática, porém recomenda o uso de folhas de estilo inseridas com a tag link no seu lugar.

Conclusão

A nossa tarefa era encontrar uma forma de dimensionar o texto que permita aos designers manter o controle apurado da tipografia, sem sacrificar a capacidade do usuário ajustar o seu ambiente de leitura. Nós testamos várias unidades através de navegadores comuns. Foi mostrado que dimensionar o texto e a altura da linha em ems, com uma porcentagem especificada para o body (e uma condição opcional para o Safari 2), proporciona textos apurados e redimensionáveis através de todos os navegadores em uso hoje em dia. Essa é uma técnica que você pode colocar na sua bolsa de kits e usar como uma boa prática que satisfaz designers e leitores para dimensionar texto no CSS .

Adendo

Ems podem ser difíceis de trabalhar, especialmente quando se aninham muitos elementos dentro de outros elementos, pois pode ser difícil acompanhar a matemática. Porém, comentar bem suas folhas de estilo e aplicar os estilos aos elementos a partir do body para dentro, pode manter as coisas fáceis de seguir. Esse exemplo mais complexo e sua folha de estilo demonstram como dimensionar elementos aninhados usando o body como ponto de partida.

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).