Busca

Boas práticas de Desenvolvimento com Padrões Web


Modulando o CSS

As vezes não é inteligente fazer o código CSS todo em apenas um arquivo CSS. É aí que entra a modularização do CSS.

12/11/2008 por Diego Eis
30 Comentários

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.

30 Comentários

Sua opinião:

Vamos elevar o nível de discussão. Exponha sua opinião, sua crítica.



RSS dos comentários deste post
URL para Trackback

30 Comentários

Marcus VBP 12/11/2008 às 07:37

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!

Não “otimize” seu código » Tableless.com.br - CSS e Práticas com Padrões Web 12/11/2008 às 09:15

[...] 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 [...]

Raphael PH 12/11/2008 às 09:43

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.

Ramon Lima 12/11/2008 às 09:57

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

Rhamsés Soares 12/11/2008 às 12:17

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

Gabriel Moretti 12/11/2008 às 13:30

[...]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?

Chris Benseler 12/11/2008 às 16:47

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).

Willian 12/11/2008 às 20:28

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

Jason Divless 13/11/2008 às 13:34

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?

Rodrigo Fante 13/11/2008 às 15:25

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.

Carlos Eduardo 13/11/2008 às 23:29

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.

Pablo Augusto 15/11/2008 às 11:47

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.

rascunho » Blog Archive » links for 2008-11-15 15/11/2008 às 18:04

[...] 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) [...]

Rodrigo 20/11/2008 às 15:14

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.

Sergio Gumer 25/11/2008 às 12:22

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

Pablo Almeida 01/12/2008 às 11:44

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

Samuel Corradi 01/12/2008 às 12:12

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

RicoSouza 01/12/2008 às 17:08

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.

Renan 28/12/2008 às 23:39

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..

leocello 14/01/2009 às 17:24

Normalmente, quando faço estilos iguais para todas as páginas, crio uma folha de estilos apenas com as TAGs, e chamando outras duas, uma com as classes e outra com os IDs.
Quando tenho páginas com estilos diferentes, opto por fazer com que se carregue apenas a determinada folha de estilos que necessito, e essa escolha de arquivo é feita diretamente pela programação, com a “mágica”, segundo o Diego.

Sergio Almeida 26/02/2009 às 16:39

Legal o @RicoSouza compartilhar essas informações de “Gestão de CSS” :o ) Bem interessante, uma boa referência. E, claro, um excelente post e mais fatos de Chuck Norris – pq não? hehehe!

Joel 23/03/2009 às 18:32

Realmente muito bom! Modular o CSS era uma coisa que eu pensava em fazer a muito tempo, mas não encontrei um padrão (também não gastei tempo procurando, heheheh).

Gabriel Silva 02/09/2009 às 10:50

Não gosto de modular o css. Uma vez carregado, ele fica na cache do browser e ele não precisa baixar o arquivo de novo.

É claro que a otimização desse arquivo tem que ser boa. ( eu uso o dreamweaver e discordo quando dizem pra não otimizar o código css. Pra isso deus inventou o apply source formatting ;) )

É só minha opinião.

Tioni Oliv 02/09/2009 às 10:59

Não uso nenhum método idêntico aos apresentados para modularização, mas trabalho com reset, grid e style, 3 arquivos css e outros plugins básicos do jQuery em um pacote (quase um framework) que e chamo de “Genesi”.

LuizCarvalho 02/09/2009 às 11:32

Otimo o post, Parabéns.

Tbm gostei do comentário do RicoSousa(http://www.tableless.com.br/modulando-o-css#comment-133155)

E morri de rir com o site que o Ramon colocou (http://giveupandusetables.com/) e depois a resposta do diego: http://www.shouldiusetablesforlayout.com/ KKKK [2]

E Detalhe Olha o que você encontra no Source Code do segundo site:

“Fact: Chuck Norris hates layout tables!”

Abs

Não “otimize” seu código « GoDesigneZ® – Douglas L. Figueiredo 16/09/2009 às 16:36

[...] 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 [...]

ueb3.com.br :: A web como ela é! » Não “otimize” seu código 16/09/2009 às 16:37

[...] 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 [...]