Samuel Corradi

Blog

CSS - Minha metodologia

samuel corradi, programacao, internet, html, css, tableless, padroes web, metodologia, desenvolvimento

Ainda me lembro do dia em que larguei as tabelas para me concentrar nas DIVs. Agradeço um amigo de graduação, Rafael Ramos, por ter aberto minha mente. Mudar minha forma de construir o layout dos sites foi quase tão doloroso como um parto.

Acabei me convencendo (por questões que hoje soam como óbvias) que aquilo era muito melhor, porém, ainda assim, tinha certa dificuldade por pura falta de metodologia de trabalho. Bastava o site crescer demais para o CSS virar uma dor de cabeça. Como fazer para gerenciar aquele monte de linhas de cogido? Como lembrar onde exatamente estava 'aquela' declaração? Faz meses que não mexo nesse site, já não lembro mais o que representa o que. Vou ter que ficar consultando o xHTML toda hora?

De tanto a cabeça “bater pino”, hoje me encontro mais tranqüilo a respeito das CSS pois busquei desenvolver uma metodologia de trabalho que resolvesse meus problemas. E ela funciona muito bem para mim. E justamente por funcionar muito bem para MIM, venho através desse pequeno artigo tentar passar as soluções que aprendi para vocês. Espero que gostem.

Sei que mudar de metodologia não é fácil. Pode ser tão doloroso quanto um parto, porém as vezes é só uma questão de abrir a mente... Antes que eu comece a escrever a introdução toda de novo, vamos lá. Separei o texto em tópicos. Cada tópico representa uma regra que criei para mim na hora de trabalhar com CSS e o conjunto dessas regras formam minha metodologia.

Modularidade – Separe seu arquivo .css em outros arquivos .css menores.

Nomenclatura dos arquivos .CSS - Ao modularizar seu arquivo CSS, não crie arquivos com nomes como 'topo.css' ou 'rodape.css'. A razão simples para isso é que se um dia o layout do site for mudado para algo diferente, o texto que estava no rodapé pode ir para o topo, o menu do topo pode ir para baixo, etc. Então sua nomenclatura perderá o sentido e começará a confundir a partir daí.

O que eu faço é dividir os arquivos CSS pelos tipos de páginas que meu site tem. Ou seja, se meu site for totalmente igual, em todos links, coloco tudo em 1 único arquivo chamado 'geral.css'. Já que o site é todo igual, provavelmente ele não terá tantos elementos diferentes que justifique modularizar o CSS.

