Escrever e manter arquivos de formatação css só parece simples no início. Conforme o projeto vai crescendo, novas solicitações de alterações são sugeridas pelo cliente. O tempo sempre exíguo muitas vezes leva a soluções mais rápidas mas, quase sempre conceitualmente erradas. O que era para ser solução, a possibilidade de determinar em um único local os atributos de um objeto html, torna-se um problema pelo seu efeito em cascata. Se este cenário já é caótico, imagine trabalhar e manter estes arquivos em um time de desenvolvimento, com profissionais com experiências e estilos diversos. É preciso definir um padrão e regras claras e simples de desenvolvimento.

Modularização

Uma abordagem possível é dividir os arquivos css em módulos. Por exemplo, agrupar as definições de fontes, cor, posicionamento (layout), formulários e navegação (menus) em arquivos diversos. Depois, pode-se definir um arquivo index.css e colocar todos juntos utilizado o elemento @import url(‘fonts.css’), por exemplo.

Esta é uma boa técnica, ajuda bastante na manutenção do código. Porém, exige um grau alto de organização e gera um trabalho inicial extra, pois algumas, senão todas as classes, ids e tags terão que ser escritas várias vezes em arquivos diversos.

Ex:

main.css

h1{
    font-size: 10px;
    color: black;
    margin: 10px 0;
}

No método modular:

font.css

h1{
    font-size: 10px;
}

color.css

h1{
    color: black;
}

layout.css

h1{
    margin: 10px 0;
}

A vantagem é óbvia: para mudar a cor de uma tag, basta abrir o arquivo color.css. A manutenibilidade aumenta em razão proporcional a qualidade do esforço inicial. Recomendável somente para projetos que sofrerão diversas alterações ou que posteriormente necessitarão de manutenção. Além do trabalho inicial maior, outra desvantagem desta técnica é a quantidade multiplicada de requisições http. Em sites com muitos acessos que precisem economizar cada bit, esta técnica pode não ser a mais adequada. Porém há uma vantagem adicional: a possibilidade de usar alguns arquivos em outros projetos, aproveitando definições de classes e ids. E isto leva a idéia da definição de um padrão, de um framework em css, como mostra este artigo.

Código auto-documentado

A idéia é usar classes e ids com nomes semânticos, ou seja, que tenham significado. Além de ser uma prática recomendável na edição de documentos html bem escritos, também é uma técnica de SEO (search engine optimization) que melhora a classificação das páginas nos sistemas de busca. Definir o caminho absoluto de um objeto protege o restante das aplicações de heranças indesejáveis.

Por exemplo, considere a seguinte estrutura.

    <div id="header">
        <ul id="menu">>
            <li><p>[...]</p></li>
                [...]
            <li><p>[...]</p></li>
        </ul>
    </div>
    <div id="content">
        <p>[...]</p>
        </div>
    <div id="footer">
        <p>[...]</p>
    </div>>

div#header é mais legível que #header, pois neste caso fica claro que a regra css estará associada somente a uma div cujo id é “header”. Se tivessemos definido a regra somente como #header, ela poderia ser usada por qualquer elemento html. Por isso, div#header ul#menu p{color:red} vai aplicar a cor vermelha somente na tag p que estiver dentro da ul#menu, que por sua vez está dentro da div#header, e não nas outras tags que aparecem em content e footer. Desse modo, além de conseguir escrever um código mais legível para a equipe, adicionalmente evitamos a propagação em cascata da propriedade para outras tags da página (técnica da caixa-de-areia).

Do geral para o específico

Mas a beleza e poder do css está justamente na propagação em cascata, na herança. Ou seja, é a possibilidade de indicar em um único lugar atributos que afetarão todo sistema. Tendo isto em mente, acredito que uma boa prática é partir do geral para o o específico. Definir, logo no início do arquivo, propriedades que serão usadas em toda aplicação, notadamente definições de fontes e cores de letras atribuídas a elementos básicos como h1, h2, h3 até h6, p, span, td, tr, hr, etc.

Um arquivo css para cada página? Não!

O maior problema de definir um css para cada página é o aumento da quantidade de requisições ao servidor e diminuição da manutenibilidade do sistema devido a inevitável redundância que fatalmente ocorrerá. Além disso, é mais fácil dar manutenção em um único arquivo do que em dezenas deles.

Comentários

Se usarmos comentários aliados a técnica da caixa-de-areia não precisaremos lançar mão de vários arquivos css:

/* cadastro de clientes : begin */
div.cadastroDeClientes{
    padding: 10px 0 0 5px;
    margin: 0;
    background: #ccc;
}
    /* box begin */
    div.cadatroDeClientes div {
    padding: 0 5px;
    margin: 0;
    }
        div.cadastroDeClientes div p{
            font-size: 12px;
        }
    /* box end */
/* cadastro de clientes : end */

O código comentado ajuda no consumo posterior do css por outros membros da equipe. A identação, simulando a hierarquia das tags html, aumenta a legibilidade do código. Tudo isto junto evita a redefinição de propriedades em locais impróprios, como no fim do arquivo css, que se por um lado sobrescrevem atributos anteriormente declarados, geram efeitos e defeitos imprevisíveis. A utilização destas técnicas darão ao desenvolvedor pistas concretas e legíveis do local exato onde deve proceder com as alterações sem que elas propaguem incontrolavelmente por toda a aplicação. Adicionalmente, sobrescrever, dentro de cada definição, elementos de layout (margin, padding, position, display, float, etc) evita problemas de layout ocasionados por herança.

Ressetando o CSS

Outra sugestão é usar sempre um arquivo para neutralizar propriedades indesejáveis de layout definidas como padrão e de maneira não padronizada pelos diversos browsers.

Nomenclatura padronizada

Nem sempre conseguimos dar bons nomes às classes e ids do css, nem sempre há tempo hábil ou inspiração para isto. Porém, estas definições são fundamentais para a legibilidade e posterior manutenção e desenvolvimento conjunto do código. Parte do problema pode ser resolvido definindo um framework, já que provavelmente poucas coisas novas surgirão no desenvolvimento de vários projetos e boa parte do código poderá ser re-utilizado.

Revisão do código

Equipes estáticas são teóricas, não existem no mundo real. Na verdade, parece ser bastante comum a entrada e saída de novos membros no decorrer dos projetos. Membros novos, sem a devida orientação, tenderão a cometer falhas. O código comentado e devidamente organizado minimizará este problema, mas não o solucionará completamente. Níveis diversos de conhecimento e experiência, aliados a urgência podem também conduzir a defeitos e soluções funestas. Criar um fluxo de trabalho onde o código seja continuamente revisado pelos membros da equipe pode contribuir positivamente para minimizar defeitos.

Conclusão

Longe de almejar uma resposta definitiva, o objetivo deste texto é apresentar técnicas para a elaboração de guidelines simples, fáceis e úteis, tendo como foco a redução de problemas de layout gerados por efeitos de propagação da herança do CSS, do comportamento diferenciado dos diversos browsers e da conjunção destas variáveis com outras que surgem ao realizar este trabalho coletivamente.

Referências: