Tableless » internet explorer

O IE6 vai morrer no Brasil

Diego Eis — Fri, 16 Dec 2011 13:30:07 +0000

Ontem a Microsoft anunciou que em Janeiro vai ativar a atualização automática para os Internet Explorers dos sistemas Windows XP, Vista e Windows 7! E sabe por onde eles começarão a fazer esse milagre? No Brasil e na Austrália. Este é um passo importante para que a web, do mundo, avance mais rápido.

O mais interessante é a Microsoft está diferente. Ela realmente está colocando o usuário em primeiro lugar. Por exemplo: toda vez que o sistema atualizar a versão do IE, essa atualização não mudará a sua configuração de browser padrão, nem as configurações de buscador, bookmarks, nada. Isso faz parte da nova filosofia que a Microsoft tem adotado nos últimos tempos e que está dando muito certo.

Se consumidores e empresas não quiserem atualizar seus browsers, eles tem a opção de não fazer o update e continuar recebendo suporte para a versão do IE que eles ainda terão. Há também a possibilidade de desinstalar os updates caso seja necessário. Em versões mais avançadas do IE, a Microsoft colocará uma opção de desativar as atualizações automáticas.

Essa decisão é ótima para os consumidores, desenvolvedores e pricipalmente para as empresas. A Web ficará melhor e mais segura. Com esta decisão, nós, desenvolvedores, teremos um campo farto para novas oportunidades de entregar experiências melhores para nossos usuários. Com o IE9 já temos algumas features do HTML5 que funcinam. Nós iremos gastar menos tempo codificando para um browser específico, corrigindo erros e bugs. Isso quer dizer que sua obrigação de convencer e educar seu chefe e cliente fica bem mais fácil.

Você entende o que está acontecendo? Não é um grupo de desenvolvedores que resolveu tentar matar o IE e deixa a web livre… é a própria Microsoft. Você sabe o quanto isso é importante? Sério, pense nisso.
Eu sei que não faz mais que a obrigação dela já que foi ela que começou essa confusão toda, mas vamos lá… há quanto tempo estivemos esperando por uma decisão dessa?

Microsoft, obrigado!

Veja o post na íntegra no blog do IE.

E use este link para pegar a imagem do post em tamanho maior.

Posts Relacionados

Ferramentas de diagnóstico

Diego Eis — Mon, 11 Apr 2011 16:46:49 +0000

Se você escreve CSS e HTML provavelmente tem problemas de compatibilidade e visualização. Isso é normal, acontece com os melhores desenvolvedores. Quando isso acontece, o melhor a se fazer é um trabalho investigativo. Esse trabalho normalmente é ingrato porque você demora horas investigando o seu código para encontrar o erro e geralmente esse erro é solucionado com uma linha de código. Para você descobrir qual é essa linha, você precisa de ferramentas que te ajudem a decifrar todo o problema. Vou indicar algumas aqui que você já deve conhecer.

Ferramentas de Inspeção

Hoje a maioria dos browsers tem sua própria ferramenta de inspeção. O Firefox incorporou a Firebug, o IE tem a Developer Tool, o Chrome e o Safari tem o web inspector do próprio Webkit. O Opera usa o Dragonfly.

Com estas ferramentas você consegue facilmente encontrar o elemento, verificar o seu estilo CSS e entender qual das propriedades está causando o problema. Você consegue editar essas propriedades e ver o resultado ali mesmo.
Entenda que essas ferramentas não são utilizadas para salvar seu CSS diretamente servem apenas para fazer o trabalho investigativo.

Além de nos ajudar com HTML e CSS, os “inspectors” nos ajudam muito com debugging de Javascript. Você consegue localizar exatamente um determinado problema adicionando observer points para verificar o funcionamento de partes do script.

XRAY

O XRAY é um bookmarklet que te mostra as informações sobre um determinado elemento apenas clicando em cima dele. Você salva o bookmarklet e pronto. Clicando em qualquer elemento, você consegue informações como tamanho, nome da classe e do id, hierarquia, margens e qualquer outro estilo relacionado ao elemento.

