Existem muitas metodologias CSS por aí, e eu odeio todas elas. Alguns mais (vento favorável e outros) e outros menos (BEM, OOCSS, etc.). Mas no final das contas, todos eles têm falhas.
As pessoas usam essas abordagens por bons motivos, é claro, e muitos dos problemas abordados são aqueles que também encontrei. Portanto, neste post, gostaria de escrever minhas próprias diretrizes sobre como manter o CSS organizado.
Esta não é uma metodologia CSS totalmente descrita que qualquer um poderia começar a usar. Talvez pudesse ser transformado em algo com algum trabalho extra, mas o objetivo deste post é simplesmente mostrar como tomo essas decisões ao escrever CSS.
Como regra geral, tento usar tipos de elementos integrados tanto quanto possível e com o mínimo de detalhes extras possível.
Ter a necessidade de mil tipos diferentes de botão é um sinal de que pode haver algo errado com o design em um nível mais profundo, então, embora em alguns casos eu perceba o apelo do CSS ser inerte até que classes específicas da estrutura sejam usadas , na maioria dos casos considero ideal quando um botão é apenas e se parece com um botão sem qualquer mágica adicional.
div.btton deve se transformar em botão
Nem todos os elementos de design possuem um equivalente HTML semanticamente adequado e, nesses casos, costumo recorrer a elementos personalizados.
Não vi muitos casos de nomes de elementos personalizados sendo usados sem nenhum javascript de acompanhamento, mas provou ser uma escolha surpreendentemente sólida para escrever HTML claro que também tenha a aparência que desejo.
Elementos totalmente separados em termos de design também têm maior probabilidade de, com o tempo, desenvolver requisitos que só podem ser implementados com JavaScript, o que deixa você com um caminho claro para implementar aqueles que não precisam de alterações no HTML nem o CSS.
div.vsep deve se transformar em separador vertical
As classes devem funcionar como modificadores do nome do nó existente, em vez de tipos de elementos inteiramente novos, e geralmente têm efeitos semelhantes, mas diferentes, em diferentes tipos de elementos.
Um botão perigoso é um botão.perigo
Algumas maneiras de modificar elementos não são simples interruptores liga/desliga para os quais as classes são úteis, mas se comportam mais como pares de valores-chave.
Nesses casos, atributos personalizados com seletores correspondentes provaram ser a melhor opção quase sempre que os usei. Ao contrário das classes hifenizadas, elas mostram em nível de sintaxe qual é o atributo e qual é o valor, tornando mais fácil para os editores destacá-los, mais fácil para o olho humano analisar rapidamente e mais fácil de fazer interface usando JavaScript.
Para aqueles de nós que ainda têm esperança de que a função attr() possa um dia chegar ao CSS para mais do que apenas conteúdo, esta também é uma camada extra de proteção para o futuro.
IDs são, por definição, únicos dentro do documento. Como tal, qualquer regra direcionada a um ID específico será limitada e poderá exigir refatoração se mais tarde se descobrir que, afinal, deveria haver mais de um elemento desse tipo no lage.
Como tal, os IDs devem ser usados com moderação e somente quando não faz sentido ter mais de um elemento em um documento.
Os benefícios sobre as classes, tanto no sentido prático quanto de legibilidade, são bastante pequenos, portanto, errar por parte das classes geralmente é a melhor ideia quando nenhuma relação clara de 1 para 1 entre elemento e estilo pode ser identificada.
Qualquer aplicativo do mundo real, em algum momento, terá elementos que simplesmente requerem ajustes individuais para torná-los mais esteticamente agradáveis no contexto em que aparecem.
Nesses casos, o atributo style é o caminho a percorrer. Qualquer razão pela qual usá-lo é considerado uma má prática se aplica a qualquer tipo de estilo embutido, incluindo classes utilitárias. O problema não é o atributo, é misturar estilo e marcação.
A única diferença entre estilo e classe para estilos inlining é que um indica o propósito, permite o uso de CSS simples e é praticamente universal, enquanto o outro não é.
Simplificando, width: 100px tem um significado universalmente definido, enquanto .width-100 pode significar qualquer coisa.
Em ocasiões muito raras, os estilos específicos de elementos ficam tão complexos que inlinhá-los explicitamente prejudicaria a legibilidade ou seria até mesmo impossível (por exemplo, se exigir consultas de mídia).
Nesses casos, as classes utilitárias são basicamente a única opção, mesmo que sejam feias.
Em um mundo ideal, eles poderiam ser tratados separadamente de classes específicas de mixin, e até considerei usar prefixos para diferenciá-los mais facilmente, mas no final das contas não encontrei uma boa maneira de fazer com que não fossem feios.
Gosto da ideia de prefixar classes de utilitários com a para representar que elas adicionam algum tipo de funcionalidade ao elemento, em contraste com classes normais, que especificam que tipo de elemento é.
E foi isso. É claro que não existem dois projetos iguais e, às vezes, as regras precisam ser um pouco alteradas para permanecerem práticas, mas, no geral, essa é a minha estrutura para decidir como fazer com que algo na tela tenha uma determinada aparência.
Quais são seus pensamentos? Você odeia isso? Você acha que faz sentido? Deixe-me saber em um comentário?
Isenção de responsabilidade: Todos os recursos fornecidos são parcialmente provenientes da Internet. Se houver qualquer violação de seus direitos autorais ou outros direitos e interesses, explique os motivos detalhados e forneça prova de direitos autorais ou direitos e interesses e envie-a para o e-mail: [email protected]. Nós cuidaremos disso para você o mais rápido possível.
Copyright© 2022 湘ICP备2022001581号-3