Organizando o CSS com o SUIT CSS

Quando trabalhamos com CSS, a forma como organizamos nossas folhas de estilos e nomeamos os componentes da nossa interface são pontos cruciais. Existem alguns padrões de organização e nomenclatura que tem como objetivo nos auxiliar nessa tarefa, entre eles BEM, SMACSS, OOCSS e o não tão falado SUIT CSS. Seja qual for o padrão de sua escolha, será perceptível o reaproveitamento de código, a comunicação mais clara entre integrantes de uma equipe, coesão e coerência no código e agilidade na entrega de projetos. Hoje vamos abordar o padrão de nomenclatura do SUIT CSS.

O SUIT CSS foi projetado para trabalhar com componentes em uma interface e se encaixa muito bem com frameworks como React, Angular, Ember ou qualquer um que trabalhe com essa abordagem (component-based). Conta com nomes de classes estruturadas com hífens significativos (hífens não são usados apenas para separar as palavras). Sua arquitetura é primariamente dividida entre componentes e utilitários.

Utilitários (Utilities)

Usamos a classes utilitárias para aplicar regras de estrutura e posicionamento que podem ser aplicadas diretamente a uma tag ou componente. Vamos dar uma olhada em sua sintaxe:

u-[sm-|md-|lg-]<utilityName>

Usamos o prefixo u, opcionalmente temos os indicadores de breakpoints para nossas variantes responsivas (small, medium e large) e em seguida temos o nome do utilitário escrito em camelCase. Veja como é simples:

<div class="u-cf">
  <a class="u-floatLeft" href="{{url}}">
    <img class="u-block" src="{{src}}" alt="">
  </a>
  <p class="u-sizeFill u-textBreak">
    …
  </p>
</div>

Nesse exemplo temos vários utilitários que aplicam estilos que estamos acostumados a usar, como clearfix, floats, displays e regras para texto. Simples não?

Componentes (Components)

Vamos ver como ficam nossas classes que agrupam as regras para os componentes? Começando pela sintaxe:

[<namespace>-]<ComponentName>[-descendentName][--modifierName]

Chegamos no ponto interessantíssimo do SUIT CSS. Depois de entender como componentes são formados, só em olhar para seu seletor temos de cara várias informações úteis a seu respeito. O componente é descendente de outro? Está inserido em algum namespace? Está tendo alguma de suas características sendo modificada? Tudo isso em seu seletor!

Namespace (opcional)

Componentes podem ter um namespace para evitar possíveis choques com outras bibliotecas usadas no projeto.

.twt-Button { /* … */ }
.twt-Tabs { /* … */ }

Raramente o namespace vai ser necessário, mas caso você precise ele está aí para evitar dores de cabeça.

ComponentName

O nome do nosso componente é escrito em “PascalCase”. Isso dá um destaque maior ao componente durante a leitura do nosso código HTML.

.MyComponent { /* … */ }

Veja como fica no HTML:

<article class="MyComponent">
  …
</article>

ComponentName — modifierName

Um modificador de componente é representado por uma classe que altera a apresentação do nosso componente base. Deve ser escrito em “camelCase” e tem que ser separado do nome do componente que ele modifica por dois hífens. Um detalhe muito importante é que modificadores devem ser incluídos no HTML em conjunto com a classe do componente base:

<button class="Button Button--default" type="button">…</button>

Para não esquecer dessa regra, é ideal que se escreva o seletor pensando nela, ou seja ao invés de:

/* Core button */
.Button { /* … */ }
/* Default button style */
.Button--default { /* … */ }

Prefira escrever da seguinte forma:

/* Core button */
.Button { /* … */ }
/* Default button style */
.Button.Button--default { /* … */ }

E se você utilizar algum pré-processador, como o SASS, isso fica mais simples ainda de se escrever:

.Button {
    /* Core button style */
    &.Button--default { 
        /* Default button style */ 
    }
}

ComponentName-descendentName

Um componente descendente é uma classe que é adicionada a um nó descendente do componente base. Ele deve ser escrito em “camelCase”. Veja no exemplo:

<article class="Tweet">
  <header class="Tweet-header">
    <img class="Tweet-avatar" src="{{src}}" alt="{{alt}}">
    …
  </header>
  <div class="Tweet-bodyText">
    …
  </div>
</article>

O seletor css nesse caso não deve ter mais de um nível:

.Tweet { /* ... */ }
.Tweet-header { /* ... */ }
.Tweet-avatar { /* ... */ }
.Tweet-bodyText { /* ... */ }

E olha só como fica usando o SASS:

.Tweet {
    { /* ... */ }
    &-header { /* ... */ }
    &-avatar { /* ... */ }
    &-bodyText { /* ... */ }
}

ComponentName.is-stateOfComponent

Este é um caso especial do padrão que não está definido em sua sintaxe. Você deve usar o is-stateName para refletir as mudanças de estado de um componente. Deve ser escrito em “camelCase” e não deve ter seu seletor escrito sozinho, assim como no caso dos modificadores.

Veja um exemplo:

.Tweet { /* … */ }
.Tweet.is-expanded { /* … */ }

E no HTML:

<article class="Tweet is-expanded">
  …
</article>

Considerações Finais

O padrão de nomenclatura do SUIT CSS é uma opção poderosa para organizar o CSS de seu projeto. Como você pôde ver, conseguimos encapsular bem as regras de estilo de cada componente de nossa interface. Em conjunto com um pré-processador ele pode ser mais interessante ainda pois podemos separar cada componente em um arquivo distinto, aumentando assim a organização e facilidade de manutenção do nosso código. Juntando isso aos benefícios gerais citados no início desse post, já são bons motivos para você sair de sua zona de conforto e testá-lo em seu projeto. São poucas regras para aprender e não tem forma melhor de aprender do que as aplicando e comparando com outros padrões disponíveis. Como leitura complementar, temos o excelente artigo do Jean Carlo Emer, OOCSS, SMACSS, BEM, DRY CSS: afinal, como escrever CSS?.

Os exemplos usados nesse post foram retirados da especificação no github do SUIT CSS e lá você notará que ele é bem mais que um padrão de escrita de estilos. Ele possui um conjunto de ferramentas e componentes já prontos que podem ser utilizados, testados e extendidos em seu projeto. Vale à pena conferir.