SelectORacle

Você já deve ter visto algum seletor muito, mas muito complexo e difícil de se entender. Algo do tipo:

body > ol > li p;
:not(a);
p:not(.section);
body > h2:not(:first-of-type):not(:last-of-type);
ul li:nth-child(2n+3):not(:last-child);
ol li:nth-child(-3n+9);
ol li:nth-child(7n-3);
button:not([DISABLED]);
html|*:not(:link);

Se você parar alguns preciosos minutos você consegue entender exatamente o que cada um dos seletores quer dizer. O SelectORacle te fala em segundos o que cada um dos seletores quer dizer, explicando em poucas palavras cada uma das funções.

Validadores de HTML e CSS

Validar seu HTML e CSS não é ponto crucial para a aprovação do código pelo cliente, mas ele validar o código é muito importante para que ele não vá para a produção com erros de sintaxe. Estes erros podem causar grande parte dos erros visuais de crossbrowser. Cada browser se comporta diferente ao encontrar uma tag aberta ou colocada no lugar errado. Se o IE quebra o layout porque a tag não está fechada da forma correta, mas nos outros browsers o visual da página aparece normalmente, você logo fará um Hack para consertar o problema no IE.
Por isso é interssante que antes de incluir um CSS Hack em seu código, procure a SOLUÇÃO do problema antes de fazer um “workaround”.

O W3C disponibiliza o validador de HTML, que já está entendendo algumas coisas de HTML5. E o validador de CSS, que ainda não entende CSS3.

Posts Relacionados

Desenvolvendo para IE6

Diego Eis — Mon, 06 Dec 2010 18:11:43 +0000

Você ainda faz sites para IE6? Já me fizeram uma pergunta dessas certa vez. A resposta: Sim. Mas…
Desenvolver para Internet Explorer 6 já foi uma obrigação. Enquanto ele era o browser mais utilizado e ainda era o browser mais atual da série, nós tínhamos que desenvolver para ele. Não havia escolha. O cenário atual é outro.

Eu não desenvolvo sites para o Internet Explorer 6 se o cliente não pedir. Nas propostas e nas reuniões costumo deixar bem claro que o IE6 está fora da cartilha de browsers compatíveis. Nesse momento é bom conversar com o cliente para entender o mercado dele. Caso ele precise que o Internet Explorer 6 seja previsto, eu aviso duas coisas: 1. O valor da proposta vai aumentar. 2. O tempo de desenvolvimento também.
Claro que os motivos para estas decisões precisam ser explicados. Não vou aumentar o valor da proposta simplesmente porque sou contra o IE6. Mas porque eu terei mais trabalho pela frente.

É muito trabalho, para pouco retorno
Eu não preciso dizer para você que o Internet Explorer 6 é complicado. Você já sabe. Mas o seu cliente não deve saber.
Para que o IE6 passe no teste de satisfação, temos que seguir alguns longos passos:

1.   Previsão de bugs de compatibilidade de CSS e HTML.
2.   Previsão de CSS escrito exclusivamente para o IE6.
3.   Bateria de testes e pente fino de Design em comparação ao layout original e outros browsers.
4.   Manutenção exclusiva
5.   Muito código e limitações de tecnologia

Previsão de bugs de compatibilidade de CSS e HTML.
Não preciso dizer que o IE6 é uma colcha de retalhos. Há dezenas de bugs conhecidos relacionados ao desenvolvimento com CSS e HTML. Todos estes bugs precisam ser previstos e solucionados.
Muitos desenvolvedores já tem conhecimento destes bugs já preparam o código para que eles sejam previamente solucionados e não haja surpresas posteriores. Infelizmente isso nos leva para o próximo tópico.

Previsão de CSS escrito exclusivamente para o IE6.
Não é nada inteligente escrever código CSS cheio de Hacks. Você acaba misturando código errado com código correto. Sem contar que que usuários de browsers atuais não precisam baixar um código com hacks para solucionar problemas de um browser descontinuado. Por isso, uma solução interessante é criar um arquivo CSS apenas para o Internet Explorer 6. Entenda que nesse arquivo não haverá todo o código do site, apenas o código que servirá para curar os bugs de layout exclusivos do IE6.
Atualmente essa solução é a mais interessante porque o IE6 está prestes a sumir. Quando isso acontecer, basta você retirar a linha que linka esse código e pronto, seu site não suporta mais IE6.

