12 Lições para Aqueles com Medo do CSS e dos Padrões

por Ben Henick

Quando eu conheci as Cascading Style Sheets no outono de 1998, eu estava tentando fazer coisas legais – fazer este negocinho mexer, fazer aquele outro mudar de cor – e foram mais 6 meses para que eu começasse a usar o CSS para controlar a apresentação ao invés do comportamento.

Eu levei dois anos para quebrar a confortável prisão dos layouts com tabelas, e mais dois para poder produzir layouts em CSS que foram originalmente pensados em tabelas.

Apesar de ser forçado neste período a trabalhar com obras de arte tão obsoletas como o Netscape 4.0 e IE 5.0 para Windows, a moral da história é bem clara: eu levei muito tempo para atingir proficiência genuína em CSS.

Existem muitos livros e artigos excelentes por aí, incluindo muitos escritos pelos colaboradores desta publicação. Enquanto a maioria destes trabalhos guia o desenvolvedor inexperiente por layouts desafiadores e ensinam com exemplos reais, poucos deles percebem que usar CSS para criar sites de acordo com os padrões requerem um pensamento que é desconhecido para muitos desenvolvedores experientes. Este requisito enfraquece muita gente talentosa, e por dois anos eu estive procurando pelas palavras que vão curar a dor delas.

As frustrações que eu ouço de outros desenvolvedores sobre o CSS são somente um eco daquelas que eu tive por anos. Como conseqüência eu gosto de pensar que consigo me relacionar, e estou escrevendo para transmitir as lições mais importantes que aprendi até agora.

Lição No. 1: Tudo que você sabe está errado… um pouco

Como estamos no mesmo barco, quero frisar que se você está começando a trabalhar com CSS, tudo que você aprendeu até agora provavelmente parece inútil, ou pior que isso. Este é um problema que deve ser jogado pela janela e atirado com a maior velocidade possível.

O que não será afetada é a sabedoria que você já adquiriu em assuntos como design, otimização, experiência do usuário, programação e gerenciamento de projeto. No entanto, os conceitos em que você está acostumado a utilizar este conhecimento mudam – às vezes drasticamente – quando você muda para as técnicas de produção de acordo com os padrões.

Como resultado, o melhor a fazer é limpar sua ficha. Jogue fora suas crenças e expectativas. Aproveitando, jogue fora as crenças e expectativas de todo mundo. Arregace as mangas e aprenda algo novo. Quando se trata de layout e produção, tente remover as palavras "mas" e "deveria" do seu vocabulário profissional por um tempo. Substitua-as por "como" e "por que" – e se comprometa a atingir os objetivos do seu projeto.

No nível de implementação, esta lição é sobre as diferenças entre o código com tabelas e o código semântico:

Tabelas x Semântica
Tabelas	Semântica	Implicações
Linear	Hierárquico	Desenhe para a informação, não apesar dela.
Processual	Funcional	Coloque as coisas onde elas pertencem.
Baseada no local	Baseada no Contexto	Deixe o código descrever o que é alguma coisa, antes que ele diga onde ela está.
Define restrições	Define domínios	Você não precisa empurrar os limites, porque eles se adaptarão às suas necessidades.

Finalmente, não se esqueça que existem coisas que as tabelas conseguem fazer, e existem coisas que o CSS consegue fazer. Algumas dessas capacidades são mutuamente exclusivas, e isto não diminui o poder do CSS.

Lição No. 2: Não vai ficar exatamente igual em todo lugar a menos que você queira um pouco de stress... e talvez nem assim

Existe um número absurdo de diferenças entre os engines de renderização, e as especificações do W3C sancionam estas diferenças. Você pode ajustar, refinar, hackear, e desistir, mas se você quer preservar sua vida social, você vai aprender a relevar as pequenas diferenças – e convencer os participantes do seu projeto a fazerem o mesmo.

Lição No. 3: Você será forçado a escolher entre o ideal e o praticável

A vida e o trabalho normalmente se tornam uma série de compromissos, especialmente quando as coisas estão em transição. O melhor que você pode fazer para usar os compromissos a seu favor é planejar efetivamente.

De tempos em tempos, no entanto, você deve esperar por situações em que será forçado a escolher o menor dos males , ou talvez até situações em que não tenha escolha. Sites que são incapazes de passar em testes de validação e acessibilidade vão acontecer, e você será forçado a aceitar estes contratempos mesmo quando suas convicções contrárias estiverem absolutamente corretas.

Aprecie os objetivos do seu site. Conheça as políticas do local de trabalho. Decida o que é mais importante para você como profissional. Aceite que as decisões de outros feitas sobre suas objeções, muito menos que aquelas feitas sem sua interferência, não refletem em nada no seu conhecimento ou integridade (apesar de refletirem na sabedoria com que você escolhe seus clientes). Escolha seu terreno, faça suas batalhas... e lute com aqueles que você pode realmente vencer.

