Tableless - Desenvolvimento inteligente com Padrões Web

30/11/2007
Artigos

Dicas para ter compatibilidade nos browsers

Estava lendo o artigo do Fugita e pensei comigo mesmo: – Porque todo mundo sempre quer matar o Internet Explorer? A pergunta não foi difícil de responder: Compatibilidade. Quando desenvolvemos com Padrões Web, a primeira coisa que aprendemos é a …

Por


Estava lendo o artigo do Fugita e pensei comigo mesmo: – Porque todo mundo sempre quer matar o Internet Explorer?
A pergunta não foi difícil de responder: Compatibilidade.

Quando desenvolvemos com Padrões Web, a primeira coisa que aprendemos é a odiar o Internet Explorer. Sei disso porque a frase mais falada nos meus cursos e em algumas palestras é: Não funciona no IE6. Ou: Se funcionasse no IE6.
Grande parte dos problemas de desenvolvimento de um site se deve pela falta de compatibilidade entre browsers.

Infelizmente não posso dizer: – Esqueça o IE6.
Ele é até hoje o browser mais usado, – não por mérito, mas isso é outra história – portanto, viveremos por um tempo com a falta de compatibilidade e alguns bugs não só do IE, mas de todos os browsers. Mesmo assim, há maneiras de minimizar os problemas:

Graceful Degradation

Para quem não sabe, isso é uma premissa do desenvolvimento com Padrões Web. Este assunto é bem interessante. A idéia é a seguinte: existem diversos dispositivos, aparelhos e softwares que podem acessar sua aplicação web ou site. Acontece que cada destes meios tem sua limitação, seja uma limitação de software ou hardware. Mesmo assim, seu site precisa funcionar quando for acessado por eles. Se você faz um site com PNG semi-transparente, que não funciona no IE6, os usuários do IE6, precisam utilizar o site sem problemas. Se você faz seu site em flash e o camarada entra no site com algum SmartPhone que não funciona flash, seu site precisa funcionar de alguma maneira alternativa.

A moral da história é a seguinte: faça o site funcionar da melhor maneira possível para aquele meio de acesso. Você precisa dar a melhor experiência para aquele usuário. Mesmo que tenha que abrir mão de algumas coisas, como design, por exemplo. O importante é que funcione.

Logo, o usuário de desktop terá uma melhor experiência que o usuário de Smartphone. Mesmo assim, o usuário de smartphone terá a melhor experiência que o seu aparelho pode lhe trazer.

Entenda e estude a solução dos bugs

É mentira que apenas o IE6 tem bugs. Mas é fato que o IE6 é campeão em número de bugs. O remédio para contornar os bugs é sempre saber mais de uma técnica para fazer a mesma coisa. Acredite, sempre há mais de uma alternativa com CSS.

O mais importante é conhecer soluções simples, que não lhe tragam trabalho posteriormente. Se você sabe que determinada combinação de propriedades pode gerar algum tipo de bug em determinado browser, tente uma maneira alternativa. Crie, invente, converse com outras pessoas, pesquise. Se mesmo assim não houver jeito, use CSS HACK, mas apenas em ÚLTIMO CASO!

CSS HACKS, use com moderação

Vou ser sincero: CSS HACK pode fazer sua vida virar o inferno. Não estou brincando. Use com moderação. Com cuidado, com inteligência.

Grande parte dos desenvolvedores não gostam de perder seu precioso tempo tentando entender o problema para achar uma solução inteligente. Acabam usando CSS HACK par a resolver um problema imediato e acabam se acostumando mal. Sou a favor de perder tempo procurando a solução, mesmo naquelas horas apertadas e que cliente respira fundo no seu cangote. Você vai trabalhar duro apenas uma vez para nunca mais perder tempo com aquele problema.

Repita comigo: CSS HACK apenas em último caso.

Hoje, felizmente é possível fazer sites complicadíssimos sem utilizar CSS HACKS. Na maioria das vezes o uso do Hack é necessário por causa de um problema anterior: o código complicado.

Seja simples

Pense quantas vezes for necessário. Se você resolveu um problema com 3 divs, tente resolver com apenas 2. Se resolveu com 2, tente resolver com 1. Apenas se não conseguir, volte para 2 divs. E assim você faz com o resto do site. Quanto menos código HTML, melhor. Mas lembre-se, o pouco código HTML que você escrever, precisa ter significado. A semântica ajuda bastante neste sentido. Escrevendo código semântico, você garante que o código escrito será mínimo e significativo para sistemas de busca e outras aplicações que dependam da semântica para funcionar.