Bateria de testes e pente fino de Design
Invarialmente você precisará gastar um tempo para fazer uma bateria de testes em todo o layout para se certificar de que nada está fora do lugar.
É regra haver diferenças gritantes de alinhamento, medidas e distâncias no layout do Internet Explorer 6 em relação ao layout original e aos outros browsers.

Manutenção exclusiva
Prepare-se para ter alguém cuidando exclusivamente do Internet Explorer 6 durante tempo indeterminado.
Com os browsers atuais, é normal fazermos implementarmos um layout e o resultado ser homogêneo durante as versões posteriores dos browsers. Se você precisar fazer alguma alteração brusca no layout, prepare-se para a manutenção no IE6.

Muito código e limitações de tecnologia
Um exemplo clássico é o suporte ao PNG. Havia um trabalho terrível para replicar sombras e determinados tipos de gradiente por conta do efeito alpha que os designers aplicavam nas imagens. O desenvolvedor client-side precisava fazer tantos slices de imagens quanto nos tempos do desenvolvimento com tabelas. A ideia de que o design deveria trabalhar para o conteúdo era totalmente esquecida. O design deveria ser seguido ao pé da letra, mesmo que isso prejudicasse a informação.
Ainda com o exemplo do PNG. Se quisermos que o PNG funcione no IE6, é necessário a utilização de alguns códigos extras de Javascript. O resultado não é 100%, há um consumo desnecessário de banda e também o browser consome processamento de máquina do usuário. Escrevemos muito código para ter por resultado.

Os exemplos acima são decisivos para o desenvolvimento. Isso precisa ser explicado se seu cliente faz questão do IE6. Contudo, há clientes que precisam dessa compatibilidade por obrigação, por conta de um legado que não é simples de resolver. Aí não tem jeito. Você vai ter mais trabalho e o cliente vai gastar mais. Ninguém fica feliz.

O processo de evangelização é feito nas trincheiras. Então, mãos à obra!

Posts Relacionados

Google Apps não suportará mais IE6

Diego Eis — Tue, 02 Feb 2010 11:58:08 +0000

Recebi hoje um email do Google explicando que em 2010 eles irão deixar de suportar o IE6. Vitória!
Contar com o IE6 na cartilha de suporte é subutilizar o HTML5 e JavaScript. Aqui mesmo na Visie, temos projetos que o HTML5 e CSS3 seriam a resposta, mas ainda não podemos utilizar por causa do IE6, IE7 e em alguns casos o IE8.

Deixar de suportar o IE6 é questão de sobrevivência. E para matar o IE6, nós precisamos evoluir. Cabe a nós educar o usuário. Formar um mundo novo.

Abaixo segue o email recebido do Google.

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology. This includes faster JavaScript processing and new standards like HTML5. As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 as well as other older browsers that are not supported by their own manufacturers.

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010. After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Google Apps will continue to support Internet Explorer 7.0 and above, Firefox 3.0 and above, Google Chrome 4.0 and above, and Safari 3.0 and above.

Starting this week, users on these older browsers will see a message in Google Docs and the Google Sites editor explaining this change and asking them to upgrade their browser. We will also alert you again closer to March 1 to remind you of this change.

In 2009, the Google Apps team delivered more than 100 improvements to enhance your product experience. We are aiming to beat that in 2010 and continue to deliver the best and most innovative collaboration products for businesses.

Thank you for your continued support!

Sincerely,
The Google Apps team

Email preferences: You have received this mandatory email service announcement to update you about important changes to your Google Apps product or account.

Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

Posts Relacionados

Safari 4 Beta

Diego Eis — Wed, 25 Feb 2009 02:42:43 +0000

O Safari é o quarto browser mais utilizado segundo o The Counter, com 4%, logo atrás do Firefox com 17%.