Lição No. 4 (agradecimento a Antoine de Saint-Exupéry): Perfeição não é quando não há nada a acrescentar, mas quando não há nada a retirar

Quando se produz código para um site de acordo com os padrões, é muito fácil se prender ao jeito de fazer as coisas com tabelas e criar uma abundância de elementos dentro de outros. Mesmo que à primeira vista pareça senso comum adaptar o código ao design, isso te faz perder o foco da produção de acordo com os padrões.

Não force nada, e não acrescente código a não ser que o contexto peça isso. Foque na informação antes. Se você tem diversas instâncias de conteúdo que compartilham o mesmo propósito ou classificação, não hesite em colocá-los em divs ou spans que tenham uma classe nomeada de um jeito que descreva aquele propósito ou classificação. Se você quer colocar conteúdo num elemento que é comum a todas as suas páginas, a maioria das pessoas não te culpará.

Pelo contrário, se você está ficando louco com as divs porque você precisa de uns truques para preencher algumas coordenadas do layout (ou tem algum outro tipo de requisito de apresentação), é possível que você não esteja pensando em seu design como um todo. Como conseqüência, seu código ficará ainda mais difícil de atualizar do que aquele com tabelas que você está tentando substituir.

Remova tags sempre que possível... enquanto mantém a próxima lição em mente.

Lição No. 5: Alguns sites são o cúmulo dos extremos

Em muitos casos, a pessoa responsável pelo design de um site não tem responsabilidade por mais nenhum aspecto de sua implementação. Quando combinada com a falha em criar ambientes adequados para o site e suas seções, esta falta de contabilidade resulta num compendium de muitas páginas, e conseqüentemente, muito mais trabalho para os produtores.

É por experiência própria deste escritor que este problema é muito mais comum em projetos pequenos do que em grandes, o que leva estes projetos pequenos a explodirem o orçamento. Eu convido o leitor a considerar as implicações do fato.

Sempre que possível, encoraje os designers com quem trabalha para respeitarem a imperativa da consistência. Se seu encorajamento não tem efeito, certifique-se de colocar um id único no body de cada página do site, e curta o lado bom: não há dúvida que você tem sua vida.

Lição No. 6: Maiores tempos de produção são inevitáveis

Os fabricantes de navegadores tiveram cinco frenéticos anos para trabalharem num entendimento uniforme e razoável de renderização de tabelas, e esta tarefa foi facilitada pelo fato de que antes do Gecko e do KHTML serem lançados, a maioria das engines de renderização tinha muito em comum – o Mosaic gerou o Netscape mas também foi licenciado para a Microsoft .

O estado da tecnologia de renderização de CSS é comparável à de tabelas em 1998... então dê um tempo, e teste muito bem seus layouts enquanto isso.

A boa notícia é que o tempo necessário para testar e depurar seus layouts são pagos depois do lançamento com a redução do tempo de manutenção, extensões e revisões.

Lição No. 7: A ordem coerente e sensível do código é o melhor de tudo

Se você entrega um trabalho que pode ser lido corretamente quando os estilos são removidos, sua coerência vai te retribuir muitas vezes mais. Esta prática traz muitos benefícios, como:

• Um estilo único para impressão substitui páginas de "versão para impressão".
• Folhas de estilo são mais fáceis de documentar, normalizar e gerenciar.
• A interferência de códigos e scripts em templates diminui.
• A navegação pelo site com o teclado fica muito menos dolorosa.
• Quando o site é remodelado, não há necessidade de reordenar todo o conteúdo de novo.

Lição No. 8: Seletores com descendência são o início e o fim de regras de CSS genuinamente poderosas

Quando você começa a transição do layout baseado em tabelas para uma produção de acordo com os padrões, é comum não só enlouquecer com elementos contentores (nota: não consegui achar uma palavra melhor para "container"... se alguém souber, me ajude, rs) , mas também sair colocando classes e ids para todo lugar.

É claro, você geralmente não precisa. Por exemplo, imagine um elemento criado para conter os links de navegação. Um erro comum de iniciantes é construir tudo com divs, o que ofende os puristas porque fazer isso dificulta as coisas para usuários de leitores de tela.

Já que as divs não são a solução ideal, podemos usar listas não-ordenadas. Leitores de tela aceitam comandos para evitá-los. Portanto, um "bom" elemento de navegação é uma lista não-ordenada de links. Um desenvolvedor consciente pode colocar um id na lista para efeitos de posicionamento, e classes nos links, para que eles possam ser distinguidos de todos os outros links do documento.

No entanto, neste cenário, somente o id é necessário. O corte em questão pode ser feito com o uso de um seletor descendente:

#nav a {
color: red;
}

Em português, este seletor diz: "todos os links dentro de #nav devem ser vermelhos."

Aí vai um exemplo mais complicado:

