Uma outra visão sobre CSS Frameworks

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:

  1. Reset, onde limpo todas as definições de estilo padrão do navegador;
  2. Basic, onde estão as definições genéricas de tags e classes;
  3. Grid, onde desenvolvo estrutura da página;
  4. Format, onde configuro cores, fundos, tipologia, por área de layout;
  5. Pages, onde estão as definições especiais de cada seção do site;
  6. 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.

  1. 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
    }
  2. 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;
    }
  3. 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.

  4. 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
    }
  5. 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);
    }
  6. 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: table ao 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:

Por | Tags: | Alterado em 19/03/08 às 18:03

Comentários

  1. Jader Rubini disse:

    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.

  2. tigo disse:

    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?

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

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

  5. Leonardo L Procópio disse:

    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!

  6. Caio disse:

    Encaminhado pra alguns amigos =)
    Estava precisando formalizar isso que vc fez.

    gracias 😛

  7. tigo disse:

    Obrigado pela resposta Simone.
    Tudo de bom pra tu//=]

  8. Vomicae disse:

    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.

  9. tigo disse:

    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á ;]

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

  11. Caio disse:

    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 😛

    http://www.caioruman.com/blog/css-framework-10-19/

  12. Joao Pereira disse:

    mto bom!

    já seguia este tipo de organização por necessidade própria. bom exemplo de como organizar um css!

    abraço

  13. Areta do Bem disse:

    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,

    😉

  14. Leo Cabral disse:

    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.

  15. Léo Hackin disse:

    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.

  16. Wilton Santos disse:

    Nossa, perfeito seu artigo, Simone. Gostei tanto pelas dicas e ideias, quanto pelo método de trabalho.
    Você descreveu o que realmente importa para qualquer desenvolvedor front-end, seja ele inicante ou experiente. É importante ter em mente o que são resets e formatações padrões.

    Não gosto muito de usar frameworks “da moda”, pois na minha opinião são muito “pesados” e dificilmente se adaptam à um método de trabalho de uma agência/empresa de Web. Não descarto que é importante conhecer.

    Utilizando algo assim torna-se inevitável a adaptação dos arquivos de estrutura e as vezes até de formatação para melhor se adequarem a cada metodologia de desenvolvimento. Fazendo o próprio framework, objetivo e claro, é uma opção muito mais interessante na minha opinião e até menos trabalhosa.

    Parabéns pela dedicação, aqui no Brasil precisamos muito de pessoas com iniciativa e que estudam de verdade, nessa nossa área tão “mal compreendida” por muitos…

    Um abraço!

  1. […] maior esteja com os scripts habilitados em seu navegador. Aqui você trabalha apenas a parte de grid do seu […]

  2. […] maior esteja com os scripts habilitados em seu navegador. Aqui você trabalha apenas a parte de grid do seu […]

Faça um comentário

*