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:
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.
É 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!
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.
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.
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.
Acabei de ler o artigo “Acessibilidade Web: 7 mitos e um equívoco” escrito pela Lêda Spelta do AcessoDigital. Um artigo que só quem entende profundamente o tema, poderia escrever com tanta clareza.
Mesmo assim, quero fortalecer o que ela disse no artigo e enfatizar mais o que já venho dizendo aqui.
No artigo a Lêda fala sobre aqueles mitos (desculpinhas esfarrapadas, em vez de mitos, na minha opinião) que profissionais sem conhecimento básico e falta de curiosidade, sempre dizem quando ouvem a palavra acessibilidade.
Já disse isso aqui e em algumas palestras: damos uma série de desculpas para não ter trabalho demais, principalmente quando achamos que fazer um site acessível dá um trabalho terrível e não tráz retorno algum. Sempre deixamos para segundo plano ou para a próxima atualização do site. Acontece que esse é um assunto que simplesmente não pode ser procrastinado como geralmente fazemos.
Acessibilidade é coisa séria e grande engano se você acha que o trabalho de acessibilidade destinam-se apenas para cegos ou para pessoas com qualquer deficiência visual. Ela envolve uma série de grupos de usuário, e cada grupo com tem sua particularidade.
Infelizmente ainda estamos deixando em segundo plano essa tal de acessibilidade… Na maioria das vezes um simples “alt” faz a diferença. E ainda assim, pode servir como desculpa para não fazer um trabalho mais rebuscado.
O desenvolvedor coloca os alts nas imagens, um link para pular direto para o conteúdo, um menu acessível e acha que o trabalho de acessibilidade está terminado. Embora essas coisas ajudem muito, o trabalho não é completo. Embora seja uma iniciativa interessante.
No último mito que a Lêda descreve - que na verdade não é mito, mas sim, um conceito pré formado pela maioria dos profissionais - é a seguinte: “Meu site é direcionado a um público específico; ele não interessa a todos os grupos de usuários.”
Ela dá pelo menos 4 exemplos matadores sobre esse pensamento tacanho.
Se você vai fazer um site que vende monitores, você pode pensar não precisa fazer um site para cegos porque, afinal de contas, um monitor pode não fazer muita diferença para alguém que não enxerga. Mas e se esse alguém tiver um filho designer ou fotógrafo? Ele não pode entrar o seu site para escolher um monitor de presente para o filho?
Momento Jabá:
Oficina de Wordpress Visie: Wordpress é a mais poderosa ferramenta de blogging da atualidade. É a ferramenta usada em todos os blogs aqui da Visie, e em boa parte dos blogs mais populares do Brasil e do mundo. Extremamente simples de usar, facilmente configurável e poderosamente extensível, Wordpress ainda por cima é open source e completamente gratuito.
Wordpress é a ferramenta por trás do Tableless.com.br. A idéia da oficina nasceu numa conversa com o Juliano Spyer, no Blogcamp. Teremos um dia para quem quer aprender o básico de Wordpress para, por exemplo, criar seu próprio blog, um dia para designers, falando de temas para Wordpress e um dia para programadores em que vamos construir plugins e ferramentas que se integrem ao Wordpress.
13 ComentáriosAcabei de fazer uma Tabela de Compatibilidade de CSS..
Quem achar algum erro, por favor, me dá um alô.
Essa tabela será atualizada com outros elementos do CSS. Ainda tenho alguns elementos pré-definidos que faltam ser colocados. Assim que der mais um tempinho, vou colocar os links dos exemplos e atualizar a tabela com novas coisas.
Sei que a navegação vai ficar um pouco pesada. Preciso colocar links de âncora para poder facilitar a navegação entre as tabelas. Mas, por enquanto, isso deve quebrar o galho de quem está com dúvidas
[update] Seguindo a dica do Rubens, fiz uma versão para impressão da tabela. Agora ficou fácil imprimir sem gastar tanta tinta. ![]()
Desde que adquiri um MotoQ (se lê MotoQUIU) eu venho usando o Opera Mobile como browser padrão. Ao contrário da versão pra desktops, o Opera Mobile é pago. Por este motivo, quando a data expirou, eu resolvi usar por um tempo o Internet Explorer.
Descobri que a forma com que o IE Mobile renderiza as páginas é tão boa quanto a do Opera Mobile. A velocidade de navegação também é ótima.
O Opera usa muito um sistema que eles chamam de SSR,que em teoria, melhoraria (ou pelo menos tentaria) a visualização de sites em dispositivos móveis. Acontece que esse modo deixa o site muito, mas muito feio. Neste caso, tive a impressão de que o Internet Explorer renderiza melhor os sites que não foram feitos para mobile.
Para quem quer dar uma ajuda para o pessoal que usa browsers mobiles, existe uma metatag chamada MobileOptimized:
<meta name="MobileOptimized" content="sualargura" />
Essa metatag é usada principalmente pelo Internet Explorer Mobile para otimizar melhor o site quando visto de SmartPhones, PocketPCs, etc. O valor colocado ali no atributo “content” deve ser a largura que o browser deve limitar seu layout quando visto de um mobile.
Aviso aos navegantes: fazer image-replacement usando text-indent não funciona no IE para Mobiles. Parece que ele não reconhece o text-indent, o que faz com que o texto fique por cima do logo.
A qualidade de rederização das fontes também achei melhor que a do Opera Mobile. Achei as fontes muito mais nítidas e legíveis.
Uma coisa ruim que achei o IE para Mobiles é a falta de abas. Isso seria muito útil. Normalmente estou sempre visitando e usando mais de dois sites simultâneamente. E sair de um para visitar o outro é uma alterativa terrível. Isso sim me faria voltar para o Opera.
Não é a primeira vez que me perguntam se eu acoselho o uso de includes. Não sei o motivo, mas grande parte do pessoal não usa includes. Parece que isso é uma daquelas coisas de uso exclusivo de programadores. Engano deles.
Includes (por exemplo) é uma das coisas que ajudam e muito o trabalho da equipe inteira. Menus, cabecalhos, rodapés, e qualquer coisa que você ache que vá se repetir em mais de uma página no site deve ser colocado em includes. Já vi muita gente, em pleno século 21, repetir o código do menu em todas as páginas. E sim, quando algo muda no menu, ele muda na página inteira. Muito triste.
Faz parte do trabalho parar um tempo por dia para pesquisar novas metodologias, novos meios para agilizar seu trabalho diário. Costumo fazer isso no final do expediente. Normalmente sempre encontro maneiras que resolvem meus problemas mais urgentes.
PS.: Já já novidades aqui no Tableless.
39 ComentáriosO Consórcio World Wide Web (W3C) tem a satisfação de anunciar a inauguração do primeiro escritório W3C na América do Sul: o W3C Escritório Brasil, abrigado no NIC.br (Núcleo de Informação e Coordenação do Ponto BR), em São Paulo, Brasil. W3C deseja aumentar a interação com a comunidade de língua portuguesa com a instalação deste escritório, principalmente porque o status da arte do ambiente tecnológico no Brasil está em perfeita sintonia com as tendências no W3C, tais como mobilidade, aplicações e vídeo para o mundo Web.
Gostei da parte do “aumentar a interação com a comunidade de língua portuguesa”.
10 Comentários