O beta da sua versão 4 acabou de ser lançado e tem uma série de modificações visuais e outras novidades.
Na sua versão beta, foram adicionados algumas características interessantes para a utilização da navegação do usuário. A Apple diz que são 150 novidades na versão 4 beta. Dê uma olhada aqui na lista completa.
Vou comentar rapidamente as que me chamaram mais a atenção.

Mudanças visuais

Houve uma série de mudanças visuais que além de impressionar, ajudam bastante na experiência de navegação. As abas por exemplo, foram colocadas no topo da página, como o Chrome. Isso facilita e aumenta a área útil do browser.

A interface do Safari no Windows segue o mesmo padrão do sistema. Em vez de carregar uma interface própria, que faz com que o programa se torne mais pesado, o pessoal da Apple resolveu fazer com que o Safari tenha o visual nativo do Windows.

Uma característica que, pelo que eu me lembre, apareceu primeiro no Opera e depois no Firefox, foi agora adotado também pelo Safari que é a Full-Page Zoom. Quando o usuário tem dificuldades para ler o texto no browser, antigamente os browsers aumentavam o tamanho da Fonte do texto. Agora, com o Full-Page Zoom, o browser dá um Zoom na pagina inteira, como se fosse um zoom no Flash. É mais interessante porque mantem o design do site intacto e resolve o problema do usuário.

Foi adicionado também proteção contra Pishing e Malware, autocompletar inteligente no campo de endereço e busca.

Desenvolvimento Web

O pessoal do Safari também implementou uma série de novidades para nós, desenvolvedores. Infelizmente, muitas coisas não poderemos utilizar por conta da falta de suporte idêntico de outros navegadores. Mesmo assim, já sabemos que o Safari está com uma série de boas intenções para ajudar a comunidade e facilitar o desenvolvimento para web.
O pessoal que desenvolveu o Safari, ainda continua levando a sério aquela história de suportar a próxima geração de padrões. Ou seja, o Safari é um dos únicos a suportar, por exemplo, HTML 5 media tags e CSS Animation.
Ele também suporta agora CSS 3 Web Fonts, isso significa que você, designer, não está mais amarrado com meia dúzia de fontes.

Sobre HTML5, o Safari agora suporta as características de Offline Support e MediaTags. Sem contar que ele passou no teste Acid 3.
Ele também está renderizando mais rapidamente scripts em Javascript. A Apple diz que a renderização do Javascript ficou 6 vezes mais rápida que o IE8 e 4 vezes mais rápida que o FF3. Alguém quer fazer o teste?

Ele ganhou também um Inspetor de código decente. Um ponto contra é que não é possível editar a página por esse Web Inspector como fazemos com o Firebug. Mesmo assim, ele é muito completo, dá para substituir a Firebug.

Eles inseriram uma série de outras novidades para que possamos controlar erros e fazer testes na hora do desenvolvimento. Realmente é um kit completo (ou quase) de desenvolvimento web. Para ver o resto das características, veja a lista completa aqui!

Se você quer saber mais detalhes sobre a compatibilidade de CSS do Safari e outros detalhes importantes, a Apple mantém uma página de apoio ao desenvolvedor web. Lá você encontra uma série de materiais interessantes sobre o desenvolvimento para Safari e informações sobre o WebKit.

O resto das mudanças são coisas que fazem o Safari se aproximar mais do Firefox e Internet Explorer. Mesmo assim, ainda acho que a Apple faz pouca “propaganda” do seu browser. Ele é muito conhecido no mundo Mac, mas ainda é um anônimo no mundo Windows!

Aos poucos o Safari ganha corpo e conquista sua fatia do mercado. A briga vai ser silênciosa como eu sempre digo, mas muito concorrida. Mais do que nunca os browsers estão entendendo a receita de conquistar os usuários e os desenvolvedores. Ponto para o Safari, mas ainda há um grande caminho para percorrer.

Posts Relacionados

Propriedade Float do CSS

Diego Eis — Fri, 13 Feb 2009 13:06:02 +0000

