Afinal, como nomear IDs e CLASSes no CSS/HTML ?

Somos incentivados a usar UpperCamelCase para nomear classes em OOP, usamos lowerCamelCase nos nomes dos métodos, não podemos usar dash-case em nomes de variáveis (erro de sintaxe), por isso usamos underscore_case.. mas saindo do mundo backend, e voltando para o frontend, afinal, como nomear ids e classes no css/html ?

a

Escolha um e somente um, e use

lowerCamelCase, onde a primeira letra da palavra é minúscula e as inicias das demais palavras são escritas em letra maiúscula.
UpperCamelCase, o mesmo de cima, mas a primeira letra da palavra é escrita em maiúscula.
dash-case, onde as palavras são separadas por um hífen, e tudo é sempre escrito em minúsculo.
underscore_case, onde as palavras são separadas por underlines.
AlGoMuito_louco-eEsquisito, nem preciso falar nada ne?! não faça isso.

Mas o problema começa não só quando vc está nomeando uma variavel, objeto, id ou class. O problema existe quando um mesmo projeto possui estilos diferentes de codificação nele mesmo, portanto, padronize. Entre em um acordo com a sua equipe.

SMACSS – Scalable and Modular Arquiteture fore CSS

book-covers O http://smacss.com/ não é um framework css, é um guia de estilo.

Toda a teoria dele é muito interessante e eu recomendo a leitura. O foco deste post é apenas como eu venho nomeando meus ids e classes.

dash-case

Considero esse estilo mais próximo da linguagem css e html, do que os outros. As próprias propriedades css já são escritas em dash-case: text-decoration, data-*.. e assim por diante.

in english

Afinal não podemos mesmo usar acentos, algumas palavras são menores e queremos que qualquer pessoa possa dar manutenção em nosso código. É o caso, por exemplo de plugins, frameworks e snippets open source. As linguagens já são em inglês, então se o nosso código também for fica mais natural ler.

Pense em módulos

É comum quando estamos recortando layouts tableless, nos depararmos com partes da página que estarão presentes em mais de uma página. Por exemplo um box de depoimentos que pode existe na home e na página de preços de um produto.

O ideal é escrevermos um código html/css que possa ser copiado/movido de um lugar para o outro, sem que nada se perca e continue funcionando.

<ul id="comments">
    <li class="comment">
        <q class="comment-text">"lorem ipsum dolor sit amet..."</q>
        <cite class="comment-author">Desconhecido</cite>
    </li><!-- .comment -->
    <li class="comment">
        <q class="comment-text">"lorem ipsum dolor sit amet..."</q>
        <cite class="comment-author">Desconhecido</cite>
    </li><!-- .comment -->
</ul><!-- #comments -->

Só possuo um bloco de comentários por document, então uso ID para identificar esse bloco.
Cada LI é um .comment, e os filhos desse comentário, como o texto e o autor carregam o nome do pai neles: .comment-text e .comment-author.

Namespaces isolados

Ao batermos o olho no nosso css:

.comment {}
.comment-text {}
.comment-author {}

Sabemos rapida e exatamente quais classes se referem a esse módulo de comentários. O mesmo não seria possível se tivéssemos nomeado assim:

.comment {}
.text {}
.author {}

Afinal, podemos gerar um conflito de namespaces, pois se for uma página com CDs, a classe text poderia também estar identificando qualquer texto na página, e o author poderia ser o compositor.

Não estilize por filhos

Uma alternativa seria usar classes filhas:

.comment {}
.comment .text {}
.comment .author {}

O problema dessa abordagem é que estamos aumentando a especificidade do seletor, e se precisamos sobrescrever alguma propriedade, tudo começa a ficar muito verboso:

body.home .comment .author {}
body.price .comment .author {}

Além do que, se o .author for uma classe com poucas responsabilidades, podemos usá-la em diversos contextos, apenas somando classes:

<cite class="comment-author author"></cite>
<p class="music-author author"></p>

Não estilize pelo nome da tag

É comum termos preguiça de declarar classes no HTML, e sair fazendo coisas assim:

#comments li {}
#comments p {}
#comments cite {}

ou então:

.comment {}
.comment p {}
.comment cite {}

O grande problema, é que estamos vinculando o nosso css a um único html, e quando fazermos isso, estamos travando a implementação, o que é ruim, já que se formos apresentar um único comentário, não vamos usar uma LISTA para isso, mas sim uma DIV ou algo do tipo. Além de lento, pois devemos lembrar que os browsers lêem os seletores da direita para a esquerda.

Pense nos layouts que vc já implementou. Tudo começa a ficar mais complexo conforme o site cresce e mais módulos são adicionados, mais áreas precisam ser transpostas de um lugar para outro.. Dei um exemplo simples para ilustrar o conceito.

Quando usar ID e CLASS

Identifique um elemento com ID quando ele for único em uma página, e não existir nenhuma possibilidade de ter outro igual a ele, como por exemplo o #header e o #footer do site.

