Tableless.com.br


por Diego Eis 12 November 2008

Modulando o CSS

Quando trabalhamos com Padrões Web, trabalhamos com três camadas principais: Informação, formatação e comportamento. A informação seria controlada pelo HTML. Ele exibiria a informação na tela com significado. O CSS manipularia a formatação desses elementos para que ficassem belos e controlaria suas posições na tela. E o Javascript / Ajax cuidaria do comportamento destes elementos. Vamos nos focar um [...]

Quando trabalhamos com Padrões Web, trabalhamos com três camadas principais: Informação, formatação e comportamento.
A informação seria controlada pelo HTML. Ele exibiria a informação na tela com significado.
O CSS manipularia a formatação desses elementos para que ficassem belos e controlaria suas posições na tela.
E o Javascript / Ajax cuidaria do comportamento destes elementos.

Vamos nos focar um bocado na segunda camada, o CSS. O CSS é uma linguagem de formatação é extremamente flexível.
O CSS, por ser uma linguagem com uma sintaxe fácil, muita gente coloca a mão durante o processo de desenvolvimento. E como seu código só tende a crescer, temos que ter um cuidado especial na organização dos arquivos.

Há várias maneiras de organizar os arquivos CSS de um site. Há sites que não precisarão de vários arquivos, bastando apenas um. Para estes devemos apenas ter cuidado com o código. Deixando-o simples e legível. Sempre tomando cuidado com a quantidade de linhas e código desnecessário. A estrutura seria mais ou menos essa:

Grandes portais e sites com uma visitação extrema, podem querer otimizar esse código. Isso é considerável apenas para estas excessões. O preço da banda é alto e qualquer 1Kb que economizarem será um caminhão de dinheiro que economizarão. Para sites pequenos, e até mesmo alguns sites de médio porte, na minha opinião, não é necessário haver uma “otimização de código“.

Se você perceber que as páginas são muito diferentes uma das outras e que o código está aumentando descontroladamente, é muito aconselhável você dividir o código CSS para cada padrão de página. Isso ajuda a controlar o tamanho do código e permite que você modifique uma parte do site sem interferir em outras páginas.

Essa opção é ótima para um site que tenha várias seções e cada seção tem um design diferente. Há um inconveniente: o código dentro do HEAD pode ficar enorme com tantas tags de LINK importando os arquivos de formatação. Para mudar isso, você pode fazer duas coisas: a primeira é fazer um arquivo CSS que importe todos os outros arquivos e linkar no HEAD apenas este arquivo.

Com essa primeira opção, o browser ainda carregará todos os arquivos CSS de uma vez. Pode ser que o carregamento fique pesado.
Por isso, há uma segunda opção que é conversar com seu programador para que ele faça uma mágica onde o site carregue apenas o arquivo CSS relativo àquela página. Quando visitamos a página interna, não é necessário carregar o arquivo CSS da HOME, por exemplo. Essa mágica previniria isso.

Outras pessoas preferem separar todo o código CSS em dois arquivos. Um arquivo conterá apenas informações de cor e fonte. E no outro arquivo haverá apenas informações sobre a estrutura do site: largura, altura, tamanho, margin, padding, position, float, etc.
Essa maneira é ótima para caso você quiser dar ao usuário opções de cores. O programador pode fazer um javascript maneiro que permita o usuário clicar e mudar a cor. O designer prepara vários CSS com regras de cores diferentes. A estrutura pode continuar a mesma, mas a paleta de cores muda. A mesma coisa pode-se fazer com a estrutura. A cor continua, mas a estrutura pode ser alterada de acordo com a opção do usuário.

Essas seriam as formas mais comuns de organizar seu CSS. Perca um bocado de tempo planejando essa estratégia. Se o site é muito grande, esse tipo de planejamento prévio pode salvar o projeto. Vale a pena a equipe definir padrões desenvolvimento. O CSS é um dos fatores definitivos para manutenção, velocidade e compatibilidade do site. Um CSS fora de controle é um pesadelo que você não quer ter.

