Resumo: Scalable and Modular Architecture for CSS

Por -

"Scalable and Modular Architecture for CSS" ou simplesmente SMACSS é um guia de como criar uma arquitetura para os estilos do front-end (CSS). Esse guia foi escrito por Jonathan Snook, que trabalhou no Yahoo! e hoje esta no Shopify.

O conceito do CSS é bonito em sua elegância e simplicidade. Mas essa simplicidade fica só no conceito quando estamos falando de estilizar um site mais complexo. Inúmeras regras, conflitos, "cascatas" podem facilmente causar uma confusão ao ponto aonde é impossível manter ou evoluir os estilos.

A maioria dos desenvolvedores web já se deparou, ou vai se deparar, com uma parede de CSS incompreensível e macarrônica.

O livro do SMACSS basicamente compila a experiência do autor no que diz respeito a organizar, se preparar para mudanças e evitar problemas na estilização de um grande site. E pessoalmente posso dizer que já me identifiquei com muitas das situações descritas no livro.

Categorizando os estilos

A base do SMACSS consiste em categorizar cada regra do CSS como:

  • Base
  • Layout
  • Module
  • State
  • Theme

Base é a categoria para o estilo default. São os seletores de elementos, resets e fallbacks (de HTML5 por exemplo)

Layout serve para regras que tem o proposito atuar na diagramação.

Modules. Cada componente visual do site.

State representam regras que tem haver com a interação do usuário e que mudam como os modules ou layouts são apresentados.

Theme não são sempre necessários. Usado para por exemplo alterar a cor de um elemento ao final. Pode ser aplicado de acordo com a preferencia do usuário, ou então seção do site por exemplo.

Na organização dos arquivos de estilo, as categorias podem servir como separadores.

base/
    reset.scss
    defaults.scss
layout/
    grid.scss
    alternate.scss
module/
    bookmarks.scss
    button.scss
    callout.scss
mixins.scss
global-states.scss
main.scss

Segundo a recomendação do SMACSS, a maioria dos states devem ser definidos dentro de seus respectivos módulos, no entanto, podem existir estados "globais", como por exemplo .is-hidden, is-collapsed que podem ser definidos em um arquivo de separado.

Place layout and module states, including media queries that affect those layouts and modules, into the module files. - Jonathan Snook

O mesmo serve para as media queries

Convenção e padronização

Outra prática sugerida pelo SMACSS é de utilizar um préambulo no nome das classes para identificar a categoria. Isso da mais contexto as classes e possibilita uma melhor leitura.

Utilizar l- para classes de layout, is- para estados é um pequeno detalhe que pode fazer toda a diferença. Para casos mais rigorosos, a adoção de m- para os módulos também pode ser útil. Compare a leitura dos dois trechos abaixo:

<div class="card expanded">...</div>

Nesse caso não podemos afirmar com certeza se .card é um estilo visual ou uma diagramação. Além disso não podemos dizer se .expanded é uma classe permanente.

<div class="m-card is-expanded">...</div>

Com os devidos préambulos já podemos presumir que o modulo .m-card possuí uma versão expandida .is-expanded que provavelmente é alterado via JavaScript.

Como o SMACSS é um guia não tão rigoroso, é importante definir as convenções para o seu projeto e documenta-las. O conselho que posso dar aqui é, mantenha a documentação o mais próximo do código. Assim é possível versiona-la e facilitar as consultas.

Have a convention, document it, and stick to it. - Jonathan Snook

Hierarquia e Especificidade

O SMACSS não impõe uma regra sobre esses assuntos. No entanto defende que os módulos devem ser semânticos e preferencialmente independentes do HTML aonde serão aplicadas.

Com isso, seletores que incluam elementos devem estar presentes na categoria Base (Visto anteriormente)

// base/defaults.css
h3 {...}
p {...}
li {...}

Ou no escopo de um modulo, por exemplo:

// modules/thumb.css
.m-thumb {...}
.m-thumb > h3 {...}
.m-thumb > p {...}
.m-thumb.is-selected {...}

// layout/alternate.css
.l-inline > li {...}

Ainda que isso cause certa dependência da estrutura HTML, Jonathan Snook defende que pode valer a pena em certos casos onde o modulo é usado diversas vezes na pagina.

We want to avoid going back to the days where we did silly things like adding class names to every paragraph. [...] We are trying to strike a balance between maintenance, performance, and readability

Porém a forma mais recomendada pelo SMACSS é depender o mínimo de seletores de elementos.

// modules/thumb.css
.m-thumb {...}
.m-thumb-title {...}
.m-thumb-body {...}
.m-thumb.is-selected {...}

// layout/alternate.css
.l-inline {...}
.l-inline-list {...}

Inclusive essa é a forma considerada mais performática de escrever CSS. Mas ao mesmo tempo fica o alerta:

If you take yhis recommendation at face value, they are suggesting we go back to the days of <p class=bodytext>. - Jonathan Snook

Considerando performance, outras recomendações do autor:

  1. Use child selectors.
  2. Avoid tag selectors for common elements.
  3. Use class names as the right-most selector.

Por fim, o SMACSS não define uma guideline tão rígida sobre como escrever os seletores. Esse é o ponto mais aberto para convenções do utilizador ou de outras metodologías.

Prototyping (AKA: Pattern Library)

SMACSS defende fortemente o conceito de prototyping, também conhecido como "Pattern Library".

Esse conceito consiste em isolar os seus componentes em um formato fácil de consultar e testar, de forma semelhante ao Twitter Bottstrap, aonde você pode ver cada pedaço de "layout" ou "modulo" aplicado isoladamente junto com um código de exemplo.

A prototype should assist in viewing components in part or in whole and to allow the codification of the design language into building blocks. - Jonathan Snook

Ao final do capítulo o Pattern Library do MailChimp é citado como exemplo. Que por sinal é um link que não me canso de compartilhar.

Remember, patterns are good. Codifying those patterns is also good. Having a process in place to review and test those patterns is great! - Jonathan Snook

Esse capitulo me lembrou do excelente artigo sobre Pattern Library escrito pelo Paul Boag. Recomendo.

Conclusão

O SMACSS é um guia com algumas instruções sobre o que fazer e porque fazer. Por ser um guia não muito restritivo, o próprio autor sugere elaborar uma documentação mais específica por projeto que entre em detalhe as convenções e regras adotadas.