Dicas para estrutura CSS para sites de negócios (ou qualquer um para esse assunto)

CSS e HTML são simples de entender. No entanto, são necessários anos de prática para aprender sobre as melhores abordagens arquitetônicas ao criar sites (e aplicativos) de uma forma que os torne reutilizáveis ​​e manteníveis no futuro e mantenha os desenvolvedores felizes.

O que se entende por arquitetura aqui? É a estrutura do código CSS. A maneira como você o separa em arquivos, as regras por trás dos nomes de classe, a profundidade dos seletores, a forma como ele se espalha, o que é herdado, como você configura componentes, páginas, elementos e modificadores.

Aplicar as melhores práticas a todos esses componentes do site com centenas de páginas, vários tipos de conteúdo, exibições de tela, casos extremos e com a consideração de adicionar mais e modificar os existentes é a parte difícil.

Construa com componentes, não páginas

Esta é uma das partes principais a considerar. Você não deve estilizar com base na página em que está. Não crie estilos .homepage… {}. Se sua página tem uma seção, estilize a seção. Com isso, você pode reutilizá-lo em outras páginas também. Se você tiver um botão, defina o estilo do botão como .button {} e reutilize-o em outro lugar. É válido para todas as visualizações.

Este é o conselho mais comum e a abordagem de melhor desempenho (até agora) que você pode utilizar.

Agora, como você gerencia diferenças específicas da página? Porque esse é o motivo mais comum para estilizar por página? Bem, existem algumas abordagens:

Use modificadores.

Em “BEM”, o “M” significa modificador. Esta é a aparência do modificador .block__child. Mesmo se você não usar o BEM, os modificadores existem de qualquer maneira. Se houver uma variação para um componente ou seção, adicione um modificador para ele.

Idealmente, o designer deve ser cuidadoso e manter as variações ao mínimo para manter o código limpo, mas você não deve ter medo de adicionar mais a ele. Idealmente, as variações devem substituir apenas algumas propriedades e devem funcionar com a mesma marcação. É uma boa maneira de abordar os componentes na fase HTML - adicione as tags de que precisará e mantenha-as consistentes em todo o site. Não adicione novos por causa de uma classe modificadora.

Componentes de estilo infantil.

A outra abordagem é estilizar com base no contexto. Um botão é sempre um botão, tem sua classe .button e tudo mais, mas você ainda pode ajustá-lo se for parte de outro componente. Isso geralmente não é uma boa ideia, pois cria inconsistências, mas também é um caso de uso bastante realista. Do contrário, você acabaria com 20 modificadores com nomes estranhos.

Estilos contextuais são quando você estiliza um componente apenas se for filho de outro. Vamos pegar um cartão de artigo, por exemplo. Ele tem seus estilos por padrão. Mas se for parte de uma seção colorida com algum texto ao lado, o design requer que o cartão tenha alguns outros elementos ao seu redor (como formas animadas, etc.).

Nesse caso, você estiliza com o seletor .parent .card {}. Você só terá que substituir algumas propriedades como faria com um modificador. Quando você faz isso, o cartão em si não adiciona mais complexidade aos seus estilos, mas ainda se comportará corretamente naquele caso específico.

Quando você pensa sobre isso, você também pode ver como isso pode ser aplicado “por página”. Se houver alguns casos extremos estranhos no design e algumas pequenas diferenças das visualizações de componente padrão (e a maneira como todos eles interagem), você pode estilizar exatamente isso com o seletor .homepage {}. Lembre-se de usar isso com moderação. Em nossa experiência, esses estilos raramente excedem algumas linhas de código.

Observação importante a adicionar: estilos baseados no contexto NÃO são uma boa prática em geral. Idealmente, você nem deveria precisar disso. Na maioria das vezes, você teria modificadores que deveriam fazer o trabalho bem o suficiente. Mesmo que seja realista em algumas compilações, mergulhar muito fundo em um bom código abstrato com regras estritas pode ser muito caro.

Trabalho em Seções

A maioria dos sites de negócios (assim como muitos outros) separa o conteúdo em seções. Cada seção é um componente próprio com uma classe modificadora que define as várias propriedades. Uma sugestão para acompanhar a estrutura das aulas seria:

• section.section-container - este pode ser o “nome do componente” se você quiser, que contém os preenchimentos / margens consistentes ou o que for necessário.
• section.section-border-top - é um modificador. Isso não usa BEM, mas você pode "traduzi-lo" para a borda do contêiner da seção, se necessário.
• section.section-welcome - seria o nome da seção.

