Dicas: ie6 PNG24

Como prometido no post anterior (sem nenhum sucesso porém com dois comentários) colocarei muitos dos truques que aprendi com o site da Gafisa para corrigir este “pequeno” bug do ie6 com PNG24.

Explicarei algumas soluções, com seus prós e contras, e deixo por vocês a melhor escolha, pois eu não tenho nenhuma para indicar… alias, tenho sim! Vamos nos unir e acabar com o ie6 da máquina de todos os usuários que ainda insistem em usá-lo!!!

Microsoft AlphaImageLoader Filter

Como primeira, e única opção (vocês verão porque), existe um filtro que foi criado pela Microsoft para corrigir este bug.
Ele consiste basicamente em retirar o background que já foi aplicado no CSS e inserir a imagem novamente através um seletor que funciona apenas do ie6 pra baixo e do comando do filtro (explicação completa sobre hacks e a parte de seletores consultem http://www.maujor.com/tutorial/hacks-css.php ), como podemos ver no exemplo abaixo:

*html #exemplo {
  background:none;
  filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='_img/exemplo.png');
}

Agora a explicação do que funciona e o que simplesmente é impossível de se fazer com este filtro.

Possível

A Microsoft disponibiliza para este filtro duas opções de recorte da imagem, através da propriedade sizingMethod que aceita os valores:

  • crop – recorta a imagem exatamente do tamanho original, independente do tamanho do elemento que aonde ele está.
    filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='_img/exemplo.png', sizingMethod='crop');}
  • scale – estica a imagem horizontal e verticalmente para caber no tamanho do elemento.
    filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='_img/exemplo.png', sizingMethod='scale');}

Por costume eu sempre utilizo a propriedade crop, para ter certeza que a imagem não terá nenhuma distorção, porém quando preciso criar um repeat da imagem utilizo o método scale, que gera o mesmo efeito.

Impossível

Apesar de parecer muito bacana este filtro ele tem grandes limitações. Você se lembra que eu disse que ele retira o background e aplica o filtro né? Então, como ele faz essa substituição do background pelo filtro todas as definições como background-position e background-repeat não funcionam. Por isso fica impossível posicionar uma imagem com filtro no bottom de um elemento, pois o filtro tem como padrão o left top. Existe como corrigir ou fazer uma gambiarra para isso? Sim existe! Mas não é nada bonito.

Durante o desenvolvimento de um dos sites que participei todas os modais tinham bordas arredondadas e uma sombra para dar a impressão que estavam flutuando sobre o site, e para fazer um HTML correto não utilizei a famosa <div class=”bottom”> e por conta desta teimosia perdi algumas horas com meu querido amigo Sandro Salles procurando uma solução. Esta solução consiste em pegar a imagem que faz o fechamento do Box e aumentar a sua altura com um fundo transparente sem repetir a imagem. Com isso podemos utilizar o sizingMethod=’scale’ que o filtro colocará a imagem esticada fazendo o fechamento. Dependendo do tamanho do Box ou se ele é expansível podemos ter uma distorção na imagem, porém é a melhor solução que eu já encontrei até hoje.

Além do problema com o posicionamento o Microsoft AlphaImageLoader Filter trás um outro problema sério. Quando ele retira o background e aplica o filtro nota-se que todos os elementos que estão dentro dele perdem o click e deixam de ser selecionáveis. Mas como tudo no mundo do CSS tem solução (e mais uma vez Sr. Sandro Salles estava lá para ajudar) conseguimos encontrar a combinação perfeita para que tudo volte ao normal.

Para este bug basta seguir a seguinte receita:

  • Elemento pai: elemento aonde é substituído o background pelo filtro deve ter a propriedade position:static
  • Elemento(s) filho(s): tudo o que está dentro ou o elemento que engloba todo o conteúdo do objeto que recebeu o filtro, deve ter declarado no CSS position:relative
<div>
  <span>
    <p>
      Por favor preencha todos os campos corretamente
      <a href="javascript:void(0)" title="fechar">Fechar</a>
    </p>
  </span>
