CSS é Lógica

Artigo original ↗ Discussão no Hacker News ↗

A reputação do CSS de ser “ilógico” é contestada por quem argumenta que ele segue regras consistentes, embora muitas vezes opacas, especialmente em torno de conceitos de layout como width vs. height, fluxo de documentos e dimensionamento baseado em porcentagens. Muitos comentários sugerem que o verdadeiro problema é a ferramenta inadequada, o peso histórico e modelos mentais enraizados em interfaces de aplicação em vez de documentos, o que faz recursos como especificidade, a cascata e seletores mais recentes parecerem pouco intuitivos. Alternativas e complementos como Tailwind, estilos com escopo por componente e variáveis CSS são apresentados como tentativas de lidar com essa complexidade, e não como evidência de que o CSS carece de lógica interna.

Debate sobre o que “lógico” significa

  • Muitos argumentam que “lógico” no sentido do artigo (“tem regras consistentes”) é trivial: qualquer linguagem de computador se qualifica.
  • Críticos dizem que a questão real é a usabilidade humana: CSS pode ser consistente e ainda assim ser confuso, desajeitado ou “uma merda”.
  • Outros distinguem “lógico” de “intuitivo”: CSS pode ser baseado em regras, mas frequentemente entra em conflito com os modelos mentais dos desenvolvedores.
  • Alguns comparam aprender CSS a aprender uma língua estrangeira ou vim: uma vez que você internaliza o modelo, ele parece lógico, mas não antes disso.

Comportamento de width, height e porcentagens

  • Vários comentários contestam a formulação do artigo “width olha para cima, height olha para baixo” por ser enganosa ou simplesmente errada.
  • Esclarecimento: width e height percentuais são ambos definidos em relação ao bloco contêiner; a confusão surge dos padrões:
    • Elementos de bloco têm como padrão width: 100%, mas height: auto (baseado no conteúdo).
    • Isso cria dependências circulares ao usar alturas percentuais dentro de contêineres cujas alturas dependem do conteúdo.
  • Usuários compartilham padrões como definir html, body { height: 100%; } para fazer height: 100% se comportar como esperado.
  • Alguns observam peculiaridades como padding/margin percentuais sempre se basearem na width, e padding-top se comportar de forma surpreendente.

Complexidade, opacidade e ferramentas

  • Vários argumentam que o CSS em si não é tão complexo, mas seu comportamento é opaco: as devtools não explicam por que uma regra “não funcionou”.
  • Melhorias sugeridas: depuração com passos pelo layout, visualização de especificidade e avisos para dependências cíclicas de porcentagem.

Documentos vs aplicações

  • Tema recorrente: o CSS foi construído para documentos de texto fluido, mas é amplamente usado para interfaces no estilo aplicativo.
  • Alguns dizem que recursos modernos (flexbox, grid, nesting, container queries) agora tornam layouts de app bastante viáveis, embora ainda sejam trabalhosos em certos casos (por exemplo, overflow centralizado, split views).
  • Outros gostariam de layouts baseados em restrições em vez de aninhamento profundo e configurações intrincadas de flex/grid.

Estratégias de estilo, Tailwind e especificidade

  • As opiniões se dividem sobre Tailwind: alguns o veem como uma opção pragmática para apps baseados em componentes; outros o consideram um “brinquedo” e hostil ao usuário para personalização.
  • Regras de especificidade e !important são amplamente citadas como fontes de comportamento não intuitivo e de gambiarras (por exemplo, repetir classes para superar seletores).
  • Alguns recorrem a variáveis CSS e calc() para reintroduzir uma sensação de “lógica” sistemática em seus estilos.