Escrevendo um bom CSS

Publicados: 2016-10-17

Estou sempre tentando aprender coisas novas. No entanto, também tento aprender maneiras de melhorar a maneira como já faço as coisas. Tanto no meu trabalho em tempo integral quanto para projetos paralelos ao cliente, o que eu sempre quis melhorar foi meu CSS. Sempre achei que sou muito bom quando se trata de CSS, mas sempre achei confuso de ler e muitas vezes difícil de manter.

O que tenho tentado fazer é descobrir o que torna um CSS bom, legível e sustentável. Acho que inventei (e encontrei) algumas maneiras de tornar tudo isso possível.

Os problemas

Há várias coisas que me incomodam sobre CSS. Os incômodos mais comuns que tenho são:

  • repetindo código comum
  • prefixos do navegador
  • falta de comentários
  • mais de seletores qualificados
  • nomes de classe ruins

Quando se trata de meus projetos pessoais, assumo total responsabilidade pelo meu código. Raramente comento meu CSS e geralmente o trato como uma reflexão tardia. Isso está errado.

Por muito tempo achei que os nomes das minhas classes são “semânticos” e sou apenas eu fazendo as coisas, então não há necessidade de explicar o código, ou pequenos “hacks”, ou qualquer coisa.

Voltar ao código em um projeto de longa data rapidamente prova que essa teoria está muito errada.

Quando se trata de código no trabalho, não posso levar toda a culpa. Na verdade, parte do problema é o número de pessoas que colocaram suas mãos lá. Atualmente, nossa equipe tem sete de nós que em algum momento escreveram CSS para nossos sites, com outros 6-8 que entraram e saíram do anos. Cada membro da equipe tem níveis variados de conhecimento e habilidade em relação a CSS.

Além disso, como costuma ser o caso de projetos de longa data, parte do código é antigo . Muito disso é pré-CSS3, ou pré-qualquer-tendência-foi-legal-5-anos-atrás. Em ambos os casos, muitas vezes havia maneiras diferentes de fazer as coisas no momento em que foi escrito e, em alguns casos, uma falta natural de conhecimento.

Também aprendi que alguns programadores insistem que seu código é “autodocumentado”. Se você não estiver familiarizado com esse termo, ele se traduz em “meu código não tem comentários”.

Soluções

Embora nada seja perfeito, acredito que há coisas que podemos fazer para melhorar nosso código. Eu descobri CSS Guidelines por Harry Roberts um tempo atrás. Ele se mantém fiel à promessa de “Conselhos e diretrizes de alto nível para escrever CSS sã, gerenciável e escalável”.

Comentários

Embora as Diretrizes CSS forneçam detalhes sobre estilos de comentários, eu pessoalmente apenas tento colocar algo para me dizer no futuro o que eu estava pensando. Começo cada componente com um comentário representando o título, com detalhes sobre a intenção do componente.

Ao usar um pré-processador, estilizo comentários específicos para serem incluídos no CSS ou ignorados pelo pré-processador. Ainda estou trabalhando nessa parte, e tentando adquirir o hábito de colocar alguma coisa, qualquer coisa .

Orientação a objetos

A orientação a objetos é um paradigma de programação que quebra grandes coisas em pequenas coisas. Da Wikipédia:

A programação orientada a objetos (OOP) é ​​um paradigma de programação que representa o conceito de 'objetos' […] que geralmente são instâncias de classes, [e] são usados ​​para interagir uns com os outros para projetar aplicativos e programas de computador.

Quando se trata de CSS, chamamos isso de CSS orientado a objetos, ou OOCSS . O conceito básico separa a estrutura do elemento, da pele do elemento. Isso significa que podemos reutilizar facilmente quaisquer padrões de design recorrentes, sem necessariamente reutilizar os detalhes de implementação específicos ao mesmo tempo. O OOCSS se concentra fortemente na reutilização de código, o que nos torna mais rápidos e pode manter o tamanho de nossa base de código baixo.

Penso em aspectos estruturais como esqueletos; quadros comuns que fornecem construções conhecidas como object . Esses objetos são padrões de design simples que estão livres de qualquer cosmético. Abstraímos a estrutura de um conjunto de componentes para termos um objeto genérico.

Em seguida, opcionalmente, adicionamos a camada “skin” à nossa estrutura para que possamos dar às abstrações uma aparência específica. Por exemplo (retirado das Diretrizes CSS):

 /**
 * Um objeto de botão simples e sem design. Estenda este objeto com uma skin `.btn--*`
 * classe.
 */
.btn {
    exibição: bloco em linha;
    preenchimento: 1em 2em;
    alinhamento vertical: meio;
}

/**
 * Pele dos botões positivos. Estende `.btn`.
 */
.btn--positivo {
    cor de fundo: verde;
    cor branca;
}

/**
 * Pele dos botões negativos. Estende `.btn`.
 */
.btn--negativo {
    cor de fundo: vermelho;
    cor branca;
}