Identifique um ou mais elementos com CLASSes quando estiver pensando em módulos reaproveitáveis, em estilos que podem ser somados, como por exemplo:

<a href="" class="btn btn-hire btn-big">Contratar</a>

Estou somando classes para compor o meu elemento. Se eu precisar desse botão em um tamanho menor, apenas troco uma classe no html, ou se eu quiser ele em outra cor, eu apenas adiciono outra class class=”btn btn-submit btn-medium”.

Nomeie pela função

Não escolha nomes que estejam vinculados aos estilos de um seletor. Estilos mudam, assim que layouts se alteram. Escolha nomes que representem o que aquele seletor é na página, ou o que ele faz.

O que faz ?

Por exemplo, .btn-green e .btn-orange são nomes ruins, pois carregam cores que podem ser alteradas. Melhor seria se esses nomes de classes descrevessem o que aquilo faz, como: .btn-hire e .btn-submit. Assim sabemos que possuimos uma classe que cuida de todos os botões de contratar do site e outra para cuidar dos botões de enviar formulários.

Dessa forma, podemos altera a vontade os estilos sem que o nome do seletor deixe de fazer sentido.
Vale a pena dar uma lida sobre a teoria OOCSS.

O que é ?

Outra má prática, é nomear de acordo com a posição do elemento na página: #column-left, se algum dia essa coluna deixar de ser coluna ou mudar de lado, além de alterarmos alguns estilos no css, teríamos também que alterar no html, pois não faria sentido esse nome.

Nomeie pelo o que o elemento é. Esqueça coisas como posição, cor e tamanho. Se é uma coluna adicional ao conteúdo, não importa onde ela está, é uma #sidebar, #aside.. algo do gênero.

Devemos conseguir distinguir o que um elemento é, sem ler ou ver o conteúdo dele. Apenas batendo o olho na tag e no seletor que ele possui.

Google Style Guide

Uma indicação de leitura complementar:
CSS Style Rules

Conclusão

Para ter um código mais fácil de ler, mais simples de dar manutenção, com seletores mais rápidos, desenvolvido em módulos encaixáveis em qualquer página e independente da marcação html, é que eu nomeio os meus IDs e classes desta maneira.

E ai ? gostou desse estilo ?