</div>
<style>
  div {
    position:absolute;
    top:60px;
    left:40%;
  }
  span {
    position:static;
    width:200px;
    height:40px;
    padding:30px 40px;
    background:img/exemplo.png;
  }
  *html span {
    background:none;
    filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='img/exemplo.png');}
  }
  p {
    position:relative;
  }
</style>

Esta combinação mágica é infalível, e foi testada e re-testada diversas vezes, por isso, podem confiar (exemplo disso é o site da Gafisa).

PNG Behavior HTC

Como eu já disse anteriormente só existe uma solução para o PNG24 no i6, scripts e behaviors são baseados no Microsoft AlphaImageLoader Filter, e este exemplo não foge a regra. Existem muitos sites que disponibilizam este behavior na extensão .htc que fazem exatamente a mesma coisa, porém tem dois grandes diferenciais com relação ao da Microsoft.

A primeira delas é a quantidade de código que precisa ser escrita, para fazer uma chamada em um objeto que precisa do filtro aplicado no CSS basta declarar behavior: url(”pngbehavior.htc”);  contra aquele código gigante que eu já coloquei a cima. Isso em um grande projeto pode fazer toda a diferença na quantidade de KB que vai pesar o seu CSS (acreditem! Até a quantidade de ; no CSS faz diferença).

Outra vantagem deste behavior é poder aplicá-lo a uma imagem colocada no código via <img src=””>, algo que não conseguimos com o Microsoft AlphaImageLoader Filter pois só aplicamos a elementos do CSS. Uma maneira fácil de aplicar o behavior a todas as imagens do site sem ter que ficar fazendo marcações especificas é através da declaração a baixo:

img { behavior: url(”pngbehavior.htc”);  }

Visto por estes dois pontos a utilização do behavior é maravilhosa, mas como nada é perfeito temos um grande porém. O behavior geralmente utiliza o sizingMethod = scale; para dar uma flexibilidade maior, mas as vezes não queremos que ele tenha o comportamento de scale, então temos que optar, porém existe uma maneira de fazer uma “gambiarra” com o behavior que é duplicar o arquivo e modificar no próprio código as propriedades, salvar com nomes diferentes e aplicar com o crop ou scale quando for mais conveniente.

Outra coisa que o behavior precisa para funcionar é a famosa imagem blank.gif, com 1×1 px transparente, muito utilizada em layouts com tabela para definir os tamanhos de linhas ou colunas quando eram menores do que 10px (se bem me lembro). Esta imagem é utilizada quando o behavior encontra uma imagem inserida no código. Ele faz a substituição do espaço transparente, que no caso do nosso amigo é tratado como cinza, por essa imagem transparente. O contra disso é que o usuário de ie6 quando clica na imagem para salvar só vai conseguir salvar o blank.gif.

Javascripts

Juro que até quase a metade de 2008 nunca havia ouvido falar em javascript que corrigisse o problema de PNG24 no ei6 e fiquei muito animado quando soube, pois acredito muito no “poder” javascript para tratar de diversos problemas, como uma solução que foi desenvolvida e diz que não é necessário usar nenhum tipo de hacks em CSS para o ie6 e faz com que ele interprete corretamente todas as propriedades, mas o script ainda não está 100%, tem algumas falhas, inclusive esta do PNG24, por isso não vou colocar ela na minha lista.

Mas vamos aos scripts comentados. Fiz alguns testes para saber a qualidade e eficiência, e encontrei alguns pontos falhos, como em todas as outras soluções.

Começando pela solução do TwinHelix fiquei animado pela descrição no site da versão 2.0 Alpha 3 que diz ter sanado o problema do background-position quando o filtro é aplicado. Bem, realmente eles conseguiram corrigir isso, fazendo uma duplicação de div via javascript e colocando a imagem que precisa ficar posicionada com o background-position:bottom dentro de um outro div.

