Nomeclatura de classes no CSS

[felipefialho]

Pegando o gancho da issue #35 do @willianjusten, queria abrir uma discussão com vocês sobre padrão de escrita CSS.

Nunca curti muito o BEM e outras metodologias, sei que não interfere no resultado final, mas a 'sujeira' no nome das classes me incomoda.

Portanto, sempre tentei ao máximo usar dois separadores, exemplo: widget-gallery, e trabalhava com elementos já existentes (como atoms, molecules, etc), seguindo o conceito de Atomic CSS.

Porém nem sempre isso dá certo, em várias situações preciso criar um elemento especifico para esse widget, e ele ganha mais um nome widget-gallery-main, isso sempre me incomodou.

Já pensei em utilizar inclusive os [data-*] para modificador, mas isso causaria mais um problema, e preferi manter separado (uso o [data-*] para controlar plugins do JavaScript).

Então, hoje pensei em simplesmente adicionar mais um - no terceiro modificador. Eu achei que para o meu raciocínio lógico fica muito mais sólido (tenho pavor quando as coisas começam a parecer estar saindo do controle), usa um pouco da ideia do BEM e etc, mas não fica um código muito exagerado.

Ficaria portanto: widget-gallery--main.

O que pensam sobre isso?

[bernardodiasc]

Aproveitando a pergunta, em especial em relação ao uso de --, fiz um projetinho ante-ontem pra um hackaton com mais 3 pessoas, usamos BEM e CSS Modules. Houve uma ocasião de usar o modificador (M do BEM, --modifier), e quando tentei pegar a variável no componente, não rolou. A não ser que tenha feito algo errado, como era 1 dia de hackaton não parei pra debugar isso e mudei para apenas um -mesmo pro modificador e boa, apesar de ter um stack foda o projeto era meio que descartável servindo apenas de POC pra chefia. Só comentando mesmo pra agregar um ponto contra essa nomenclatura. A propósito, CSS Modules simplifica tanto esse lance de nomenclatura, da pra usar classes tão mais genericas como por exemplo .title sem medo de ser feliz, depois do hackaton percebi que nem precisávamos ter incluído as regras do BEM no projeto (vivendo e aprendendo).

[willianjusten]

Então, como eu falei lá na issue, eu também não sou muito chegado no BEM, mas queria ter algo para me organizar melhor e não causar especificidades altas.

Por isso me adaptei muito bem com o RSCSS, que meio que já possui tudo que eu queria. Ele é fácil de ler, escrever, não parece fugir do controle e segue uma filosofia bem parecida com a que eu já usava.

[ghost]

@bernardodiasc esse lance do -- na classe modificadora já aconteceu comigo. Estava me baseando na metodologia do BEM, mas separava o nome apenas com - ao invés de __ e quando fosse adicionar um modificador não repetia a classe, adicionava somente a classe modificadora com --.
Ex.: <div class="thumb-partner --large">.
Até então tudo funcionou muito bem e ficou fácil de ler o html, mas na hora que fui testar no iPad (que não sei o modelo) ele não reconheceu e cagou tudo...

Agora eu gostei muito do rscss, quando li o post do @willianjusten e a documentação, comecei a usar e fiquei muito entusiasmado. Principalmente essa ideia de separar o componente por arquivo. Ajuda muito!
Só fiquei em dúvida com a performance, pois dizem que os navegadores procuram da direita para esquerda até chegar no elemento pai.

[DevCarlosAugusto]

@lfeh eu acho animal a ideia do BEM, mas odeio a nomenclatura dele também, atualmente trabalho usando BEM/SMACSS.
Os dois são muito bons juntos, mas acho que essa nomenclatura é horrível e suja o HTML no final, atualmente tenho tentado mudar e pra não usar muitos "-" tenho usado apenas um para modificadores e apenas um "_" para elementos, misturando camel case em nomes compostos.
Ainda não conheço RSCSS que o @willianjusten comentou mais acima mas vou dar uma olhada depois, atualmente tenho visto um pouco de ITCSS que até gostei mas cria uma certa especificidade.

Acho que apesar de todos essas propostas serem interessantes ainda não temos uma espécie de "Design patterns" para CSS....

[gustavomodena]

Pessoal, já passei por esse problema de chamar alguma classe no js com o modificador iniciando com uma classe com dois traços na frente, por exemplo o <div class="thumb-partner --large">. Não parei para debuggar também. Mas a idéia do BEM seria você adicionar a classe novamente junto com o modifier e nao deixar o modifier sozinho.

Ex: <div class="thumb-partner thumb-partner--large">