A convenção de nomenclatura novamente é irrelevante aqui. Com essas seções, você ganharia a liberdade de ajustar os estilos para componentes reutilizáveis ​​em casos extremos criados pelo projeto (seja devido a inconsistências que precisam ser seguidas ou apenas vistas mais complicadas).

Separação de arquivos

Muito provavelmente, você usaria Sass ou outro pré-processador semelhante. Em termos de separação de arquivos, existem muitas abordagens, mas a que adotamos segue a seguinte estrutura geral:

• Geral - Geral geralmente consiste em código de configuração como fazer uma grade funcionar, estilos para tags HTML, redefinições / normalizador, alguns estilos específicos de CMS e similares.
• Páginas - os estilos de página conforme explicado acima. Idealmente, você deve manter muito pouco código aqui.
• Componentes - o núcleo da construção - os vários componentes residem aqui. Uma dica é que você pode ter “elementos” ou “diversos” que caberiam em pedaços menores de componentes em um arquivo em vez de 80 arquivos. É claro que os maiores devem ir em arquivos separados.
• Layout - estilos globais, por exemplo, no cabeçalho, rodapé e layouts de página, modificadores para sua grade e assim por diante.
• Plugins - Qualquer coisa externa que seja gerada a partir de um plugin, extensão ou qualquer outro. É bom separá-los, pois você pode reutilizá-los em outros projetos.

Mantenha os seletores limpos

Um bom sinal de código limpo é sua aparência simples. Sem propriedades estranhas, tudo tem sua finalidade, há baixo recuo. Seletores de “aparência inteligente” quando desnecessários não estão tornando seu código “legal”. Se você puder substituir algo como #container> .row div [rel = ”something”] por .rel-something (imagine que é um nome de classe significativo), então você deve apenas atualizar um pouco a marcação. O objetivo disso é manter tudo mais simples.

Mantenha as indentações baixas. Raramente você precisa passar de três níveis. Vejamos, por exemplo, uma classe .entry:

.entry {...}
.entry-title {...}

Veja que não há realmente necessidade de indentar .entry-title dentro de .entry. Posteriormente, ao adicionar um modificador ao arquivo, você pode ter .entry-modifier {} e .entry-modifier .entry-title {}

Com essa abordagem, substituir estilos no futuro é muito mais fácil. Vamos dar uma olhada em outro exemplo comum: você tem a marcação de nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Agora, para estilizar, tudo que você precisa é:

.site-nav {} - componente 1

.list-menu {} - componente 2
.list-menu .list-item {}
.list-menu a {}

Se você tiver mais componentes internos, como menus suspensos adicionais, poderá aninhá-los diretamente dentro de .list-menu. Você não precisa escrever .site-nav .list-menu .list-item .dropdown {} (4 níveis de profundidade) quando você pode ter dois níveis de .list-menu .dropdown {}

Escreva mais nomes de classes abstratos para modificadores

Este vale para sustentabilidade. Um exemplo comum que você encontraria em postagens semelhantes seria não definir uma variável de cor como $ red, mas sim como $ primary ou $ secondary.

O motivo é que, quando uma mudança é necessária na linha, a variável $ red produziria azul. Faz muito mais sentido você querer mudar sua cor primária , não sua cor vermelha , certo?

O mesmo aconteceria com outros tipos de cores e propriedades. Digamos que você tenha linhas separando algum conteúdo (como a tag <hr>). Você nomeia esse .line-dash porque é tracejado. Faz todo o sentido. Mas então vem uma mudança e tem que ser pontilhada. Você vai e renomeia para .line-dotted? Este não é um modificador, é o componente. Em vez disso, você pode nomeá-lo como .line-separator. E, se você quiser ser específico, pode adicionar um modificador para .dotted ou .dashed. Esse tipo de nomenclatura geralmente é o que leva mais tempo durante a construção de um site.

Em suma

Existem inúmeras práticas boas e más. Uma forma de obter melhores resultados é definir regras e segui-las. É difícil criar tais regras, então uma boa sugestão seria navegar pela web e tentar reunir todas as informações possíveis sobre a arquitetura, como convenções de nomenclatura, boas práticas, como escrever código sustentável e muito mais.

Produzir um bom código leva muito tempo e centenas de milhares de linhas de código. Ao fazer tudo isso, sempre se pergunte “Será que essa escala?”, “Posso reutilizá-la?”, “Substituí muito?”, “Faz sentido nomeá-la assim?” Quanto mais você fizer isso, mais otimizadas serão suas decisões e mais sua velocidade de trabalho melhorará.

Um investimento em bons fundamentos resultará em menos idas e vindas em seus projetos e quaisquer mudanças futuras que precisem acontecer serão muito mais fáceis de implementar.