Pois bem, falando assim parece que a solução é perfeita e que eu deveria ter colocado como solução definitiva, mas como nem tudo é perfeito o script tem uma grande falha, que é substituir todos os elementos que recebem o filtro por div, ou seja, no teste que fiz aonde tinha um <h3> com um PNG24 aplicado em seu background ele simplesmente trocou a tag, fazendo com que todas as outras informações de formatação fossem perdidas. Por este “pequeno” detalhe eu simplesmente ignorei esta solução e estou aguardando o lançamento de um outro release que corrija isto, caso eles vejam isso como um problema é claro.

A outra solução que é o ifixpng que utiliza como base o jQuery, que é aonde começam os problemas. Hoje em dia muitos sites utilizam o jQuery por ser uma boa biblioteca de javascript com muitos efeitos, complementos, ter uma boa documentação e compatibilidade com todos os browsers, porém o peso de todos esses scripts carregados no site pode gerar problemas de performance.

Particularmente eu acho desnecessário você colocar uma biblioteca como o jQuery e o complemento do ifixpng apenas para corrigir algumas imagens no site, acho que a solução do Microsoft AlphaImageLoader Filter é bem mais pratica e leve neste caso, mas se você já utiliza jQuery para outras funções no site pode ser bem interessante.

Além do problema do peso desnecessário também existe a questão do background-position que não funciona e também existe a necessidade do elemento estar visível na página para ele aplicar o filtro, como a própria documentação no site explica.

Conclusão

Não vejo saida a não ser convencer todos que o ie6 é um browser obsoleto, mas isso ainda demora um tempo para virar realidade e enquanto isso teremos que nivelar tudo por ele.

Espero que este artigo possa ajudar na hora de decidir por alguma solução e ajudar a não levar tantos tropeços durante o desenvolvimento de um site.

construindo: www.gafisa.com.br

Para iniciar as histórias de trabalho achei interessante falar sobre o site da Gafisa, que foi um grande desafio desde o começo, pois teve o layout pensado para flash, plataforma que não foi aprovada pelo cliente e que a criação achou que não teria problema de ser implementado em HTML, ou seja, não modificaram absolutamente nada para facilitar a minha vida.

A primeira encrenca do site foi o fundo orgânico que não se repetiria no monitor do iMac de 22’’ com seus 1680px de largura do cliente. Tentei argumentar que ficaria muito pesado fazer um .jpg deste tamanho, mas ele disse que queria assim mesmo, então nós fizemos… afinal, para algumas coisas, o cliente tem a razão.

Passado esse pequeno “stress” inicial comecei a produção do site, recortando as imagens semitransparentes que cairiam sobre o fundo orgânico, uma maravilha não? Muitos png24, e png24 sobre png24 para nunca perder a harmonia do layout.

Até certo ponto esta brincadeira é saudável e divertida, pois fica tudo muito bonito, mas quando você abre o site no ie6 tem aquela agradável visão do inferno, pois é claro, ele não aceita o png24 sem que tenhamos que fazer um hackzinho bacana para ele (às vezes me ponho a pensar que o ie6 é um browser muito egoísta, e por isso a Microsoft foi muito feliz em tê-lo feito, afinal, todo mundo tem que lembrar e se preocupar com o ie6, a ponto que o Safari, Opera e outros browsers são deixados de lado muitas vezes).

Mas deixando esse pequeno porém de lado parti para a produção do site criando a Welcome Page e home, aonde já teria o esqueleto do site tendo apenas que mudar o famoso miolo para as páginas internas, que maravilha não? Isso seria o paraíso, afinal recortar uma imagem ou outra e colocar uns textos não é nada muito complexo.. mas não, nas páginas internas os títulos foram feitos com fontes maravilhosas e uma sombra, sim, uma sombra que cairia por cima do fundo orgânico que já mencionei. Pronto! Estava ai, mais uma leva de png24 que deveria ser criada e devidamente hackeada para funcionar no nosso browser camarada.

