Começando a organizar seu CSS

Você já deve ter aberto um CSS com 2.000 linhas com o nome de styles.css, dentro de uma pasta chamada css. Esse é um bom momento em focar um tempo para estudar um dos modelo de arquitetura de CSS:

Vale a pena ler os cinco modelos de arquitetura e em seguida definir com sua equipe a melhor maneira de organizar o seu CSS. Foi o que realizamos na Caelum, antes de começar a desenvolver a parte interna do nossa plataforma de curso online, o Alura.

Após ler as cinco arquiteturas de CSS, o time de desenvolvedores (Back end e Front end) se reuniu durante 3 dias por uma hora diariamente focado em resolver os seguintes pontos:

Como definir um bom nome para uma class?

Durante a discussão decidimos tomar os seguintes cuidados para definir o nome de uma class:

  • Evitar nome genérico demais, como title;
  • Evitar nome preso a tag, como inputText;
  • Não dar nome com associação a uma propriedade CSS, como floatLeft;
  • Não dar nome que descreva o valor de um propriedade CSS, como colorBlue;
  • Utilizar o hífen para identificar o filho lendo apenas o nome da class, como paifilho
  • Utilizar o underline para adicionar um modificador, como pai-filho_modificador;
  • O nome de uma class tem que começar com uma analogia com o mundo real e a segunda parte quando necessário, representar o conteúdo do elemento, por exemplo: cardCourse.

Utilizando os pontos acima como base, vamos dar nome para os elementos do seguinte layout:

cardCourse

<section class="cardCourse">
  <img class="cardCourse-icon" src="iconHtmlCss.png">
  <h3 class="cardCourse-title">Avançado a HTML e CSS</h2>

  <div class="progressBar">
    <span class="prgressBar-value">50%</span>
    <progressbar class="progressBar-bar">
      Seu progresso é de 50%.
    </progressbar>
  </div>
</section>

Como organizar os arquivos CSS?

O time curtiu a organização criada pelo BEM. Seguindo o exemplo do layout apresentado acima, criamos uma pasta css, dentro dela criamos outra pasta com o nome de block.
Todos os seletores dos blocos cardCourse e progressBar, ficam dentro de um arquivo com o nome de cardCourse.css e progressBar.css, que fica salvo dentro da pasta block. E qualquer arquivo CSS que não for um bloco fica na raiz da pasta css, como o famoso arquivo reset.css.
Quando temos um CSS que vai ser utilizado apenas em uma página, colocamos ele dentro da pasta page.

tree

Como escrever seletores sem muitos problemas de especificidade?

Ter seletores com valores altos de especificidade torna a manutenção do CSS mais custosa.
A melhor forma de resolver isso é utilizar seletores com baixo valor e especificidade. Pra escrever seletores com um baixo valor de especificidade, vamos entender melhor como funciona esse negócio de especificidade:

Valores de especificidade dos seletores CSS

Id #card Class .cardCourse
Pseudo-class :first-child
Tag section Seletores avançados > + ~ e :not()
100 10 1 0

Cada seletor CSS tem um valor conforme foi apresentado na tabela acima. Para entender um pouco melhor vamos ver uns exemplos:

/* Valor de especificidade: 100 */
#card {
  ...
}

/* Valor de especificidade: 10 */
.cardCourse {
  ...
}

/* Valor de especificidade: 1 */
section {
  ...
}

/* Valor de especificidade: 10 + 10 = 20 */
.cardCourse .cardCourse-title {
  ...
}

/* Valor de especificidade: 10 + 10 + 1 = 21 */
.cardCourse h3.cardCourse-title {
  ...
}

/* Valor de especificidade: 10 + 10 = 20 */
.cardCourse:nth-of-type(2n) {
  ...
}

Para não termos muitos problemas com valores altos de especificidades optamos em seguir as seguintes regras:

  • A ordem dos seletores no arquivo CSS devem respeitar a ordem do HTML;
  • Evitar seletores com id e tag;
  • Evitar o uso de seletores avançados e pseudo-class.

Com técnicas como essa conseguimos deixar nosso CSS no Alura muito mais modular e de fácil manutenção. A produtividade da equipe aumentou muito. E você, como faz no seu trabalho? Tem outras dicas de como melhorar a forma que organizamos nosso CSS?

