Desde as primeiras linhas do código, cada pessoa começa a entender a importância de organizá-lo corretamente e otimizar o espaço de trabalho como um todo.
Não é importante de qual setor falar especificamente, mas é importante entender que onde quer que exista código, deve haver regras para sua criação e armazenamento.
No primeiro casal, é claro, pode parecer que aderir a certas regras e ordens leva apenas tempo, o que na prática parece completamente diferente. A quintessência de qualquer princípio de escrever código é que não o escrevemos de uma vez por todas - voltamos constantemente a ele com o objetivo de editar e modificar.
Esse processo pode se transformar em um problema real se o caos e a imprevisibilidade reinarem ali. Esse problema pode ser agravado se esse caos não tiver sido criado por você, mas por uma pessoa com a qual não é possível estabelecer contato. É para eliminar tais situações que existem metodologias.
Se falamos sobre css, podemos dizer com confiança - cada um de nós usa uma certa metodologia, consciente ou não. Mesmo que uma pessoa não use certas regras e padrões, ela ainda tem seus próprios hábitos e constantemente repete truques.
As formas de escrever código não precisam ser geralmente aceitas e padronizadas; outra coisa deve ser obrigatória - elas devem ser previsíveis.
A lista de metodologias às quais você deve prestar atenção não é tão longa:
-BEM,
-Smacss,
-OOCSS,
-MCSS,
CSS atômico
O CSS atômico é talvez a metodologia mais incomum e até um pouco assustadora, que felizmente não impede que seja muito compreensível e previsível.
Para fundamentar minha escolha, tenho que retroceder um pouco.
CSS quase atômico
Houve momentos em que o diretório raiz do grande número de projetos no estágio de criação da interface parecia três arquivos e duas pastas:
>fonts >img -index.html -style.css -script.js
Mas essa simplicidade pode parecer enganosamente conveniente, de fato, pelo menos em dois desses três arquivos algo terrível estava acontecendo.
Duas coisas sempre me incomodavam - bagunça e falta de estilo. Em Css, muitas nuances diferentes se enquadram na classificação de desordem, mas acima de tudo, não fiquei feliz com a repetição constante das mesmas regras e propriedades para diferentes seletores.
A primeira solução para esse problema foi a seguinte:
- criando um arquivo chamado "reutilize.css",
- criação de instruções neste arquivo, que em teoria podem ser necessárias para mais de um seletor,
- adicionando seletores diferentes à mesma instrução.
Parecia assim:
... .class { display: inline-block;} .class { text-transform: uppercase;} ...
e posteriormente aceitou o seguinte:
... .menu-link, .primary-button, .form-button, .footer-link, .social-link { display: inline-block;} ...
Obviamente, essa solução foi muito inconveniente e felizmente temporária. Não muito tempo atormentado com a alternância interminável entre arquivos, e encontrando o lugar certo neles, cheguei à conclusão de que seria muito mais conveniente criar classes separadas que são responsáveis por uma instrução cada:
...
.inline-block { display: inline-block;} .block {display: block;} .uppercase {text-transform: uppercase;}
Nos arquivos html, as tags com um grande número de classes pareciam estranhas, mas essa solução me pareceu bastante aceitável:
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>
De relance, basta entender que esta é uma coluna lateral, com posicionamento fixo, no lado esquerdo da tela, ocupando 30% de sua largura e 100% de sua altura, preenchida com a cor principal.
Tudo o que se relacionava com valores numéricos, principalmente estes eram recuos externos e internos, escrevi no formato padrão. Para fazer isso, adicionei uma classe separada que vem primeiro a cada tag ou grupo de tags, no exemplo acima, é a classe "slider".
Era uma abordagem quase atômica e quase conveniente. Várias deficiências impediram que ele se sentisse confortável, sendo as mais importantes as seguintes situações:
- ao criar um grande número de tags semelhantes, por exemplo, itens de lista, tive que copiar muitas classes e parecia complicado,
- ao fazer alterações, tive que excluir e adicionar classes para cada elemento separadamente,
- havia muitas classes não utilizadas que eram difíceis de capturar.
E então duas coisas vieram ao resgate que ajudaram a resolver todos os problemas - este é o pré-processador e o mecanismo de modelo.
Com a ajuda deles, modifiquei minha metodologia e tornei o layout agradável e conveniente.
CSS quase perfeito
Vou começar com o pré-processador. Sua escolha não é fundamental; primeiro usei o Sass, depois o SCSS e, finalmente, mudei para o Stylus, porque respeito o minimalismo, e o Stylus era o mais minimalista possível (o scss será usado nos exemplos abaixo, devido à sua popularidade).
Então, a primeira coisa que fiz foi escrever classes adicionais que pareciam átomos reais usando a diretiva @extend:
.flex { display: flex; flex-wrap: no-wrap; } .flex-jc-center { @extend .flex; justify-content: center; } .flex-ai-center { @extend .flex; align-items: center; }
Gostei da ideia e a diretiva @extend causou uma semelhança com o núcleo atômico, próximo ao qual havia instruções adicionais.
Decidi que a idéia deveria ser desenvolvida e criei um arquivo separado para os organismos. Organismos que chamei de classes que incluem várias diretivas @extend:
.header { @extend .fixed; @extend .w-100; @extend .main-fill; @extend .left; @extend .top; @extend .flex-ai-center; @extend .z-top; }
Tendo criado um pequeno “zoológico” de vários organismos, decidi fazer algo com classes que exigem valores numéricos para identificação e tamanho.
Os recursos do pré-processador me ajudaram a lidar com isso novamente, com a ajuda da qual escrevi algumas funções e adicionei variáveis.
Primeiro, estudei em detalhes os projetos gráficos que recebo dos designers e revelei vários padrões:
- número de cores para cada projeto,
- número de fontes
- número de tamanhos diferentes para texto e títulos,
- recuo repetido (para seções, botões, etc.)
O primeiro passo foi escrever funções e mixins para criar as classes necessárias:
// px em @function em($pixels, $context: $browser-context) { @return #{$pixels/$context}em };
// $text-size: ( l: 18, m: 16, s: 14, xs: 12 );
@mixin emFonts($list, $n) { // $list – , n – . @each $status, $size in $list { // - &-#{$status} { font-size: em($size - $n); // } } }
Agora podemos chamar essa combinação de mixins e funções em qualquer lugar conveniente para nós:
.txt { @include emFonts($text-size, 0) }
E na saída temos 4 classes para textos de tamanhos diferentes:
.txt-m { font-size: 1.125em; } .txt-s { font-size: 1em; }
Da mesma forma, funções para tamanhos de cabeçalho, cores de texto e preenchimento, fontes etc. são criadas e chamadas.
Ou seja, o trabalho em cada projeto começa com o preenchimento dos valores para as variáveis, e as próprias classes e funções migram de um projeto para outro.
Mecanismo de modelo.
Eu acho que muitos de vocês usam modelos, e provavelmente esse é o Pug (anteriormente chamado de Jade).
Para tipografia atômica, é necessário graças a três coisas:
O Pug nos salva completamente de microclasses pesadas de código HTML, pois podemos ativar o seguinte código:
… <ul class=”menu__list flex-ai-center w-100 relative “> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>first</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>second</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>third</li> </ul>
conveniente para edição:
-let menuItemClasses = 'menu__item m-color m-font txt-s inline-block bold-border' // ul li(class=`${menuItemCLasses}`) frst li(class=`${menuItemCLasses}`) second li(class=`${menuItemCLasses}`) third ... </ul>
ou em outra modalidade, usando um loop:
let menuItems = ['first', 'second', 'third'] ul -for(let item of menuItems) { li(class=”menu__item m-color m-font txt-s inline-block bold-border”) -}
Isso não é menos conveniente, porque a linha com as classes necessárias não se repete mais de uma vez.
A última vulnerabilidade dessa metodologia foi que um grande número de classes não utilizadas permaneceu no código. Mas esse problema aparentemente sério foi resolvido facilmente adicionando plug-ins ao construtor de projetos que removem classes desnecessárias.
Conclusão
Concluindo, gostaria de dizer o seguinte:
Antes de começar a usar a “metodologia quase atômica”, usei o smacss e depois o BEM por um longo tempo. Como resultado, deixei apenas os nomes das classes que exigem descrições de travessões e tamanhos e a hierarquia de armazenamento de arquivos e pastas. Um conjunto de classes e funções prontas, eu me conecto ao projeto como uma biblioteca.
Um ponto importante que eu gostaria de observar é a conveniência do layout das páginas e de suas seções individuais como um todo. Graças às microclasses, é fácil criar um "esqueleto" de uma página ou seção no mecanismo de modelo e só então escrever estilos para ela.