Curto muito o BEM. Trabalho com BEM e SMACSS.

[joaoahmad]

Não sou muito fan do BEM também não pelos motivos já citados. Curti bastante o RSCSS tanto que estou usando nos meus últimos projetos, mas confesso que sinto falta de separar o layout da aparência. Quanto a performance que o @wdss93 citou acho que se a regra é quanto mais específica a rule mais trabalho o navegador vai ter, de fato o BEM ganha do RSCSS, mas não acho que seja um problema.

[lagden]

@joaoahmad mas a perfomance do BEM da tapa na cara do RSCSS...
by the way o RSCSS só funciona com preprocessors!

A idéia do BEM é evitar o aninhamento, ou seja, melhor performance!

[joaoahmad]

Se da um tapa na cara não sei, nunca vi teste de perfomance entre eles... só penso pela teoria. Sabe de algum teste entre eles?

[lagden]

@joaoahmad

Fiz especialmente pra você!!!

BEM: http://cssstats.com/stats?url=http%3A%2F%2Flagden.github.io%2Fcss-test%2Fbem.html
RSCSS: http://cssstats.com/stats?url=http%3A%2F%2Flagden.github.io%2Fcss-test%2Frscss.html

Source: https://github.com/lagden/css-test

Refs

http://csswizardry.com/2014/10/the-specificity-graph/
http://cssguidelin.es/#nesting

https://css-tricks.com/efficiently-rendering-css/
#main-nav > li { } /* Slower than it might seem */

https://github.com/benfrain/css-performance-tests/tree/master/CSS%20Selectors

[joaoahmad]

É uma boa fonte de referência @lagden!
Sobre #main-nav > li { } /* Slower than it might seem */:
Mesmo sendo de 2010, tem um trecho que resume bem meu pensamento:

But you don't have to be all dogmatic about it. If you happen to be in the position where you need to eek out every last drop of performance out of a site and you have never considered this stuff before, it may be worth revisiting your stylesheets to see where you can do better. If you aren't seeing much rendering slowness in your site, then don't worry about it, just be aware for the future.

Queria saber de mais opiniões sobre, já que influencia diretamente em como escrevemos.

[lagden]

Então!!

Se você trabalha com um produto, por exemplo Spotify, com certeza a equipe vai adaptá-lo para ter a melhor performance possível!!

Mas se é um trampo de agencia, por exemplo Campanha da Coca e já acabou, então o próximo trampo iremos repensar! just be aware for the future

[felipefialho]

Então, tem essa questão de performance, eu também tento ao máximo utilizar classes ao invés de aninhar, por isso tive essa ideia de usar um duplo -- para variações.

Porém em determinados casos aninho elementos sem problemas (desde que até 3 níveis). Até porque essa a lógica do Atomic CSS que eu tanto gosto, ou seja, estruturas maiores, alterando atoms ou molecules menores.

Também não curto usar elementos sem classe, por exemplo .nav > li, sempre dou preferencia para classe .nav-item, até porque nunca sei se vou adicionar um elemento que não vai ter aquele estilo.

Porém em casos como, sei lá, .breadcrumbs, eu sei que nunca vai ter um outro li lá dentro que não seguir o padrão, então coloco ,breadcrumbs li sem medo algum, e o link ficaria .breadcrumbs a (e não .breadcrumbs li a).

Ou seja, como sempre, tudo depende do contexto.

[bernardodiasc]

Penso que esse caso do breadcrumbs ta tudo bem pois apesar de ser um componente genérico, é muito improvável que haja outros componentes dentro, e também possui uma estrutura de marcação simples, quase previsível.

Lembrando que CSS sem HTML é Claudinho sem Bochecha. Costumo incluir documentação sobre a marcação requerida junto com o CSS por causa disso. Um exemplo do HTML contendo as classes CSS num bloco de comentário perto das classes no arquivo CSS. Fica a dica.

Alguns casos usa-se apenas classes para que a marcação fique livre e o estilo possa ser aplicado independentemente dos elementos usados, é um cenário comum em frameworks css pois por exemplo aquele estilo de hyperlink pode tanto ser um a quanto um button, difícil pro CSS prever como vai estar o HTML. Mas nem sempre esse é o cenário, na verdade, em muitos dos sites, ficar com essa mentalidade de framework é perda de tempo já que os estilos muitas vezes são feitos sob medida.

[felipefialho]

Puts @bernardodiasc, sensacional essa ideia de incluir o HTML esperado dentro de um comentário no componente. Vou começar a usar \o

[brunoravanhani]

