Nomeando classes no CSS, a thread
Se você quer aprender a nomear suas classes no CSS, acredito que aprender essas 3 coisas possa te ajudar:
- Tomar decisões de arquitetura de CSS
- Expandir seu vocabulário de tokens e componentes
- Conhecer padrões de CSS (como BEM ou CubeCSS)
"Arquitetura CSS" pode assustar um pouco, mas a proposta é basicamente você pensar no seu CSS de forma estrutural antes de escrever.
Você pode, por exemplo, escrever unicamente classes utilitárias, que são classes que fazem uma coisa só e a fazem bem, como no tailwindCSS
Ou você pode construir CSS pensando nos seus componentes, como acontece em frameworks de componente como Material UI, Bootstrap, UI Kit ou Ant Design.
Você pode seguir qualquer uma das abordagens ou ambas, mas sempre adotando de forma consistente!
Expandir seu vocabulário de componentes é importante pois ao escrever uma classe, a maioria das vezes acabamos descrevendo o conteúdo do elemento ao invés de descrever o que o elemento é semanticamente.
Vamos usar o componente abaixo como exemplo, como vocês o nomeariam?
Se você pensou em .invitation ou .connection, entendo sua lógica. Porém se existir outro componente igual a esse só que avisando que vc recebeu uma mensagem, com um layout um pouco diferente, vc:
- Usaria a mesma classe mesmo não sendo um convite
- Criaria outra classe parecida??
Nenhuma das duas soluções parece ideal né? Com uma você tá referenciando uma classe pra um contexto diferente do que ela foi criada, o que é no mínimo confuso.
No outro você duplicou código, o que é beeem ruim pra performance e legibilidade.
Ambas soluções não escalam.
Em bibliotecas de componente esse mesmo elemento se estático pode ser chamado de Card, se feedback de uma ação pode ser chamado de Alert, se for um aviso do sistema pode ser Notification, Snackbar ou Toast.
Esses nomes são padrões consistentes entre várias bibliotecas de UI
A gente poderia criar uma classe base pra todas as notificações e classes modificadoras pra cada tipo de notificação contendo apenas o código que diferencia uma da outra.
Essa abordagem funciona, mas o problema dela é a especificidade.
Por usar duas classes você está criando um seletor com especificidade 0,2,0, correndo o risco de sobrescrever estilos com especificidade menor sem querer.
Se tu não sabe como mensurar especificidade, esse site me ajudou demais a aprender
specifishity.com/
Se a gente fosse estilizar o mesmo elemento usando uma lógica de CSS utilitário, poderíamos criar todo o estilo do card e separá-lo em diferentes classes que vão compor o estilo final. Uma classe pra border, border-radius, border-color.
O BO dessa abordagem é você vai sempre ter que escolher entre escrever utilities mais complexas e menos reutilizáveis OU escrever utilities mais atômicas só que ESCREVER CLASSE PRA CARALHO.
Eu aconselho sempre um equilíbrio entre componentes e utilities.
Pra finalizar esse tópico, pesquisem bibliotecas de componente ou utilitárias de CSS, elas buscam adotar padrões consistentes de nomenclatura. Ao criar um novo componente sempre vale consultar nas documentações da vida se já existe um parecido que vc pode roubar o nome (ou mais)
Lembra no componente de notificação que usamos uma classe modificadora pra alterar o CSS base da classe .notification?
Isso é uma estratégia de CSS adotada por alguns padrões de CSS pra evitar duplicação de código. O BEM CSS é literalmente Bloco, Elemento e Modificador
Padrões de escrita de CSS servem para mitigar problemas com especificidade, organização, arquitetura, conflitos de nome e etc APENAS padronizando a forma como você pensa e escreve as suas classes
Sobre isso, em português:
desenvolvimentoparaweb.com/css/bem/
desenvolvimentoparaweb.com/css/cube-css/
Pra evitar criar nomes de classe desnecessariamente, eu uso e abuso dessas 3 dicas:
- se existe uma pseudo-classe pro estado do seu elemento USE
- data-attributes são ótimos pra estados definidos via JS
- variáveis CSS podem ser usadas como "props" que o HTML envia pro CSS
Resumindo:
Se você sente que o nome das suas classes tá uma merda CALMA! Não é tão simples quanto parece fazer bem e ninguém nasce sabendo. Tem bastante coisa legal pra tu estudar que, com tempo, vai fazer com que essas decisões de nomenclatura sejam quase que automáticas.
Referências legais aqui
Um texdto bacana do Nicolas Gallagher sobre semântica
nicolasgallagher.com/about-html-semantics-front-end-architecture/
CSS Guidelines
cssguidelin.es/#naming-conventions