A mentalidade CSS

Ahh, CSS… Essa coisinha linda que dificilmente passa uma semana sem ser o tópico de uma discussão online mais acalorada. “É tão difícil”. “É muito simples”. “É imprevisível”. “Está desatualizado”… A questão é: você precisa de uma certa mentalidade CSS para escrever bons estilos.

Na verdade, é preciso uma “mentalidade” para codificação em geral, mas a natureza declarativa do CSS torna particularmente difícil de entender, especialmente se você pensar sobre isso em termos de uma linguagem de uma programação “tradicional”.

Outras linguagens geralmente funcionam em ambientes controlados, como servidores. Eles esperam que certas condições sejam verdadeiras em todos os momentos e, portanto, podem ser entendidas como instruções concretas sobre como um programa deve ser executado.

CSS, por outro lado, funciona em um local que nunca pode ser totalmente controlado, portanto, ele deve ser flexível por padrão. É menos sobre “programar a aparência” e mais sobre a tradução de um design em um conjunto de regras que comunicam a intenção por trás dele. Deixe espaço suficiente e o navegador fará o trabalho pesado para você.

Para a maioria das pessoas que escrevemos CSS profissionalmente, essa mentalidade CSS só vem naturalmente depois de um tempo. Muitos desenvolvedores têm aquele momento “Aha!”, quando as coisas finalmente começam a fazer sentido. Não se trata apenas de conhecer todos os detalhes técnicos; é mais sobre um senso geral das ideias por trás da linguagem.

Vejamos alguns destes.

Tudo é um retângulo

Isso parece óbvio, dado que box model é provavelmente uma das primeiras coisas que as pessoas aprendem sobre CSS. Mas imaginar cada elemento DOM como uma caixa é crucial para entender como as coisas funcionam com CSS.

É inline ou block? É um flex item (Flexbox)? Como vai crescer, encolher e será o wrap em diferentes contextos?

Abra as DevTools e passe o mouse sobre elementos para ver as caixas demarcadas ou use um utilitário de estilo como outline: 4px dashed hotpink; para visualizar seus limites ocultos.

A cascata é sua amiga

CSS. Cascading Style Sheets. Folhas de Estilo em Cascata. “Em cascata”. Cascata…

A Cascata é um conceito assustador no início da maioria dos devs, mas, quando usada corretamente, pode tornar a vida muito mais fácil. Entender é fundamental para a mentalidade CSS se incorporar ao seu ser.

A parte importante é saber quais estilos pertencem ao escopo global e quais são mais restritos a um componente.

Também ajuda a conhecer os padrões que são passados para evitar declarar regras desnecessárias.

“Tanto quanto necessário, o mínimo possível”

O objetivo é escrever a quantidade mínima de regras necessárias para alcançar a aparência necessária/pretendida. Menos propriedades significa menos herança, menos restrição e menos problemas com overrides.

Pense no que o seu seletor deve fazer essencialmente e tente expressar apenas isso.

Não faz sentido declarar width: 100% em um elemento que já é de nível de bloco. Não há necessidade de definir position: relative se você não precisar de um novo contexto de empilhamento (stacking).

Evite estilos desnecessários e você evitará consequências indesejadas.

Shorthands têm efeitos longos

Trocadilhos à parte, você deve saber que algumas propriedades CSS podem ser escritos em notação “abreviada” — as famosas shorthands. Isso possibilita declarar várias propriedades relacionadas juntas.

Embora isso seja útil, é importante ter em mente que o uso de shorthands também declara o valor padrão para cada propriedade que você não define explicitamente.

Escrever background: #fff; resultará efetivamente em todas essas propriedades sendo definidas:

É melhor ser explícito. Se você quiser alterar a cor de fundo, simplesmente use background-color.

Seja sempre flexível

CSS lida com uma grande quantidade de variáveis desconhecidas: tamanho da tela, conteúdo dinâmico, recursos do dispositivo etc.

Se seus estilos forem muito restritivos, é provável que uma dessas variáveis o atrapalhe. É por isso que um aspecto fundamental ao escrever um bom CSS é adotar sua flexibilidade.