Escrever código demais é herança da metodologia antiga, onde nós escrevíamos uma gambiarra atrás de outra. Onde colocávamos tabelas em todos os lugares. Lembre-se que tudo mudou. Você tem que mudar também e o desenvolvimento apenas muda se você mudar sua maneira de pensar. Pense simples. Reaprenda o que puder e esqueça o antigo.

Visualize o resultado no próprio browser.

Outro costume terrível nosso é visualizar o resultado nos previews nojentos dos editores. Geralmente estes previews são baseados em apenas um browser, normalmente o browser padrão. Há uma opção de mudar o preview para o browser que você que quiser. Mesmo assim, pense comigo: Você sabe qual será o browser do visitante? Você sabe, na melhor das hipóteses que ele pode navegar com pelo menos 4 browsers: Firefox, IE, Safari e Opera. Isso se ele usar Windows. Portanto, não tem sentido utilizar o preview do editor.

Minha sugestão é a seguinte: abra os principais browsers e visualize a implementação ao mesmo tempo.
Eu abro Firefox, IE e Safari (de vez em quando). A cada modificação no CSS e no HTML, eu aperto F5 em cada um deles e vejo o resultado. Se percebo algum erro, já corrijo e sigo em frente. Nunca deixo para visualizar em todos os browsers depois que termino a implementação. Esso é um método muito perigoso. Você procrastina todos os problemas que você teve para o final. Isso pode gerar problemas irreversíveis e na maioria das vezes, quando acontece, é mais fácil recomeçar.

Lembre-se de que com Padrões Web ficou tudo mais fácil.
Era tudo muito mais difícil quando tentávamos desenvolver com padrões, mas nenhum browser suportava grane parte dos métodos. Hoje, todos estão interessados em ter suporte com os padrões e felizmente os browsers estão mais espertos.
O jeito é estudar, estudar e estudar. Pelo menos se você quiser ser um bom profissional.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://twitter.com/diegoeis/