Se o Internet Explorer não soubesse como funciona a propriedade float do CSS, o advento dos Padrões Web não vingaria tão cedo. A propriedade float é a propriedade responsável por “administrar” a diagramação do site. É com ela que você irá organizar as caixas e deixá-las exatamente onde devem ficar. A propriedade float dá mais consistência ao Layout. Diferentemente da propriedade position, que pode trazer uma série de inflexibilidades, deixando o layout mais engessado.

Neste vídeo, mostramos um pouco como funciona a propriedade float e sua parceira, clear.
Se quiser, você pode ver uma versão em textual aqui.

Este vídeo e muitos outros podem ser encontrados no Campus Online. Visite e cadastre-se grátis para ter acesso a vários vídeos e conteúdos sobre Padrões Web, Javascript, Ajax, Python e outras coisas.

Posts Relacionados

Web Standards Project – WaSP

Diego Eis — Mon, 23 Jun 2008 18:09:00 +0000

No início, fabricantes de browsers, W3C e desenvolvedores começaram quase que ao mesmo tempo.

Neste começo não brotaram desenvolvedores web do chão. Essa profissão não existia. Os primeiros que trabalharam nessa área, migraram de profissões parecidas: quem era programador desktop naquele tempo, começou a programar para web. Quem era designer de impresso, começou a fazer design para web.

Os desenvolvedores

Os programadores estavam se acostumando com a maneira nova de criar sistemas e sites para web. E designers estavam se habiatuando às diferenças que existiam no design para web e impresso. Haviam muitas coisas para se acostumar, começando pelos erros de compatibilidade.

O W3C

O W3C foi criado para regulamentar e criar padrões para a publicação de conteúdo na web. Quando ele começou, não haviam documentos completos, com listas e regulamentos explicando cada um dos padrões. Esses documentos eram rascunhos, muitas vezes incompletos e com apenas uma descrição do que seria aquele padrão.

Com a falta de documentação completa e detalhada, os browsers aproveitavam para criar códigos proprietários, dificultando o desenvolvimento.

Os browsers

O Netscape (antigo Mosaic), era o browser com a maior base de usuários. Para ser sincero, não haviam muitos browsers concorrentes naquela época. A Microsoft, aproveitou o poder que ganhara com a distribuição do Windows com a IBM, e criou o Internet Explorer para concorrer com o Netscape. Foi aí que a Guerra dos Browsers começou.

A guerra por usuários somada com a falta de padrões resultou em códigos proprietários. Conquiste os desenvolvedores e conquistará a web.

Todo esse tumulto no começo da web fez com que o desenvolvimento de sites se tornasse mais complicado, confuso. Em conseqüência a mão de obra se tornava mais cara e o custo de desenvolvimento também. Era caro comprar um site e era mais caro ainda manter esse site.
Era preciso fazer duas versões de sites: uma para Internet Explorer e outra para Netscape. Qualquer atualização ou alteração de layout, era necessário modificar as duas versões. Isso significava trabalho em dobro, logo o custo aumentava.

A Cavalaria – WaSP

Um grupo de desenvolvedores, na maioria designers, formaram um movimento chamado Web Standards Project – WaSP. Um grupo cuja missão seria divulgar os Padrões Web como guias para o desenvolvimento web. O projeto era encabeçado por profissionais como Jeffrey Zeldman, inconformados com o caminho que o desenvolvimento web estava caminhando. E eles tinham toda a razão.

A primeira grande coisa que fizeram foi convencer a Netscape a doar para a comunidade o engine do Netscape. Um grande feito que se não fosse alcançado, hoje não teríamos a fundação Mozilla com seu browser Firefox.

A segunda missão foi fazer com que os fabricantes de browsers seguissem as idéias e recomendações do W3C.
O diferencial naquele tempo dos browsers era apenas o número de usuários. Não haviam add-ons, interface interligada com serviços sociais, leitores de feeds, nem nada do gênero. Seguir o W3C era dizer adeus ao código proprietário e abrir oportunidades para os desenvolvedores a criarem sites para o browser concorrente.