Depois de seguir o REM a risca fiquei com classes muito grandes, estava impossível manter no HTML, então parti para classes aninhadas, na semantica melhorou muito, não sei o quanto piorou a perfomance, Mas eu uso, mesmo sabendo das contra-indicações.

[schiehll]

@lfeh Mals ai a demora pra responder, to com um sprint loco aqui auhsas

Então cara, to nomeando da forma que mais faz sentido semântico pra mim. Aqui tem o ultimo projeto que fiz utilizando CSSModules: https://github.com/schiehll/events/tree/master/app/assets/styles

A estrutura de pastas e arquivos fica a critério de cada um, mas curti muito o fato de poder nomear as classes com nomes simples e semânticos sem medo de quebrar nada...e sem precisar ficar usando prefixo no nome das classes

[ghost]

Em relação à BEM, tem uma alternativa bem interessante na hora de usar os modifiers.
Aconselho que deem uma lida neste link: http://webuild.envato.com/blog/chainable-bem-modifiers/

[felipefialho]

Resgatando essa issue.

Acabei de postar uma sequencia de tuites e vou colocar aqui um resumo do meu raciocínio.

Basicamente eu comecei a adotar faz um tempinho -- para separar nome de conteúdo de nome blocos e - para separar os blocos. Estava dando certo.

.wellness--title
.wellness-container

Porém, em um projeto bem grande, com vários componentes que tinham nomes compostos ou eram muito complexos, estava ficando extremamente confuso.

.page-header-container

Então resolvi aplicar alguns conceitos do BEM, especialmente a ideia do __

.page-header__container

Mas só estou avançando nos níveis se extremamente necessário, isso ajuda a manter a sanidade do meu código.

Invés de

.page-header__container--title

Estou procurando usar

.page-header--title

O máximo que pode acontecer (aconteceu bem pouco, mas pode). São ter dois níveis de bloco.

.dashboard__header__main
.dashboard__header__aside

---

É um resumo do meu raciocínio.

O que acharam?

[paulinhoerry]

Achei bem interessante @lfeh
Eu particularmente não curto adotar essas nomeclaturas com -- e __
em projetos pessoais eu faço pela hierarquia do stylus mesmo

.page-header
 // code
 .title
  // code

Por mais que na última empresa em que trabalhei nós usávamos o SMACSS,
nos meus projetos pessoais eu ainda não encontrei uma razão pra deixar de usar dessa maneira.

[felipefialho]

@paulinhoerry, sempre gostei de seguir esse exemplo que você colocou. Mas tem um problema realmente chato nessa solução, que vem a tona com tudo em projetos grandes...

E se tiver mais de um .title filho do .page-header?

Nesse caso, era necessário começar a usar >, mas isso se tornava um grande problema quando não era filho direto. O componente começava a se tornar uma grande gambiarra.

[ghost]

Trello CSS Guide 😄

[williamcanin]

Até hoje, eu me confundo com nomenclatura em projetos grandes. Eu ainda prefiro usar o underscore __ , pois parece que separa melhor os blocos quando bate o olho, fica mais legível pra mim.

[mahenrique94]

Atualmente trabalho com SMACSS, BEM e Namespaces. Em meu blog pessoal comecei uma série de post's sobre organização, o último post será sobre a forma que eu uso.

Organizando seu código CSS parte 01.
Organizando seu código CSS parte 02

[nillswe]

Essa é uma dúvida que eu sempre tive. Normalmente acabo fazendo um mix de vários patterns, mas aí vira uma zona. Estou lendo os posts que o @lagden deixou e curti a ideia do SMACSS e do BEM mesmo que eu não goste de utilizar __.

[felipefialho]

Dois anos e meio depois, eu mesmo me respondo:

Estou usando CSS Isolado (no Angular ou CSS Modules) + BEM 😘

[nillswe]

Estou tentando usar o BEM, mas to achando meio estranho. Os nomes das minhas classses estão ficando muito grandes, em alguns casos esotu me deparando com classes do tipo .header_nav_dropdown_item_link. Eu que to fazendo zona ou é normal acontecer isso mesmo?

[felipefialho]

@niltonslf Nesse caso o lance é mais cuidar pra não ficar tão especifico. De repente

.header-dropdown__link

[nillswe]

@lfeh, to fazendo assim. Tá mto errado? Tem como dar uma força no que posso melhorar?
https://codepen.io/niltonslf/pen/zJogzw

[felipefialho]

@niltonslf No geral só deixaria menos verboso (talvez evitando essas classes com -).

Mas o caminho é esse mesmo, ta certinho.

[nillswe]

@lfeh Entendi. Brigadão aí pelo feedback!