E caso meu site seja todo igual, somente com a página inicial diferente (como em http://www.dibetes.med.br)? Nesse caso crio o 'geral.css' apenas com os elementos que repetem, tanto na página inicial quanto nas internas (como tipo de fonte, cor do link, aparencia de inputs, etc.), e crio também arquivos 'inicial.css' e 'interno.css' cada um com suas respectivas definições. Cada arquivo será carregado no cabeçalho apenas no tipo de página correspondente.

Faço isso para cada tipo de link com aparência diferente que meu site tiver. Assim, caso o site mude o layout, ele não mudará sua estrutura e a nomenclatura continuará relevante.

Velocidade e Economia – Criar arquivos modulares dessa forma aceleram o carregamento do site pois a requisição feita será apenas dos arquivos que realmente são necessários para a página que está sendo carregada.

Sem falar na diminuição do consumo de banda. Imaginem se meu site tiver milhares de acessos por hora, e a cada exibição de página ter que carregar um arquivo .css com definições que não são utilizados nessa página. Nos tempos de hoje – 11 de agosto de 2008 – que está na moda navegar via 3G onde cada mega tem preço de ouro, arquivos CSS modulares representam economia direta para operadoras e usuários.

Nomenclatura das IDs – Essa regra é a que mais me ajuda: Algo que pode confundir na hora de trabalhar com CSS é o fato de uma tag 'P' com id '#telaVerde' ser diferente de uma 'DIV' com o id '#telaVerde'.

Na hora de escrever o nome das IDs no seu arquivo CSS, se você colocar apenas #tela_verde, além de estar errado pelo fato do ID ter que ser único, a formatação atingirá tando a tag 'P' como a 'ID'. Imagem fazer isso num arquivo CSS com 500 linhas? Chegará uma hora que você não saberá mais o que referencia o que. Entenderam?.

Para acabar com isso, botei na minha cabeça que todo CSS que for montar, as IDs levam também o nome da TAG a que referenciam. Assim, minhas IDs 'Tela Verde' seriam declaradas como '#div_telaVerde' e '#div_telaVerde p'.

Assim, quando abro um arquivo CSS que não mexo a tempos e encontro a ID '#ul_menu', sei que aquilo se referencia a lista de links do meu site, o seu Menu. Caso eu tivesse colocado apenas '#menu' talvez isso não significaria mais nada para mim, eu já teria esquecido, e teria que consultar o xHTML perdendo meu tempo. Se encontro #div_menu ul já entendo que no xHTML coloquei a lista de links encapsulada dentro de uma div, e por ai vai... Lendo o CSS eu já leio o xHTML. Entenderam?

Ai vocês me perguntam: - “Pô Samuel Corradi, por que você não declara no arquivo CSS simplesmente 'ul#menu'?”. Ai eu lhe respondo: - ”É por que isso não define tanto os nomes. Eu posso muito bem esquecer de colocar o 'ul' antes e me dar mal”.

Além do mais, a própria tag no xHTML fica com o nome 'ul_menu'. Isso já me facilita também na hora de programar um JavaScript ou o tratamento de um formulário submetido via PHP. Trato tudo como uma coisa só e não tenho um nome diferente para cada coisa em cada linguagem.

Declarando as Classes – As classes eu declaro sempre dentro do arquivo 'geral.css'. Tá certo que posso não usar nenhuma classe em determinada página e carregar as classes assim mesmo. Mas geralmente, a quantidade de classes é muito menor, e não irá te atrapalhar carrega-las a cada nova exibição de página.

Use classes com restrição – Particularmente evito usar classes como '.esquerda', '.direita' ou '.floatLeft'. Seguindo o exemplo do nome dado aos arquivos .css na hora de modulariza-los, num novo layout o que estava alinhado a esquerda pode ficar na direita. O que era 'float: left' pode virar 'float: right'. Isso fatalmente geraria confusão e até mesmo lixo no xHTML, caso a classe não seja declarada em um novo layout criado a partir de um outro arquivo .css.

Por tanto, para mim, atributos como left, right e float devem ser especificados dentro das IDs dos elementos xHTML. Caso o título do seu site mude de formato em um outro layout, a entidade '#h1_nomeSite', que sofrerá alteração, não terá pseudo classe '.positionAbsolute'.

E lembre-se: IDs são únicos e as Classes servem para englobar os vários elementos de uma mesma família.

Nomenclatura das Classes - Ao contrário das Ids, nas classes eu não especifico a tag. Classes são por sí só muito generalistas para que eu possa fazer isso. Então, ao invés de declarar como '.div_quadrado' uma classe que define largura e altura de determinados elementos DIV, declaro apenas como '.quadrado'.

Se por qualquer motivo eu precisar usar o mesmo nome de classe em dois tipos de elementos diferentes (como DIV e A) resolvo o conflito criando os seletores com o nome das tags antes do ponto. Ficando 'div.quadrado' para especificar DIVs e 'a.quadrado' para especifica os links. Isso caso a tag A não esteja dentro do DIV. Se estiver, basta usar 'div.quadrado a' para por estilos no link.

Declare tudo na ordem – Dentro dos meus documentos de estilo declaro tudo na mesma ordem em que eles aparecem dentro do xHTML. Ou seja, começo declarando as propriedades do body, depois dos elementos ul, p, a, form, #div_menu, #div_conteudo, #div_rodape, e por ai vai. Isso facilita na hora de encontrar alguma informação.

/* Comente, comente, comente */ - Eu comento tudo o que não for óbvio demais para mim. Se estiver trabalhando em grupo, comento tudo. E sempre utilizo comentários em caixa alta para marcar dentro do CSS onde começa as partes do layout. Ou seja, escrevo /* MENU PRINCIPAL */ antes de começar as declarações do menu principal do site, /* CONTEUDO */ antes das declarações de conteúdo, etc.

É isso pessoal! Desenvolvendo uma metodologia para trabalhar com CSS economizo tempo na manutenção dos meus sites e, por que não dizer, durante a construção dos mesmos. Posso até ter esquecido de falar alguma coisa. Nesse caso, nada melhor que observar códigos para aprender coisas novas. Deixo a vocês o convite para dar uma olhadinha no arquivo de estilo desse mesmo site.

Obrigado!

Incluir comentário






0 mensagens enviadas

Últimos posts:

Destaques:

PHP Coupé - Desenvolvimento rápido e reaproveitável vForm - Validador universal de formulários

Programming and design by Samuel Corradi