Outro objetivo do grupo era fazer com que os desenvolvedores também adotassem os Padrões do W3C. E esse objetivo está sendo cumprido até hoje.
A resitência de hoje, não é nada com a resistência encontrada há 5 anos atrás. Os desenvolvedores estão mais aberto às novas propostas e os novos profissionais já começam aprendendo da maneira correta.

Hoje as coisas estão bem mais fáceis. Browsers e desenvolvedores lutam a favor dos padrões. W3C e entusiastas estudam novos padrões e pedem sugestão dos profissionais.
Com o amadurecimento das partes, o conhecimento se renova e desenvolver para web fica mais divertido.

Posts Relacionados

Browsers – Guerra Fria

Diego Eis — Tue, 18 Mar 2008 20:48:42 +0000

Quando o Netscape e o Internet Explorer faziam a Guerra dos Browsers o principal objetivo era conquistar usuários. As formas que os dois utilizavam para adquirir adeptos eram prejudiciais para o desenvolvimento web. Basicamente o que os browsers faziam era criar códigos proprietários. Isso gerava um retrabalho terrível para os desenvolvedores. Se você tivesse 10 sites para gerenciar, na verdade seriam 20, por conta de ter a necessidade de haver uma versão para Netscape e outra para Internet Explorer. Isso gerava trabalho em dobro. Se houvesse alguma modificação no layout, texto ou programação, o desenvolvedor teria que atualizar as duas versões dos sites.
Era normal que o visitante ao entrar nos sites via dois logos: um do Netscape e outro logo do Internet Explorer e a seguinte frase: “Qual browser você utiliza?” Então o usuário escolhia qual browser ele utilizava e clicava no link que o levava para um site desenvolvido especialmente para aquele browser.
A idéia era simples: se a grande maioria dos usuários utilizassem o Netscape, por exemplo, os desenvolvedores seriam obrigados a desenvolver em primeiro lugar para o Netscape e deixar o Internet Explorer em segundo plano.

O problema é que essa guerra estava ficando insuportável para os desenvolvedores. Desenvolver para web estava ficando muito caro. Ter um site simples publicado custava caro e o desenvolvimento era demorado e confuso.

Felizmente essa guerra acabou. Hoje os fabricantes de browsers estão com outro pensamento. A guerra de hoje é mais silenciosa e agrega muito mais valor ao desenvolvimento web. Os métodos para conquistar usuários é direcionada em serviços. Sim, ainda é mais difícil conseguir os usuários mais leigos, mas essa massa está se renovando e novos usuários de internet já sabem qual browser escolher e os motivos para escolhê-lo.

Internet Explorer 8, Safari 3.1 e Firefox 3 estão se esforçando para alcançar o nível máximo de suporte aos Padrões. Isso conquista o desenvolvedor que por sua vez vai evangelizar o usuário leigo a utilizar o browser mais interessante e útil para as necessidades dele.

Agora, o objetivo mais difícil ainda precisa ser cumprido: convencer os desenvolvedores a utilizar os Padrões Web. Com certeza este é o caminho mais complicado. Pelo menos, se não for por bem, vai por livre e espontânea pressão. A seleção natural infalível do mercado cuidará desses.

Posts Relacionados

IE8 – O sonho não acabou

Diego Eis — Sun, 09 Mar 2008 05:19:58 +0000

Para você se inteirar do assunto, leia Browser Targeting Version.

No artigo que recomendei acima, lá nos últimos parágrafos dei minha opinião sobre a antiga decisão da Microsoft:

Mesmo assim, acho que tudo deveria ser nivelado por cima. Porque os desenvolvedores que se preocupam e utilizam os Padrões da maneira correta, são os que devem marcar o browser? Não seria mais fácil criar uma metatag para marcar os sites que não devem ser renderizados com o suporte avançado de Padrões? Quem deve se preocupar, são os desenvolvedores que não dão a mínima para os Padrões. Eles sim devem trabalhar para deixar seus sites atualizados.

A Microsoft voltou atrás com a decisão do Browser Targeting Version. Eles decidiram que, por padrão, o IE8 irá renderizar os sites no modo mais complacente com os Padrões Web possível, esse modo está sendo chamado de “Super Standards Mode”. Se você não desenvolve com Padrões, comece a se preocupar.

