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.
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 maisO 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 maisHoje 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 maisNó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
2003 - 2009, tableless.com.br
Quase todos os direitos reservados.
.
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!
[...] 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 [...]
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.
Nem sempre a melhor abordagem é CSS e tableless: http://giveupandusetables.com/
Ramon, a resposta está aqui:
http://www.shouldiusetablesforlayout.com/
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
[...]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?
No. [2]
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).
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
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?
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.
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.
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.
[...] 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) [...]
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.
Seguindo o caro profissional Diego Eis.
Chuck Norris odeia tabelas pra fazer layout na web.
….e Tim Berners Lee também
hahahaha
Veho fazendo isso há algum tempo! Tem funcionado bem! Belo artigo!
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
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.
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..