Finalizado o recorte de todos os títulos voltei a produção das telas, e qual é a nova surpresa que eu tenho? Todos as páginas internas que tem menus que não utilizam fonte de sistema! Nessa hora eu fui obrigado a me levantar e conversar com o pessoal da arte, pois já estava passando um pouco do limite ter que recortar cada texto do site. Bem, tentativa em vão, só para variar um pouco, e dalhe o Riedel de novo recortando mais uma penca de png24 para fazer o menu, que é transparente, por cima do fundo orgânico (maldito layout!!).

Neste ponto eu comecei a questionar o peso do site, sinalizei para meus superiores que não seria uma boa fazer desta forma, mas como o cliente e a criação juntos têm mais razão que Deus, continuei tocando os HTML’s do site.

Mais dois dias replicando tela, escrevendo textos, ajustando o CSS, validando o XHTML na W3C, até que chego aos formulários do site (eu quis matar a criação essa hora!). Formulários com campos translúcidos, bordas arredondadas e de tamanho diferente dependendo do campo!! Não isso não podia ser verdade.. havia perdido a conta de quantos png24 que o site tinha, ele estava virando um elefante alado, mas continuava lindo, é claro.

Uma semana e meia de trabalhando sozinho no projeto, dois dias de ajuda de outro recurso da empresa em quatro telas, e estava “tudo pronto” para integrar com o .net.

Agora eu poderia voltar à paz, continuar tocando outros projetos e dando apenas uma assistência caso algo ficasse torto dando aquela mudadinha no CSS.. mas para variar não foi nada disso, afinal, o Riedel esqueceu que o site tinha quatro layers translúcidos que aparem por cima de qualquer elemento da página e que ainda não estavam feitos.. muito bom hein Riedel, que cabeça a sua!

Toca eu fazer os benditos layers! Caral** que trabalheira que isso me deu, só para não perder o costume os textos eram imagens tinham transparência e todo o bla bla bla e frescurada que vocês já devem estar de saco cheio de ler. Bem, eu também já estava de saco cheio, não agüentava mais fazer hack para ie6, arrumar isso e aquilo, mas o site não estava todo integrado ainda, e esta novela se arrastou por mais um mês, em uma jornada média de 16h por dia (meu recorde nesta brincadeira foi 36h de trabalho seguido, com pausas para cigarro, banheiro e refeição), sete dias por semana e sem poder curtir nenhum feriado.

Mas todo sacrifício tem o seu lado bom, alguns dias antes do lançamento colocaram na parede de recados uma página inteira do jornal O Estado de São Paulo, do caderno de imóveis com um anuncio lindo dizendo que o novo site da Gafisa estava por vir. Foi uma alegria enorme, junto com o desespero, pois ainda faltava aquele tapa, aquela coisinha que fica por último.. mas no final tudo sempre dá certo.

Destes problemas todos que eu tive durante a produção do HTML e CSS do site aprendi muito sobre hacks  de png24 para ie6, e é sobre isso que o meu próximo post, passando dicas e mostrando tudo o que eu já li e testei para que vocês não tenham tantos problemas como eu tive.

Web 2.0, Web 3.0… e a acessibilidade, fica pra Web 4.0?

Primeiramente, que fique bem claro, eu odeio esse termo Web 2.0, sou totalmente contra desde o início, mas para exemplificar melhor o que pretendo escrever serve bem.

No início de 2005, época em que trabalhava para o Governo do Estado de São Paulo, me passaram a responsabilidade de criar um site que fosse 100% acessível, o que era uma novidade para mim e para o Governo. Comecei então a correr atrás de referências, sites que falassem sobre como criar sites sem tabela, pois até esta época a minha vida era cortar imagens no Photoshop e jogar em tabelas no Dreamweaver e pronto (e como eu fazia isso bem!!).

