Uma outra visão sobre CSS Frameworks
mar 19 2008
CSS Design css frameworks 19 comentários
Existem várias formas de produzir com CSS frameworks. A visão que irei mostrar aqui consiste em mais uma forma de organizar e otimizar os estilos de um site, bem diferente do conceito de reutilização de código para outros sites futuros. É uma visão próxima do artigo original em A List Apart.
Importante! Esta é apenas uma sugestão de trabalho com CSS e nenhum padrão de desenvolvimento. Cada empresa ou desenvolvedor deve procurar a sua própria forma de construir seu código.
Costumo dividir meus arquivos CSS em dois tipos de blocos de tags, identificadores e classes: um por mídia e outro por tipo de conteúdo.
Uma introdução
Mas antes mesmo de começar a trabalhar o estilo, que tal um comentário sobre que projeto que estamos trabalhando? É a única chance que um desenvolvedor de interface tem que ter algum controle textual sobre seu trabalho.
/* Theme Name: Layout em curvas insanas Theme URI: http://teste.sydi.net Description: Desenvolvimento da nova versão do site Version: 0.9 Author: Simone Villas Boas Author URI: http://sydi.net/ */
É uma idéia descaradamente roubada do WordPress – que deve ter sido pega em outro lugar também – e que adotamos em todos os projetos.
Dividindo por mídia
Não há novidade alguma aqui:
@media screen{
/* minhas definições para visualização num
monitor comum de computador ou notebook */
}
@media print{
/* minhas definições para impressão do arquivo */
}
@media screen,print{
/* minhas definições para ambos */
}
Como ando obcecada em diminuir os requests HTTP, não uso o outro método de separar os tipos de mídias em arquivos diferentes. Esta é uma escolha do desenvolvedor de interface!
<link rel="stylesheet" type="text/css" media="all" href="/css/principal.css" /> <link rel="stylesheet" type="text/css" media="screen" href="/css/monitor.css" /> <link rel="stylesheet" type="text/css" media="print" href="/css/imprimir.css" />
Dividindo por tipo de conteúdo
Esta é uma lista que fui testando e aprimorando nos últimos projetos. Definindo dentro de cada mídia:
- Reset, onde limpo todas as definições de estilo padrão do navegador;
- Basic, onde estão as definições genéricas de tags e classes;
- Grid, onde desenvolvo estrutura da página;
- Format, onde configuro cores, fundos, tipologia, por área de layout;
- Pages, onde estão as definições especiais de cada seção do site;
- Hacks, onde junto todos os códigos pré-construídos de CSS como image replacements, clear-fix e outras definições genéricas.
Agora cada item em detalhes e exemplos:
Preferi manter os títulos em inglês para manter algum distanciamento. No entanto, como todo o resto neste artigo, esta é mais uma convenção.
-
Reset
Uso a opção testada pelo Eric Meyer com algumas pequenas revisões particulares:
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td { margin: 0; padding: 0; border: 0; outline: 0 !important; font-weight: normal; font-style: normal; font-size: 100%; font-family: inherit; vertical-align: baseline } body { line-height: 1; background: #fff; color: #000 } ol, ul { list-style: none } blockquote, q { quotes: none } ins { text-decoration: none } del { text-decoration: line-through } table { border-collapse: collapse; border-spacing: 0 } address{ font-style: normal } -
Basic
Definição dos estilos das tags, que é a parte mais genérica da folha de estilo:
body { background: #DDD; font: 62.5% Arial, Helvetica, sans-serif; color: #666; } h2 { font-size: 2.5em; font-weight: 400; color: #013671; } h3 { font-size: 1.2em; padding: 1.4em 0 0.8em; } td { background: #FFF; }e de classes que deveria ser também bem genérico e muito focado.
.alert{ font-color: #F00; } td.even{ background: #DDD; } -
Grid
É a estrutura essencial da página. É aqui que grande parte dos CSS Frameworks trabalha quando fornece um layout pré-moldado. Este é um exemplo de tela com conteúdo centralizado como é o caso do tema atual doPixeladas:
body{ text-align: center } #page{ width: 700px; margin: 0 auto; text-align: left } #header{ height: 100px } #content{ float: left; width: 500px } #sidebar{ float: right; width: 200px } #footer{ height: 40px }O segredo aqui é a simplicidade. Mantendo o mínimo de informações sobre a estrutura primordial da tela é mais fácil fazer alterações estruturais que normalmente seriam traumáticas, como mudar a largura da coluna lateral. Se a folha de estilos acabasse aqui, teríamos uma formatação muito básica, quase um protótipo navegável. É por aqui que gosto de começar a montar uma tela.
Obs.: O truque do
text-aligné para o Internet Explorer 6 e anteriores. -
Format
Aqui sim centralizamos todas as decisões de cores, fundos e tipologia que não são tão genéricas quanto para tags e classes e nem tão específicas que funcionem apenas em uma parte do site. Para começar, vamos definir para as seções do layout que vimos anteriormente em Grid:
#page{ background: #FFF } #header{ background: #333; color: #FFF } #content{ color: #333 } #sidebar{ font-size: 0.8em; } #footer{ background: #000; font-size: 0.8em; color: #FFF }E um pouco além:
#sidebar li{ list-style: square } #sidebar li li{ list-style: disc } -
Pages
Considerando que algumas seções do site precisam de um tratamento especial. Por exemplo, uma imagem conceitual para cada seção do site:
#content{ background: no-repeat right top; } #about #content{ background-image: url(images/bg_about.gif); } #products #content{ background-image: url(images/bg_products.gif); } #contact #content{ background-image: url(images/bg_contact.gif); } -
Hacks
Este não é o melhor rótulo para o bloco já que aqui não estão hacks de CSS e sim configurações genéricas que ajudam a construir o layout como image replacement e clear-fix:
/* img repl */ h1 a, h3.description, #menu a{ display: block; overflow: hidden; text-indent: -999px; } /* clear-fix */ #main: after{ content: "."; display: block; clear: both; visibility: hidden; /*line-height: 0;*/ height: 0; } #main{ display: inline-block; } html[xmlns] #main{ display: block; } * html #main{ height: 1%; }Cada um tem sua técnica favorita para o image replacement e outros usam a definição
display: tableao invés do clear-fix. Não importa. Isto é apenas um exemplo.
Dividir para conquistar
Se sentir que o arquivo está grande e de difícil manejo, o desenvolvedor de interfaces pode decidir dividí-lo em várias partes e importá-los em um único CSS:
@import url("reset.css");
@import url("basic.css");
@import url("grid.css");
@import url("format.css");
@import url("pages.css");
@import url("hacks.css");
...
Ah, mas é mais trabalho?
Estabelecer critérios para organizar o código CSS é mais trabalhoso no início, mas vale a pena durante o projeto e durante a manutenção, principalmente se for um código compartilhado por vários desenvolvedores. E como tudo no desenvolvimento de acordo com os padrões, a prática torna tudo mais rápido e fácil.
Teste seus próprios critérios e compartilhe com a gente!
E o Blueprint e genéricos?
Não, obrigada.
Referências:
- Frameworks for Designers, A List Apart;
- CSS Frameworks + CSS Reset: Design From Scratch, Smashing Magazine.
Twitter
Linkedin
Delicious
Posterous
RSS
mar 19, 2008 @ 19:26:17
Clap! Duplo clap!
mar 19, 2008 @ 20:41:09
Eu ainda estou em busca da organização perfeita dos arquivos CSS.
Ultimamente eu tenho feito simplesmente um arquivo geral.css com o grid básico do layout e todas as partes que se repetirão em todas as páginas (geralmente topo, lateral, rodapé).
Depois separo os css por “componente”. Por exemplo,formulários, gridView (é, aquele mesmo do [argh] .NET), etc.
Esses arquivos, juntamente com o geral.css são incluídos no css específico de cada página (ou tipo de página [p. ex. texto, listagem, destaques, etc.)].
Não é exatamente uma coisa organizada, mas, dentro da maneira como desenvolvemos lá na agência, acredito que foi a abordagem que mais se encaixou.
mar 19, 2008 @ 21:46:11
Legal teu post Simone e parabéns pelo blog.
Há tempos o conheço mas só assinei o feed nos últimos dias.
Bom, depois de tentar te agradar =]… vai uma perguntinha: tu tens alguma preferência entre o uso de hacks e comentários condicionais?
mar 19, 2008 @ 22:49:56
tigo » Comentários condicionais são mais fáceis de controlar. Tenho uma pequena cisma com alteração do código HTML para satisfazer um navegador específico, mas é melhor que espalhar hacks pela folha de estilos.
mar 20, 2008 @ 00:36:52
Excelente! Reuniu num post só tudo que precisava falar sobre CSS para quem já tá na praça.
Eu uso o Reset do Eric Meyer e não conseguiria mais viver sem ele.
Deliciado!
mar 20, 2008 @ 09:09:37
Excelente!!!
Eu tenho usado um método parecido, mas ainda me perco na hora de encontrar determinadas instruções.
Por isso eu achei mais fácil separar em vários arquivos.
Manda mais artigos Simone, estamos precisando disso!!
Grande abraço!
mar 20, 2008 @ 10:45:45
Encaminhado pra alguns amigos =)
Estava precisando formalizar isso que vc fez.
gracias :P
mar 21, 2008 @ 20:33:00
Obrigado pela resposta Simone.
Tudo de bom pra tu//=]
abr 06, 2008 @ 16:26:38
Boa simone, antigamente eu criava apenas um css para o site todo dps vi que era mais fácil dividir, tipo como você disse:
@import url(“pages.css”);
@import url(“hacks.css”);
Fica mais fácil alterar, ou corrigir, e achar as coisas,,, Gostei do seu blog ta de parabéns.. Tudo de bom amiga, fica com deus.
abr 16, 2008 @ 06:21:03
Hey senhorita, qnd der, veja esse reset –> http://www.monc.se/tripoli/
O criador diz que se inspirou no reset do Meyer mas afirma que fez melhor. Veja lá ;]
abr 16, 2008 @ 16:47:35
Oi S1mone,
Muito bom artigo!
Pra css reset, prefiro usar a versão do Yahoo UI em
http://developer.yahoo.com/yui/build/reset/reset.css
Grande abraço!
abr 23, 2008 @ 13:53:04
Legal o post!
Eu utilizo uma estrutura muito parecida!
Eu uso uma versão modificada do reset do Eric Meyer, em que tirei certas regras e adicionei outras, e certos arquivos são de nomes diferentes, mas com o mesmo propósito :P
http://www.caioruman.com/blog/css-framework-10-19/
ago 01, 2008 @ 06:32:08
mto bom!
já seguia este tipo de organização por necessidade própria. bom exemplo de como organizar um css!
abraço
set 02, 2008 @ 12:42:26
O que mais me incomoda nessa história toda são os fanáticos ou os que acham que estão sempre certos…
Fui a uma entrevista recentemente onde o diretor na empresa me perguntava “qual técnica” que eu utilizava para trabalhar com CSS… sinceramente, cada um trabalha de um jeito, cada um desenvolve da maneira que aprendeu ou desenvolveu.
É claro que se eu for trabalhar para a sua empresa por exemplo e nela vocês adotam este modelo apresentado neste post vou usar também!
Quem trabalha com CSS consegue de adequar a qualquer situação!
Achei legal a maneira apresentada!
Um grande abraço,
;-)
out 07, 2008 @ 16:45:41
O bom de voltar aqui depois de uma cara sumido é que os assuntos sempre são atuais. Concordo com você em separar as declarações; porém tenho visto que o aumento de requisições que isso gera, além dos tantos JS´s e a leve (bem leve, coisa de neurótico mesmo) perda de performance em aplicar mais folhas de estilo na página. A solução foi criar um arquivo só e usar comentários para separar as áreas (descobri afinal que é um bom uso para eles).
Ou seja, não é um seisão mas fica um meia dúzia bacana.
Abraço.
jul 15, 2009 @ 14:08:10
Bacana o post, mas não entendi o co-relacionamento exato entre dizer não à frameworks e mostrar uma forma de organizar o CSS.
Uma framework (MVC, CSS ou de metodologia) foi feita para ser customizada e extendida: será que re-escrever isso não é re-inventar a roda como milhares de programadores JAVA fazem quando fazem MAIS UMA framework MVC que não tem nada de inovador simplesmente ”se copiam” apenas com palavras-chave e modos de chamada que o criador acha que ficariam legais ? No final, ela própria não vira uma framework que depois de 5 projetos sendo usadas pode ser chamada de ”genérica” ?
O artigo transparece que o uso de frameworks “genéricos” não valem a pena, quando o conceito de framework é exatamente não ser um fim por si só, e sim um meio de atingir um objetivo. E se você própria usa essa forma de oranização, não podemos chamar isso de uma “base genérica” ?
Nessa parte principalmente:
Estabelecer critérios para organizar o código CSS é mais trabalhoso no início, mas vale a pena durante o projeto e durante a manutenção, principalmente se for um código compartilhado por vários desenvolvedores.
Concordo plenamente o que exercício da organização deveria ser feito por todos, mas será que a curva de aprendizado e sustentabilidade de uma equipe que talvez seja volátil ou multi-disciplinar não é prejudicada com uma forma proprietária e de domínio apenas do seu time de desenvolvolvimento, quando a adoção de uma versão “customizada” de uma framework já madura e possivelmente utilizada por trilhoes de designers poderia te dar um ROI e ganho de produção muito maior ?
Veja bem a questionamento não é sobre a organização de código em si, mas na forma como o conceito de framework e “genéricos” é questionada, porque no final das contas você própria criou MAIS UM framework (sem o sentido perjorativo e sem desmerece-lo).
Como a Areta do Bem bem questionou, a “rotulação de técnica” em si é ruim pois para cada problema devemos ter uma solução, mas tem uma linha de pensamento de aplicações contidas e boxed: imagina “cada um trabalhar e organizar do seu jeito” num Yahoo da vida sem uma framework ?
Blueprint e genéricos ? Com as minhas customizações, sim obrigado. ;)
Bem bacana o blog. Parabéns.