Aqui vemos como a classe .btn simplesmente fornece estrutura para um elemento, mas não tem nada relacionado a cosméticos. Podemos estender .btn com uma segunda classe, como .btn--positve para dar a esse elemento um estilo mais específico:

 <button class="btn btn--positive">OK</button>

Eu prefiro usar várias classes no meu HTML, em vez de usar algo como @extend em um pré-processador. Isso me dá mais visibilidade no meu HTML, permitindo ver rapidamente quais classes são aplicadas ao meu elemento. Isso também significa que minhas classes não estão fortemente vinculadas a outros estilos no meu CSS. Isso meio que ajuda o OOCSS seguindo os conceitos de encapsulamento .

BEM

BEM ( Block, Element, Modifier ), é uma metodologia de front-end desenvolvida no Yandex. O BEM é na verdade uma metodologia muito completa, e eu honestamente não me aprofundei em todos os detalhes, mas o que me preocupa é simplesmente a convenção de nomenclatura.

Estou usando convenções de nomenclatura do tipo BEM. O conceito é o mesmo, mas a sintaxe exata pode ser ligeiramente diferente.

O BEM coloca as aulas em três grupos:

  1. Bloco: a raiz ou base de um componente
  2. Elemento: um componente dentro de um Bloco
  3. Modificador: uma variação ou extensão do Bloco

Uma analogia muito básica ( não é um exemplo):

 .cão {}
.dog__tail {}
.dog--pequeno {}

Os elementos são delimitados com dois sublinhados (__) e os modificadores são delimitados com dois hífens (–).

Na analogia acima, vemos que .dog é o Bloco, a raiz do elemento. Então, .dog__tail é um Elemento, é uma parte menor de um Bloco .dog . Por último, .dog--small é o Modifier, uma variação específica do bloco .dog . Você também pode aplicar Modificadores a Elementos. por exemplo, poderíamos ter .dog__tail--short para, novamente, especificar uma variação no elemento dog__tail .

Em alguns casos, posso querer várias palavras para Blocos, Elementos ou Modificadores. De qualquer forma, eles são separados por um único hífen (-), e as classes são sempre escritas em letras minúsculas .

Pré-processadores

Eu tenho gasto tempo trabalhando com pré-processadores CSS em meu fluxo de trabalho e, até agora, tem sido incrivelmente valioso. Os pré-processadores de CSS pegam o código escrito em uma linguagem pré-processada e os convertem no bom e velho CSS. Eles não são CSS, o que significa que não estão vinculados às mesmas regras e limitações do CSS. Embora o CSS seja ótimo, nem sempre nos permite fazer facilmente as coisas que gostaríamos de fazer.

Por exemplo, uma coisa que seria muito legal em CSS são as variáveis . Talvez você queira que algo tenha a margem esquerda de um elemento igual à largura de outro, e de repente alguém decide que esses números precisam mudar. Como eles são o mesmo número e seu layout pode depender desse número, você precisa alterá-lo em mais de um lugar. Mas com um varibale você pode alterá-lo em apenas um lugar e refletir em todo o layout. Claro, há muito mais nos pré-processadores do que apenas variáveis, mas isso é um começo!

Você obviamente não precisa usar um pré-processador, mas acho que você encontrará a maioria das pessoas que usam, não voltarão atrás. Eu sei que não vou. O ganho em flexibilidade e maior legibilidade são algo que eu simplesmente não posso desistir. Simplesmente poder usar variáveis ​​e mixins é o suficiente para me manter viciado.

Existem vários pré-processadores disponíveis, mas os únicos dois que eu realmente olhei e usei são LESS e SASS . Por favor, dê uma olhada e considere adicionar um deles ao seu fluxo de trabalho, você não olhará para trás.

Concluindo

Meu ponto real aqui, é que CSS pode ser melhor. Tudo pode ser melhor. Alguém me disse recentemente em um comentário em um post no Reddit que “CSS não tem semântica”. Eu discordo totalmente. CSS 100%, sem dúvida pode ser semântico.

Usar OOCSS e BEM, de fato, dá ao seu CSS um significado muito semântico. Isso não significa que é fácil logo de cara, mas vale a pena explorar. Combine isso com pré-processadores de CSS e você terá o potencial para um CSS muito legível, sustentável e escalável .

Também gostaria de observar que isso não apenas torna seu CSS (pré-processado ou não) mais legível, mas também torna seu HTML mais legível, aplicando nomes de classes semânticas aos elementos.

TL;DR

Ok, talvez tenha sido muito – para resumir, escreva CSS melhor fazendo isso:

CSS Orientado a Objetos :

  • cada classe faz uma coisa - faz bem, faz certo

Nomes de classes de estilo Block, Element, Modifier (BEM) :

  • Bloco: .grid
  • Elemento: .grid__item (2 sublinhados)
  • Modificador: .grid--wide (2 hífens)

Os pré-processadores são incríveis :

  • confira: LESS – SASS
  • ou encontre outros: 8 pré-processadores CSS para acelerar o tempo de desenvolvimento