23 Comments

  1. SMACSS é tudo de bom.

    Até comprei o livro deles. Na prática dá para usar a teoria só com o que já se tem no site do SMACSS, o livro serve mais para reforçar com exemplos e estudos de uso.

  2. Ótimo post Bruno, eu só pediria para você argumentar o o porque prefere desenvolver utilizando a lingua inglesa como padrão. Em que isso beneficia a aplicação e os desenvolvedores.
    Abs.

    • Oi Tiago, prefiro em inglês por estes motivos:

      1. as linguagens já são em inglês
      2. inexistencia de acentos (sabemos q não podemos criar variáveis acentuadas)
      3. internacionalização (se eu lançar algum componente pessoas de outros países tb podem usá-lo. Assim como já recebo visitas de outros países no meu blog)

      E também para “treinar”. =)

      • Opa Bruno, nos últimos projetos eu tenho tentado mudar essa minha prática, já que escrevo tudo em português. Está sendo bem difícil me acostumar. O que tenho maior dificuldade é a parte conceitual do inglês/português. Na verdade a verbalização. Uma palavra no inglês pode significar várias em português e vice versa. Imagine que tem uma seção no seu site de clima, como você daria o nome para essa classe: climate, clime, time, weather, etc…elas, no frigi dos ovos, porem siginificar a mesma coisa pra nós, mas talvez não para o norte americano. Então há essa preocupação em colocar a palavra certa no lugar certo. Eu ainda tento generalizar, não criar o nome de classe de acordo com o conteúdo dela, pois sempre caio neste mesmo impasse. Uma situação real agora é que um site tem uma seção chamada “depoimentos” que no inglês pode ser testimony, evidence, attest a depender do contexto. Mas se por exemplo esta seção deixa de ser depoimentos e vira galeria de imagens, minha classe foi pro espaço tendo que recriar tudo. Deixar como o nome genérico também é bem difícil, como talvez bloco-a ( o que não diz nada )… Qual a sua sugestão para estes casos?

      • Nesse caso Tiago, é muito difícil que vc precise mudar de depoimentos para galeria de imagens, sem que realmente o layout se altere.
        Ai é outra coisa mesmo, vai ter que recriar. É um módulo que saiu e outro que entrou. Não se preocupe em nomear de forma genérica.

  3. E sobre definir a classe atrelando ao elemento que ela é:

    li.comment {}
    q.comment {}
    cite.comment {}

    O que pensa a respeito?

    • Eu comentei de algo parecido com isso Lucas, eu acho ruim. E nesse caso que vc mostrou, é ainda pior.
      Por que vc está vinculando tua folha de estilos a um só html, e as tuas classes não dizem o que são.

      Isso faz com que sua implementação fique travada, e se a tag mudar ? ai tem q mudar no css tb ? Isso seria errado.
      Separamos css do html, lembra ?

      Para fazermos um css mais eficiente e mais reaproveitável, o único lugar em que podemos usar tags como seletores, é no reset, logo no início do projeto. Depois nunca mais devemos declarar seletores com nome de tags.

  4. Muito bom o texto, apesar de ter alguns erros de otimização de CSS, principalmente “e se precisamos sobrescrever alguma propriedade”, não se deve fazer isso.

    • Perfeito Gabriel, mas as vezes é necessário. Como por exemplo quando trabalhamos com layouts responsivos.
      Sobrescrevemos propriedades a cada breakpoint, e não há como dizer que isso é um crime, ou que isso vá piorar muito o repaint da página.

      O ponto é realmente entender quando e como usar o que temos em mãos.

  5. João Pedro Costa

    maio 29, 2013 at 10:00

    Muito bom o artigo. É muito difícil organizar CSS, muito por causa da falta de uma padronização forte de estilística. Qualquer iniciativa nesse sentido é muito bem-vinda. Mas eu peço licença para explicar umas coisas que eu faria diferente.

    Com relação a usar os nomes das tags como seletores, existem alguns casos aconselháveis. Por exemplo, não faz sentido sair marcando cada tag “a” com um ID ou classe redundante como “.link”. É melhor estilizar pelo nome mesmo.

    Considerando a questão namespaces X estilização por filhos, eu iria muito pela segunda. Eu sei que existem questões de performance relacionadas, mas somente a segunda prática apresenta o benefício do cascateamento, que é central nas CSS. Por exemplo, uma classe genérica como “error” pode ser utilizada em várias situações. Seria um tanto contraproducente sair especificando várias classes — como .comments-error, .main-error, etc. — só para mostrar texto em cor vermelha, por exemplo. Poder-se-ia declarar uma regra para a classe “error” com a cor vermelha e, caso se precise especificar, pode-se usar um seletor de um elemento pai.

    Além disso, a notação de namespaces não é legal para separar as coisas. Explico. Em “.comments-message-box”, o namespace é “comments” ou “comments-message”? Há dois namespaces aqui? Por fim, essa notação pode ser menos verbosa no CSS, mas isso vem à custa de verbosidade no HTML. E se você um pré-processador (LESS, SASS, Stylus), essa dificuldade acaba virando uma vantagem.

    Pra terminar, eu diria mais no sentido de usar IDs ou classes. As CSS são usadas em dois sentidos: layout e estilização. Quando a ideia for identificar partes do layout, use IDs. Elementos de layout tendem a ser únicos. No exemplo que você deu, “#header” e “#footer” são claramente elementos de layout. Obviamente, isso não é uma regra escrita em pedra, mas é útil.

  6. ótimo post, parabéns!

  7. Ótimo post. ja seguia alguns conceitos, mas definitivamente tem coisa nova ai para eu poder me guiar e melhorar minhas folhas de estilo.

    Parabéns pelo seu trabalho Bruno, acessei seu site poucas vezes, mas até agora o conteúdo tem sido muito bom.

  8. Carlos Negão

    maio 29, 2013 at 21:30

    Pessoal, chega de mimimi, o ideal é utilizar camelCase nos estilos (ponto), fica mais arrumado. Fazer li.comment {} é um golpe de facão no juízo, pra que isso, é muito mais simples a utilização de .comment li {}, fica muito mais visível como caminho em relação ao primeiro. O post foi legal, mas tem muito explicação blá-blá-blá. Uma dica (pra quem quiser seguir), tente fazer o html um mais simples e sem emaranhados possíveis, seja claro com a marcação html (O Google vai agradecer).

    • Carlos, “fica mais arrumado” na opinião de quem ? tipo vc só usou argumentos inválidos.
      A idéia do post, é mostrar como modularizar, tente abrir a sua cabeça e entenda o que foi dito =)

      • Carlos Negão

        maio 30, 2013 at 00:35

        Tá bom, William vou mandando os códigos pra vc, daí vc opina 😉 e verá o que estou tentando dizer. Argumentos válidos sim. O “mais arrumado” acredito que alguém que está lendo este post entendeu. Se não entendeu VÁ À MERDA

  9. Dá até dó de pessoas como esse Carlos Negão…

  10. E o nome das imagens, como você utiliza. No inglês ou português, tudo junto ou separado por hifen ou underline?

    • Eu uso o nome das imagens em português sem acento e separadas por hífen. Descrevendo ao máximo oque cada imagem é.
      Isso por questões de SEO. (logicamente tb preencho o atributo alt)

  11. Will otima materia. Curti muito.

  12. Muito obrigado por compartilhar o post! Realmente muito bom! Parabéns!

Deixe uma resposta

Your email address will not be published.

*