19 Comentários

  1. Felipe 09/09/2015 at 11:22 #

    Vocês utilizam pré-processadores? SASS? LESS? STYLUS?

  2. Enzo 09/09/2015 at 12:56 #

    óóótimo post!

  3. Gabriel 09/09/2015 at 14:58 #

    Muito bacana, já até passeio pro pessoal aqui dar uma lida também!

  4. Bruno Rodrigues 10/09/2015 at 08:34 #

    Organizar o css e escolher a melhor estrutura pode ser um desafio para desenvolvedores com “pressa” de entregar seus sites e projetos.

    Suas dicas são muito boas, e ajudam muito a poupar tempo e até mesmo reutilizar o css, principalmento o OOCSS.

    Parabéns pelos seus posts

  5. Marco Bruno 10/09/2015 at 10:17 #

    Bom dia, Felipe.

    Após organizar o CSS deixamos de utilizar na parte interna (onde a galera assiste os cursos).
    Utilizamos LESS na parte externa (Site) do Alura, mas acredito que assim que organizarmos o CSS não vamos mais utilizar.

  6. Altair Moura 10/09/2015 at 14:17 #

    Marco,

    Parabéns pelo post. Esses cálculos de especificidade serve para aumenta a produtividade, deixar mais modular facilitando a manutenção. Essas alterações impacta na performasse?

  7. Sérgio Lopes 10/09/2015 at 15:00 #

    Altair,
    Não impacta significativamente em performance não. Existem pequenas diferencas mas costumam ser negligenciaveis em 99% dos casos. Se sua pagina for muito complexa e diferente, talvez valha a pena medir e ver o impacto real. Senao, em 99% dos casos, não se preocupe com performance de seletores de id vs classes e coisas do tipo.

  8. Alefh Sousa 11/09/2015 at 17:53 #

    Marco, excelente post!!

    Mas uma dúvida, deixando isso modular temos diversos arquivos que devemos levar para o cliente. Como vocês estão tratando isso em produção ? compila tudo em um arquivo “.min” através do grunt? Ou entrega arquivo por arquivo?

  9. Marco Bruno 11/09/2015 at 18:00 #

    Obrigado Alefh.
    Utilizamos o Grunt.

  10. Marcelo 13/09/2015 at 19:29 #

    Opa, tudo bem?

    Achei legal o post, mas gostaria um pouco mais de detalhes do que levou a tomar a decisão por essa arquitetura ao invém do design atomico por exemplo.

    Parabéns,
    Abcs

  11. Laerte 22/09/2015 at 09:15 #

    Ótimo post, pra quem esta começando essas orientações são excelentes!

  12. Jhonatan Morais 22/09/2015 at 09:58 #

    Muito bacana. Ficou divertido a citação: “O time curtiu a organização criada pelo BEM” (Pelo bem de todos rsrs…)
    Otimas dicas, utilizarei algumas delas. Obrigado!

  13. Lucas Mahle 22/09/2015 at 17:46 #

    Interessante, em partes eu estruturo da mesma forma.
    Uso como base o bootstrap v3 + LESS, removo boa parte do código dele, e uso os mixins.
    Tenho uma pasta “components” onde tem a mesma função do “block” citado no artigo e uma pasta “pages” para css específicos.
    A maior vantagem é que eu posso usar componentes de um site em outro muito facilmente.
    Inclusive estou gradativamente migrando para marcação BEM.

    Afinal, hoje eu desenvolvo (front & back) sozinho, mas me preocupo muito e transparecer meu código e facilitar para qualquer pessoa dar manutenção.

    É uma adaptação que leva um tempinho, mas é um grande diferencial pra mim e pra empresa.

  14. Vitor Melo 29/09/2015 at 01:18 #

    Hoje eu utilizo apenas um arquivo scss, com uma grande gama de comentários, consigo navegar por esses comentários facilmente, já experimentei dividir meus arquivos, no entanto, em cada projeto, você acaba tendo uma nova ideia, um novo nome, e acaba saindo do próprio padrão que criou. Fora a desvantagens de ter que deixar os vários arquivos abertos.

    Utilizo o formato abaixo, para chegar até um deles basta eu pesquisar por sinal de igual mais o nome da seção específica.

    // =header
    //—————

    // =menu
    //—————

    // =main
    //—————

    // =footer
    //—————

  15. Diogo Machado 29/09/2015 at 07:49 #

    Ótimo tópido, as vezes a gente sai codando css sem controle. Eu mesmo tenho um projeto de interface unificada aqui onde trabalho, temos algumas dificuldades para modularizar e organizar, depois desse post, vou repensar.

  16. André Violin 10/11/2015 at 09:50 #

    Bom dia, parabéns pelo post, mas poderia me tirar uma dúvida?

    É feita a seguinte afirmação: “Ter seletores com valores altos de especificidade torna a manutenção do CSS mais custosa. A melhor forma de resolver isso é utilizar seletores com baixo valor e especificidade.”, então é mostrada a tabela em que os Seletores Avançados aparecem com o valor 0 (zero).

    Na sequencia aparece o seguinte texto: “Evitar o uso de seletores avançados e pseudo-class.”.

    Afinal, devo ou não utilizar seletores avançados, uma vez que eles possuem baixo (ou melhor, nenhum) custo de especificidade?

  17. Daniel 09/12/2015 at 18:03 #

    E quanto ao rscss?

    http://rscss.io/index.html

    Vocês acham que ele também é um bom “guia”?

  18. Mauricio 17/12/2015 at 16:08 #

    Pelo que vi do post e dos comentários depois dessa abordagem vcs decidiram não usar mais preprocessadores? Quais as vantagens vcs observaram com isso?

Deixe uma resposta