#bodycopy blockquote.critical {
float: right;
width: 30%;
padding: .5em;
margin: .5em;
}

Os atributos nesta regra devem ser aplicados a blockquotes com a classe critical, mas que também estejam dentro de #bodycopy. Isto permite tanto que blockquotes limpos dentro de #bodycopy e blockquotes parecidos no #sidebar sejam estilizados diferentemente, e ainda minimizando o número de classes e ids a serem usados.

Assim sendo, seletores descendentes permitem que você reduza o número de classes e ids no código e possa prestar mais atenção no contexto do que seria possível sem estes seletores.

Quando usados em conjunto com imagens de fundo e propriedades de layout, os seletores descendentes tornam possíveis efeitos que as tabelas nem sonham em fazer.

Lição No. 9: No mundo real, os hacks de CSS levarão seu projeto para a linha de chegada

Sim, hacks de CSS são um pouco desrespeitosos quanto às intenções por trás da tecnologia. Sim, hacks introduzem a possibilidade de pesadelos quando surge uma mudança maior... como a que acontecerá quando o IE 7 for lançado. Sim, o assunto é uma expectativa esperando para acontecer.

Este escritor tem uma atitude clara sobre o assunto. Tendo a chance de escolher entre inventar desculpas para seu cliente do por quê alguma coisa parece estranha no seu navegador ou simplesmente corrigi-la, a segunda escolha atinge o objetivo com muito menos dor e tempo. Quando usados de maneira inteligente e com as devidas precauções, os hacks de CSS tornam a vida muito mais fácil!

Lição No. 10: Dar um jeito nos bugs de renderização é como jogar Whack-a-Mole

Com isso, quero dizer que quando um bug de um navegador é corrigido, ele geralmente resulta na exposição de outro bug em outro navegador (ou numa versão diferente do mesmo navegador). Quando isto acontece, prepare-se para voltar atrás e examinar toda sua regra... se não todo seu projeto.

A boa notícia é que geralmente há uma saída para esta situação aparentemente sem chances, sendo que a maioria pode ser encontrada com uma boa busca na web. Positioniseverything.net é uma referência valiosa nestes casos.

Lição No. 11: Quando você está mergulhado em problemas de layout com CSS, certifique-se da largura (width) e da altura (height) da água, flutue (float) sem se debater, e fique livre (clear) dos problemas

Quando você está trabalhando com layouts com colunas, surpresas inconvenientes são comuns. O melhor jeito de conseguir um layout com colunas esteticamente plausível e com uma ordem do código sensível é usar o atributo float. No entanto, para que isto funcione bem, todas as suas colunas devem ter larguras (width) definidas e, em alguns casos, alturas (height) definidas também. Sem esta largura e altura, o layout é renderizado de qualquer jeito.

Além disso, você pode estar ignorando a Lição 4 para criar o layout com sucesso. Porém, este é um dos compromissos que eu mencionei – um compromisso que deve ser feito somente depois que você tentou tudo que pôde para fazer de outro jeito.

Lição No. 12: Imagens de fundo fazem a diferença entre a decoração simples e a chamativa

Graças aos imprevistos do modelo de caixas (box model) do CSS, misturar dimensões fixas e proporcionais num layout – em outras palavras, tentar um layout líquido com muitas bordas – é certamente o caminho para o desastre (ou pelo menos, um considerável infortúnio). No entanto, você pode criar a ilusão desta mistura criando imagens de fundo bem compostas e referenciando-as corretamente na sua folha de estilos. Auto experimentação é recomendada, principalmente com relação ao comportamento das bordas.

Outra tarefa comum para a qual eu acredito que as imagens de fundo são apropriadas é a substituição de títulos com textos em forma de imagem. Apesar de controversa, a prática de combinar o background-position e o text-indent torna possível dar aos mecanismos de busca e aos leitores de tela o que eles precisam, e ainda manter a experiência visual de alta qualidade que a maioria dos designers tanto almeja.

Só para constar, os céticos devem saber que ainda estou par encontrar algum usuário de computador que navega pela web com o CSS habilitado e as imagens desabilitadas. Ainda que este cenário leve a um intrigante exercício intelectual, estou bem confiante de que isto tem pouca relação com a maneira com que as pessoas geralmente navegam pela web no mundo real.

Para Concluir

O barulho em torno da Web 2.0, CSS, e milhares de outros assuntos de tecnologia de ponta podem se tornar um chato zunido para aqueles menos preparados para as mudanças na indústria por causa de hábitos de trabalho adotados com boa fé anos antes. Eu espero que a experiência que estou compartilhando possa ajudar alguns de vocês a encontrar o caminho de volta para o topo da pirâmide – que é onde a web precisa de você.

-----

Este artigo foi publicado originalmente na edição 224 da A List Apart e pode ser acessado aqui.

Traduzido por Luciano Rodrigues.