A idéia de nivelar tudo por cima, para mim, sempre foi o melhor caminho. Se você não desenvolve com Padrões, ou se desenvolve despreocupadamente, é melhor mudar. Caso você se encaixe neste perfil, há duas opções:

Ou você aplica o Browser Targeting Version. Isso fará com que o IE8 utilize o motor de renderização do IE7.
Ou pára de preguiça e aprende de uma vez por todas a fazer sites padronizados. Para mim, este é o melhor caminho.

Fazer um browser rigoroso, faz com que o mercado saia da zona de conforto e comece a pensar. Tudo sobe um nível e a coisa fica mais interessante. Mesmo a decisão sendo boa, a galera ainda tem um pé atrás (leia os comentários).

As atualizações do IE8 são ótimas. Há uma série de características que fazem muita falta no IE6 e no IE7 e que agora farão parte do IE8. Por exemplo, as pseudo-classes :before, :after e :focus. A propriedade content, que serve para gerar conteúdo, também estará nessa nova atualização. Entre outras facilidades que antes usávamos apenas em browsers como Firefox, Opera e Safari.

Me preocupo com o momento em que o IE6, IE7 e IE8 estarão sendo utilizados pelos visitantes, aí sim teremos um grande problema. Ou três.

Posts Relacionados

Browser Targeting Version

Diego Eis — Fri, 25 Jan 2008 19:05:12 +0000

Para que possamos entender melhor o assunto do IE8 e como ele tratará as páginas, é bom que possamos entender o que houve no passado. Se você se lembrar bem como foi entre os anos de 1999, 2000 e 2001, provavelmente você vai lembrar que durante algum tempo, tínhamos que nos virar para garantir a total compatibilidade dos nossos sites em diversos browsers. Os principais eram o IE5, IE6, Firefox e Opera. Era uma época que – como no começo da bolha – estava tudo acontecendo ao mesmo tempo. Os Padrões Web estavam virando moda, os browsers, pelo menos os mais inteligentes, estavam se virando para suportar os Padrões, e os usuários ficando mais espertos e ativos na internet. Tudo era muito passível de erros de compatibilidade e renderização.

O principal caso era do Internet Explorer 5 e Internet Explorer 6. Os dois browsers tem uma renderização muito diferente. O Internet Explorer 6 tem um suporte melhor ao CSS do que o IE5. Isso causou um problema: pelo menos durante um certo tempo, nós tínhamos que prever a compatibilidade para o IE5. E agora, tínhamos que pensar também no Internet Explorer 6. Os dois renderizavam o CSS de formas bem diferentes, o que causou um certo dilema que foi resolvido com a seguinte solução: Chaveamendo de Doctype.

O Chaveamento pelo Doctype

O DOCTYPE (Document Type Definition, DTD) serve para indicar qual o tipo do documento o browser está lendo. Ele define qual linguagem estamos utilizando e isso ajuda o browser a saber como ele deve tratar aquele código. O código DOCTYPE deve ser escrito em primeiro lugar no código HTML. Aqui eu falo um pouco mais sobre o DOCTYPE.

A solução é seguinte: dependendo do DOCTYPE colocado no documento o browser renderiza da forma antiga, chamada de Quirks Mode ou em Strict Mode, que é o modo que o browser busca ter mais suporte com os Padrões. Isso é aplicado para o IE6. Se colocarmos um DOCTYPE XHTML 1.0 ou um HTML 4.01 o Internet Explorer 6 renderiza no modo esperto, se colocarmos um DOCTYPE de uma versão velha do HTML – como o HTML 3 – ou se não colocarmos o DOCTYPE, o IE 6, renderiza a página como o IE5, com menos suporte aos Padrões. Essa solução é feita para garantir uma certa retrocompatibilidade dos sites. Assim, o desenvolvedor que preferir manter a compatibilidade com o IE5, ele tem essa opção. Essa solução foi ótima no começo e felizmente o IE5 não demorou muito para sair de linha. Hoje é totalmente indicado que o desenvolvedor utilize um DOCTYPE novo (HTML 4.01 ou XHTML 1.0), que é a maneira mais correta de escrever HTML e que faz o IE6 renderizar melhor a página.