21 Opiniões Quero Opinar
  1. Marcus VBP says:

    Boa Diego.

    A algum tempo eu modularizo meu CSS, apesar de fazer de uma maneira ligeiramente diferente da que você apresenta aqui. Mas eu já estava pensando em modularizar da desta forma aí.

    Tem este problema da lerdeza. Um cliente uma vez reclamou da lerdeza, e analisando a página, percebi que a página ficava lenta porque havia muitos arquivos CSS linkados. Uni o CSS em um único arquivo, e a página ganhou 1 ou 2 segundos (não lembro exatamente) no carregamento!

  2. [...] superará mais de 1000, 2000, 3000, 4000 linhas. Dá para evitar? Claro que dá! Pense simples. Module os arquivos. Faça um planejamento. Mas NUNCA faça com que um CSS escrito [...]

  3. Raphael PH says:

    Sepre que pego portais, eu separo meu código CSS, faço um geral e puxo os outros arquivos CSSs.

    Isso ajuda muito na manutenção.

    Dessa maneira como é possível puxar somente os CSS’s que a página necessita??

    Ex: tenho uma Home, contato e conteúdo mas a home não precisa puxar os css’s do conteúdo e contato.

  4. Ramon Lima says:

    Nem sempre a melhor abordagem é CSS e tableless: http://giveupandusetables.com/

  5. Assim, Concordo com o Diego…tables for what? hauahuahauhauahauhah

    Nunca modularizei meu css, e por isso já tive vários problemas de css fora de controle. Comecei a bolar um padrão para isso e vou começar por em pratica no meu próximo projeto. Organizar o código é vital para a saúde de quem trabalha com ele

  6. Gabriel Moretti says:

    [...]Por isso, há uma segunda opção que é conversar com seu programador para que ele faça uma mágica onde o site carregue apenas o arquivo CSS relativo àquela página. Quando visitamos a página interna, não é necessário carregar o arquivo CSS da HOME, por exemplo. Essa mágica previniria isso.[...]
    [quote]Quote funfa aqui?[/quote]

    Não entendi muito bem, essa magica carregaria apenas alguns dos css contido no css geral, que contem todos os imports?

  7. Dalton says:

    No. [2]

  8. Eu, sempre que posso, quebro o CSS em vários arquivos.
    O único inconveniente mesmo com essa técnica é que quanto mais requests são feitos, mais lento fica o carregamento da página (vi um post certa vez que falava disso, para evitar ter um número excessivo de includes e afins uma vez que o browser “perde” um bom tempo para abrir um request, processá-lo e depois fechar).

  9. Willian says:

    eu costumo dividir os arquivos em seções quando o site é grande, e existem muitos templates diferentes a cada seção.

    estou em um job que separei um arquivo layout.css e um para cada cor institucional do site (6 cores), porque o usuário vai ter a livre escolha da cor que ele quiser no site.

    já quando o site não tem muitas páginas, templates diferentes faço um css único separando as seções por comentário (o que é essencial em qualquer um dos casos).

    é isso ae, abraço

  10. Diego, eu costumo modularizar o css. Mas geralmente, via php ou outra linguagem server-side, junto tudo (todos os módulos necessários) num arquivo só com includes, e o html acaba chamando um arquivo só. Aparentemente, apresenta ganho no desempenho. O que acha?

  11. Eu uso o mesmo metodo que aprendi no trabalho atual aqui em Londres.

    Crio dois CSS, um default e um print, o primeiro com algumas classes e definicoes de alguns elementos de forma geral e que qualquer navegador, mesmo antigos entendam.

    Ambas sao carregadas atraves da tag link

    Entao crio algo assim:

    @import ‘/site/assets/css/w3c_hp.css?version=4′;
    @import ‘/site/assets/css/w3c.css’;

    um para a pagina onde estou e outro geral.

  12. A modularização é MUITO importante!

    Esse tipo de coisa só se aprende quando realmente precisa… Com o passar do tempo a necessidade de organização faz com que você tenha que modularizar seus códigos.

    O interessante é que, dependendo do tamanho, o recomendado é dividir em vários arquivos mesmo.

    É fato que separo meus CSSs dependendo das mídias, caso necessário. Mas em grandes portais, geralmente faço um “CSS geral”, que engloba todas as definições de classes e elementos a serem utilizados em todo o site.

    Em seguida faço o CSS das páginas internas, aí sim com as regras bem específicas, mas abusando de comentários para separar tudo certinho, não separando em milhões de arquivos distintos heheh

    E, claro, há um CSS que serve como índice dos outros arquivos, indicando o que cada CSS engloba, e por aí vai… Acho essa parte da organização bem interessante e cada um acaba inventando o jeito que mais se adequa a suas necessidades.

  13. Com relação a perda de performance com o comando @import, será que nesse caso (sites de grande porte) isso não impactaria?

    Seria uma melhor alternativa usar um css compactado e único, reduzindo assim as requisições http, e melhorando a performance e velocidade do site?

    Estou estudando sobre isso, e implementando em um site que estou finalizando o desenvolvimento http://www.cfsolucoes.com.br e gostaria de comentários e opiniões sobre qual seria a melhor técnica.

  14. [...] Modulando o CSS » Tableless.com.br - CSS e Práticas com Padrões Web (tags: http://www.tableless.com.br 2008 mes10 dia15 CSS modularização blog_post) [...]

  15. Rodrigo says:

    Faço como o Jason. Tenho um css “main” e o resto é feito para cada módulo, então tenho um php que pega todos os CSSs - main + módulo - e junta num único arquivo, assim sirvo um único CSS e gzipado.

  16. Sergio Gumer says:

    Seguindo o caro profissional Diego Eis.
    Chuck Norris odeia tabelas pra fazer layout na web.
    ….e Tim Berners Lee também
    hahahaha

  17. Veho fazendo isso há algum tempo! Tem funcionado bem! Belo artigo! ;)

  18. Falei sobre esse tema recentemente em meu site.
    Acredito que a metodologia pode ser expandida além da modularidade do arquivo para facilitar a vida do programador.

    http://www.samuelcorradi.com.br/pagina38.html

  19. RicoSouza says:

    Olá pessoal, vou contar meu caso pra vocês.

    Todos os projetos que desenvolvemos seguem exatamente o mesmo padrão para todas as telas. Nesse sentido, organizamos da seguinte forma:

    layout.css - para a estrutura da página, como cabeçalho, menu, corpo, barra de ferramentas, áreas de mensagens e rodapé.

    tabela.css - para as diferentes tabelas (geralmente 3, no máximo)

    formulário.css - para os elementos de formulario

    links.css - para os diferentes links

    menu.css - para os menus local, global e contextual

    nav-abas.css - para o ficheiro ou navegação por abas (geralmente usamos dois tipos)

    impressao.css - para as definições de impressão das páginas.

    Estrutura de pastas dos projetos:

    /css/
    /img/
    /js/
    /html/
    /html/caso-de-uso/
    /html/etc/

    Caso exista a necessidade de criar algum estilo específico, este deverá ser inserido na pasta do caso de uso específico. Se for algo genérico, deverá ser inserido em uma das folhas de estilos padrão (já existentes).

    Obs.:

    1. As chamadas das folhas de estilo não aumentaram o tempo de carregamento das páginas.

    2. 1150 é o número total de linhas do código CSS. Com a separação, teve arquivo que ficou com 280 linhas, outros com 150, outros com 50 e por ai vai.

    3. Todos os projetos rodam tranquilamente no Firefox, Opera, IE6 e 7 e Safari para windows.

    4. Estamos revisando e buscando melhorar a estrutura dos códigos.

    5. Os ‘hacks’ se reduziram a pequenos ajustes de margins e paddings. O pior já passou!

    6. Escrevemos em ordem alfabética (considerem a identação), ex:

    corpo {
    background
    border
    clear
    color
    float
    font
    margin
    padding
    width

    }

    7. usamos o css reset:

    * {
    border
    margin
    padding
    }

    Já melhoramos bastante a organização dos projetos e o que é melhor: usamos o mesmo código para atender projetos de clientes diferentes com a nomenclatura padrão, ex:
    resolucao {}
    topo {}
    menu-global {}
    menu-local {}
    corpo {}
    area-mensagens {}
    barra-ferramentas {}
    caminho-navegacao {}
    dados-login {}
    table-grid {}
    table-detalhar {}
    form-text {}
    form-select {}
    form-textarea {}
    form-barra-botoes
    link-paginacao {}
    link-conteudo {}
    rodape {}

    e por ai vai… é muito bacana padronizar. reutilizamos praticamente tudo.

    Aquele abraço.

  20. Renan says:

    KKKKKKKK, morri de rir com o site que o Ramon colocou (http://giveupandusetables.com/) e depois a resposta do diego: http://www.shouldiusetablesforlayout.com/ KKKK
    Não acredito que tem gente quem mantem um dominio so pra isso!! Mas valeu a diverssão…

    abraços..

Deixe sua opinião

Mais populares

Categorias
Histórico
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
Recomendamos
Nossos serviços

Reviews de Extensions

Quem trabalha com Firefox sabe como as extensões podem mudar a vida de um desenvolvedor. Nós separamos algumas extensões e sugerimos para você. Confira.

Leia mais

Sobre Wordpress

O desenvolvimento com wordpress vem crescendo e sua plataforma está ficando mais robusta a cada dia. Por isso preparamos alguns artigos e tutoriais sobre desenvolvimento e implemetação de Wordpress em sites.

Leia mais

Sobre
SEO

Hoje não é sorte. Colocar um site em uma boa colocação no Google não é fácil e muitas vezes pode ser uma dor de cabeça sem tamanho. Por isso, manter um código organizado e simples é um bom começo. Separamos algumas dicas para que você consiga otimizar seu código e fazer algumas modificações nos seus sites para que eles não fiquem atrasados.

Leia mais

Tutoriais na Prática

Nós falamos muito sobre XHTML e CSS. Então, nada mais justo que ter um lugar onde você consiga aprender melhor as técnicas e metodologias de desenvolvimento com CSS e XHTML.

Leia mais

Tableless

2003 - 2009, tableless.com.br
Quase todos os direitos reservados.
Creative Commons License.