O Erro Número 1 cometido por devs é assumir que as coisas sempre se parecerão com o modelo estático. Elas não vão. Tuitar isso

O macete é escrever um conjunto de instruções que seja abrangente o suficiente para descrever o que você deseja alcançar, mas flexível o suficiente para permitir que o navegador descubra por si mesmo como.

É por isso que geralmente é melhor evitar “números mágicos”. Números mágicos são valores rígidos aleatórios. Algo como:

Sempre que você se pegar apertando setinhas do teclado nas DevTools para ajustar algum valor, provavelmente você está diante de um número mágico.

Eles raramente são a solução para um problema de CSS, porque eles restringem estilos a um uso muito específico. Se as restrições mudarem, esse número ficará errado/inútil.

Em vez disso, pense no que você realmente deseja alcançar nessa situação. Alinhamento? Uma proporção? Distribuir quantidades iguais de espaço? Todos eles possuem soluções mais flexíveis.

Na maioria dos casos, é melhor definir uma regra para a intenção ao invés de usar hard-code para ela.

Contexto é a chave

Para ajudar na formação da sua mentalidade CSS, lembre-se dessa regrinha tão importante: contexto é a chave.

Para muitos conceitos de layout, é imperativo entender a relação entre elementos e seu contêiner. A maioria dos componentes são conjuntos de nós pai e filho.

Os estilos aplicados ao pai podem afetar os descendentes, o que pode fazê-los ignorar outras regras. Flexbox, Grid e position:absolute são fontes comuns de tais erros.

Quando estiver em dúvida sobre um elemento específico se comportando de maneira diferente do que você gostaria, olhe para o contexto em que ele está. É provável que algo em sua ancestralidade o esteja afetando.

O conteúdo sempre vai mudar

Sempre esteja ciente de que o que você vê é apenas um estado da UI em um espectro maior. Em vez de estilizar a coisa em sua tela, tente criar um “blueprint” do componente. Em seguida, certifique-se de que o que quer que você jogue ali não irá quebrar o estilo.

Strings podem ser mais longas do que o esperado ou conter caracteres especiais; imagens podem estar faltando ou ter dimensões estranhas/não planejadas. Viewports podem ser muito estreitas ou extremamente largas. Esses são todos os estados que você precisa antecipar.

O Erro Número 1 cometido por devs é assumir que as coisas sempre se parecerão com o modelo estático. Elas não vão.

Encontre Padrões e reutilize-os

Quando é preciso transformar um protótipo em código, geralmente é útil fazer um inventário dos diferentes padrões primeiro. Analise cada tela e fique atento ao apareça em mais de uma — pode ser algo pequeno como um estilo tipográfico ou grande como um determinado padrão de layout.

O que pode ser abstraído? O que é único? Pensar em peças de um design como coisas independentes/separadas ajuda a torná-las mais fáceis de serem racionalizadas e ajuda a traçar os limites entre os componentes.

Quando há times diferentes no desenvolvimento de um projeto, faz parte do dia-a-dia de quem vai codar a interface, é tarefa básica e inicial, receber as telas prototipadas e fazer este inventário.

Use nomes consistentes

Uma parte surpreendentemente grande da programação em geral é relacionada a escolher bons nomes para as coisas.

Em CSS, ajuda bastante escolher e manter uma convenção. Os esquemas de nomeação, como o BEM ou o SMACSS, podem ser muito úteis; mas, mesmo se você não usá-los, mantenha um vocabulário/nomenclatura padrão.

Conclusão

Todas essas dicas mostradas são importantes para ajudar a formar uma mentalidade CSS, mas sua experiência pessoal sobre o que mais importa também conta muito!

Todos esses foram “estalos”, aquela “ficha que caiu” para muitos desenvolvedores, mas para você pode ter sido diferente e você também ter conseguido chegar às mesmas conclusões em CSS.

E aí, qual foi seu momento “Aha!” que finalmente fez você entender CSS?