O causo do IE8

O Internet Explorer 7 veio com muitas correções de CSS e trouxe outros problemas, mas teoricamente ele melhorou um bocado a nossa vida, pelo simples fato de que ele é um browser mais moderno e tem um suporte mais avançado que o IE6. Mesmo assim, o problema de retrocompatibilidade ainda existe: muitos sites era bem visualizados em IE6, mas quebravam quando visitados com o IE7.

O Internet Explorer 8 será muito mais diferente dos IEs passados. O pessoal que desenvolve o IE8 está criando um motor de renderização totalmente diferente. Ele já passa no Test Acid 2 e promete ter o máximo de compatibilidade sobre o CSS 2.1. Isso é um problema.

Os problemas que os desenvolvedores enfrentam são muitos. A falta do suporte total das linguagens que usamos, traz problemas de interpretação dos padrões. É normal hoje em dia, que dois browsers, atualizados, tragam renderizações diferentes de uma mesma ação.

A solução que o pessoal da Microsoft, juntamente com o WaSP foi a seguinte: usando uma declaração de metatag, nós poderemos especificar a maneira que o motor de um browser como o IE8 deverá renderizar a página. O exemplo da metatag é o seguinte:

Isso faz com que o IE8 renderize a página utilizando o máximo de Padrões (lembre-se de que eles estão trabalhando para que o IE8 tenha suporte total ao CSS 2.1. Bem como o pessoal do Firefox 3 e Safari).

Esta meta será colocada no HEAD do documento. Isso pode ser incorporado em outros Browsers, dessa forma:

Para melhorar a velocidade de processamento do navegador, será importante priorizar esta metatag colocando, se possível, em primeiro lugar dentro da tag HEAD, antes das outras tags meta e não poderá ser incluído via Javascript DOM.

Um problema que pode causar é o seguinte: imagine que você coloque a metatag dizendo que o IE8 deverá renderizar aquele site da melhor maneira possível. Quando um IE9 for lançado, o site estará travado para o IE8. O IE9 não renderizará direito o site. O desenvolvedor deverá atualizar a metatag para o IE9.

Minha opinião

Como tudo no desenvolvimento web, devemos esperar para ver. Não podemos prever muita coisa antes da efetivação dessa regra. Só iremos ter certeza dos resultados e os possíveis problemas, quando aplicarmos essa solução.

Mesmo assim, acho que tudo deveria ser nivelado por cima. Porque os desenvolvedores que se preocupam e utilizam os Padrões da maneira correta, são os que devem marcar o browser? Não seria mais fácil criar uma metatag para marcar os sites que não devem ser renderizados com o suporte avançado de Padrões? Quem deve se preocupar, são os desenvolvedores que não dão a mínima para os Padrões. Eles sim devem trabalhar para deixar seus sites atualizados.

Minha parte terrorista diz que provavelmente seria uma boa idéia quebrar a regra “Don’t Break the Web” e ver o que aconteceria com os sites que não estão nos Padrões. Talvez isso iria mobilizar clientes e desenvolvedores e forçá-los a dar mais crédito aos Padrões e a fazer atualizações estruturais no site. Normalmente os clientes não sabem e nem querem saber dos dilemas que passamos com a falta de compatibilidade. Faz parte do papel deles.

Não podemos esquecer da falta de informação dos usuários. Muitos nem sabem o que é “Navegador”. Ter uma maneira que os browsers deles fossem atualizados sem que eles mexessem um dedo seria uma forma interessante de ter a compatibilidade dos browsers sob controle. Os devenvolvedores teríam mais acesso às informações sobre o que mudou na renderização comparando com a versão anterior do browser. Isso facilitaria o trabalho de atualização e ajustes dos sites. Seria maravilhoso, se o mundo fosse perfeito. Mas…

(09/03/08) UPDATE: E a Microsoft mudou de idéia.