Veja os outros posts de

  • Bruno Francisco Santos

    “CSS HACK apenas em último caso.”

    Sempre tento evitar os hacks, mas tem horas que eles são necessários. :(

    É que nem você disse, o jeito é estudar estudar e estudar.

  • http://acordapraweb.com Alexandre

    Sempre tento evitar os hacks, mas tem horas que eles são necessários.

    É sempre possível evitar os hacks jogando o CSS específico pro IE em conditional comments. Essa é a melhor prática possível, desenvolva pro Firefox e Opera (que tem suporte melhor aos padrões) e depois “conserte” o que quebrar usando um estilo exclusivo pro IE (ou um para cada IE..

  • http://tableless.com.br/ Diego Eis

    Eu não concordo Alexandre. E acho que Comentários Condicionais são a pior opção que pode ser tomada.

  • Bruno Francisco Santos

    Eu estou com o Diego, eu odeio esses comentários condicionais, tanto quanto os Hacks! Mas acabo optando por eles pelo motivo de manter ‘maior controle’ pois os códigos ficam todos juntos em uma página e se for preciso uma alteração, as vezes voce pode acabar se esquecendo dos condicionais e ficar um tempão procurando aonde que está o erro no css default da aplicaçao.

    Mas gosto infelizmente não se discute!
    heeh

    abraços

  • http://julioweb.wordpress.com Julio Fragoso

    Gostei de ver aquela parte de “Se você resolveu um problema com 3 divs, tente resolver com apenas 2. Se resolveu com 2, tente resolver com 1. Apenas se não conseguir, volte para 2 divs.”

    Parabéns pelo post !

  • http://www.ead.feuc.br EAD

    Obrigado pela dica com certeza vai ser d grande importância pra mim!!
    abrço

  • http://www.fernandodutra.revistaorigem.com.br Fernando Dutra

    Eu tento ao máximo não usa os css hacks, porém as vezes o novo “amigo” ie6 necessita de um, quando preciso, uso comentários condicionais.

  • http://www.aikistudio.com.br Fred Figo

    Olá Diego, tudo bem?

    Comentários condicionais não seriam uma alternativa ao uso de “HACKS” no CSS ?

    Grande abraço a todos ! :)

  • http://webdeleve.net tigo

    Diego, por favor, me explique o porquê dos Comentários Condicionais serem a pior opção.

    Css incorporado?
    Desenvolvedor cria vícios e gâmbias?
    Qual o problema dos CC?

  • Pingback: Tiago Floriano Webdesigner » IEncosto: boas leituras ;)

  • http://guilhermemattos.wordpress.com Guilherme Mattos

    Eu ainda não usei nenhum CSS HACK nos meus códigos. Não por falta de vontade (que foi muita, maldito seja o ie6!) mas que nos final das contas(depois de muito esforço e tempo!) acabou dando tudo certo.

  • http://www.virtualforce.com.br Giovani

    Sempre testo com FireFox, IE e Opera.
    As únicas diferenças que percebo que ocorre do FF pro Opera, é nas caixas de texto e Inputs. No resto é a mesma coisa

  • guilherme

    Diego, me explique uma coisa por favor!

    Eu estou usando no css uma propriedade p:first-letter (para que a primeira letra do texto tenha um destaque e tal). Quando executo no I.E. fica direitinho… mas quando executo no Mozilla Firefox, após eu passar o mouse em cima do texto (que é um link) a letra maíuscula e em negrito, diminui e nao fica mais em negrito perdendo o destaque.

    Eu usei o hack html>body antes de p:first-letter ficando mais ou menos assim:

    #conteudo html>body p:first-letter {
    font-size:16px;
    font-weight:bold;
    }

    não deu certo… ainda sou um iniciante em css e html…

    Queria MUITO que vc me ajudasse me dizendo o que devo fazer para que a first letter se comporte da mesma maneira como no i.e.

    Um abraço e parabéns pelos ótimos vídeos!

  • http://floripasom.com Acelio Filho

    Caras,

    Estou com várias dúvidas e talvez esteja pensando errado, mas…

    O Tableless veio para acelerar o carregamento das páginas web, que na época, tinham só tabelas.

    O conteúdo de uma célula(td) de uma tabela que está dentro de outra célula de outra tabela… só mostra o seu conteúdo depois que o navegador leu tudo. Demorava demais. os portais de vasto conteúdo foram os precursores do uso de divs, mas a função era esta: Fazer o conteúdo principal carregar antes, e depois os elementos decorativos e os banners…
    Carregando seguindo uma ordem definida dentro do HTML. O navegador seguia esta ordem e o conteúdo ia abrindo por partes…

    divs em position:absolute
    Mas o site ficava sempre alinhado pelo canto esquerdo da tela

    1
    2
    3
    div com conteúdo principal carrega primeiro
    div com conteúdo secundário - rodapé
    conteúdo secundário - o banner (pesado) no topo da página, vai carregar depois

    A questão é

    Se usar uma grande div, pra centralizar (por exemplo, neste site (div id=”geral”)) e dentro dela as outras, umas dentro das outras, como se usa agora, dá na mesma que usar tabelas.
    Falando de carregamento mais rápido…

    O navegador vai lendo tudo aquilo e só mostra o conteúdo depois de ler a tag de fechamento da primeira div, que fica no final do código.

    Acho que estou ficando velho. Quando fiz o primeiro site usando o princípio de Tableless só haviam 2 navegadores e 2 tamanhos de tela a se preocupar. A conexão era discada e o tempo para renderizar o conteúdo era a prioridade…

    Hoje sou viciado em tableless e nem consigo mais fazer sites sem estes problemas de compatibilidade de estilos e vários navegadores abertos (dá-lhe F5)…

    Acho que vou criar um padrão “Divs on the table”

  • Héliton

    Eu prefiro abrir mão de algum elemento no design do que usar hacks ou condições. :P +

  • Ale

    “Porque todo mundo sempre quer matar o Internet Explorer?
    A pergunta não foi difícil de responder: Compatibilidade.”

    Acredito que vc esteja enganado. Muitos odeiam o IE porque é o navegador mais inseguro. Com ele, é suficiente entrar num site pra contaminar o computador.

  • Pingback: Mais algumas dicas de compatibilidade entre navegadores

  • http://www.avb.org.br Daniel

    Olá Diego!
    Estou
    dando o
    primeiros
    passos na
    construção
    de web
    sites.
    Esse artigo veio bem na hora certa.
    Abraços.
    Daniel