A partir deste momento um mundo novo se abriu, preocupações que eu nunca havia tido como navegação por teclado, teclas de atalho para acesso rápido ao conteúdo da página, organização de conteúdo semântico, compatibilidade com leitores de tela, áreas de clique de botões maiores, funcionalidades de tamanho de texto, cores pensadas para pessoas com baixa visão ou qualquer tipo de deficiência.. dentre muitas outras coisas. Mas apenas com estes exemplos já dá para perceber que a Web 2.0 herdou e a Web 3.0 herdará muitas das coisas que a acessibilidade trata como base de sua existência, então vem a pergunta “porque não pensar em acessibilidade e complementar com novos pensamentos?”.

Imaginem que linda seria uma internet acessível a todos, que tem toda uma organização semântica para os buscadores, que contempla todas as firulas que a Web 2.0 propõe e ainda mais! Funciona em todos os tipos de dispositivos!! Maravilhoso não é?

Agora, um questionamento que sempre é feito por empresas quanto a isso:

“O quanto custa e quanto tempo é necessário para fazer?” e a resposta está na ponta da língua:

“Custa à mesma coisa, e demora o mesmo tempo”. Agora vocês devem estar achando que eu sou louco, certo? Por que não fazemos assim então? Eu posso me explicar… ou pelo menos tentar.

Desde que eu entrei na iThink aprendi muito, e pude passar um pouco do conhecimento que já tinha sobre desenvolvimento de interface para outras pessoas, mas também fiquei encarregado de corrigir a avaliação e conversar com muitos candidatos que aparecem por lá para a vaga de desenvolvedor de interface… e me desculpem, mas gente boa é difícil de achar no mercado  (na verdade, nem sei se tem tanta gente boa por ai). Na correção de alguns testes eu não perdia 2 segundos, e em outros ficava alguns minutos olhando e vendo se mesmo com alguns errinhos valia à pena chamar a pessoa para bater um papo, pois era algo que seria facilmente corrigido durante o período de experiência. Até hoje eu só corrigi 1 teste que eu pude falar “esse vale a pena, não preciso explicar nada”. Mas e ai, aonde eu quero chegar falando sobre isso? Quero mostrar que os profissionais de internet não sabem direito o que estão fazendo, e que as agências estão totalmente dependentes de algumas poucas pessoas que seguram a grande maioria dos Jobs (se existir um lugar que não é assim me avisem, quero trabalhar lá!).

Tendo este problema de profissionais de interface que não são suficientemente bons, junto com a incrível vontade que os programadores têm de pegar um XHTML validado e continuar fazendo com que ele seja validado (isso porque em todos os testes de programadores que eu vi na iThink, aonde existe o campo de auto-avaliação em conhecimento de HTML, todos colocaram 10), o cuidado de fazer um código que seja bem identado, que não precise de ajustes de CSS pós-integração e tirando layouts que não colaboram em nada, é praticamente impossível garantir bons trabalhos, de fácil manutenção e que atenderão os padrões de acessibilidade, semântica e validação W3C.

Depois de ter explicado isso volto à pergunta do título deste artigo “e a acessibilidade, fica pra Web 4.0?”. Por favor, não!!! Vamos capacitar melhor às pessoas, ensinar a elas como se faz um XHTML direito, como nomear classe e ID’s corretamente, como criar um menu com itens e sub-itens de forma organizada antes de nos preocupar com a Web 2.0! A evolução da internet tem que passar pela acessibilidade antes de querer se expandir. Cada vez mais nos distanciamos da criação de sites que sejam multi plataforma, pois dependemos completamente de javascript para fazer o Ajax que os clientes acham tão necessário! Porque afinal, Ajax é a Web 2.0 para eles!

Os sites precisam ser funcionais e depois ter as firulas, e não ter firulas que são a base funcional do site! Estamos indo totalmente contra a maré, e para desfazer este nó levaremos muito tempo, muitos sites precisarão ser refeitos e muito dinheiro será gasto.

Ajudem-me a levantar esta bandeira! Leiam este artigo publicado a mais de 2 anos e entrem nesta corrente de pensamento… Vamos salvar o nosso trabalho! Acessibilidade não é ser bonzinho, é ser inteligente!