CSS com lógica em 2026: por que tirei o tema e o estado do JavaScript e devolvi para o CSS

Resposta direta: em 2026 já dá para tirar boa parte da lógica de tema e de estado do JavaScript e devolver essa responsabilidade para o CSS, usando if(), @function e style queries. Aqui no Studio Seu eu faço isso em produção há alguns meses, sempre com um valor padrão seguro embaixo e a lógica nova por cima. O ganho não é estético, é operacional: menos código, menos bug de tema e entrega mais rápida.

Escrevo isso porque passei anos vendo o mesmo padrão nos projetos que herdei. Um site simples, bonito, com trinta linhas de JavaScript só para decidir se um botão fica claro ou escuro. Toda vez que a marca mudava de cor, alguém tinha que abrir o JavaScript. Isso sempre me pareceu errado, e finalmente o CSS tem as ferramentas para resolver.

O que mudou no CSS com lógica até 2026

Três coisas concretas destravaram esse caminho:

• @function, as funções personalizadas de CSS, chegaram no Chrome 139 em agosto de 2025, e hoje rodam em Chrome, Edge e Opera. Você define uma função com nome e argumentos, e ela devolve um valor calculado.
• if() chegou no Chrome 137, ainda em 2025, e trabalha com três tipos de teste: style(), media() e supports(). É condicional dentro da própria propriedade.
• Em 2026 o Safari Technology Preview 249 passou a testar if() e @function, junto com calc-mix(), wrap-inside e outline-offset: inset. É o sinal que eu estava esperando: isso não vai ficar sendo brincadeira só de Chromium.

Vale dizer o que ainda não é verdade, porque odeio post de tendência que esconde a parte chata: if() não é Baseline. Até meados de 2026 é Chromium, com Firefox em andamento e Safari com a coisa no roteiro para 2026 e 2027. Ou seja, é aprimoramento progressivo, não fundação.

@function: a peça que faltava no design system

Na minha experiência, @function é a novidade mais subestimada dos últimos dois anos. Antes eu resolvia escala tipográfica fluida e opacidade dinâmica com uma pilha de custom properties encadeadas que ninguém do time conseguia ler depois de três meses. Hoje eu escrevo uma função com nome, argumento e valor de retorno, e ela vira parte do vocabulário do projeto.

O efeito prático que eu não previa: melhorou a conversa com o cliente. Quando o design system tem uma função chamada --espaco-secao() em vez de um cálculo solto, dá para explicar a regra em uma frase, e a regra sobrevive à troca de quem mexe no código.

if(): condição dentro da propriedade

O if() resolve um problema bem específico: variação de valor por contexto. Um card que precisa de texto escuro quando o container está em tema claro, e claro quando está escuro. Antes isso virava classe extra, ou seletor duplicado, ou script. Com style query dentro do if(), o próprio componente pergunta em que contexto está e decide sozinho.

Aqui no Studio Seu eu costumo aplicar assim: escrevo primeiro o valor que funciona em qualquer navegador, e só depois coloco o if() protegido por @supports. Se o navegador do visitante não entende, ele fica com o padrão, que é bom. Nunca uso if() para nada estrutural, layout e leitura não podem depender de um recurso que metade do mundo ainda não recebeu.

Como isso muda o meu processo

Três mudanças reais nos projetos que entreguei este ano:

• Tema virou dado, não código. Trocar a paleta de um cliente deixou de exigir abrir arquivo de JavaScript. Isso encurtou revisão de marca de dias para horas.
• Menos JavaScript no primeiro carregamento. Cada bloco de lógica de estilo que sai do script é peso que não trava a página em celular ruim, e a maior parte do meu público no Brasil está em celular ruim.
• Componente mais honesto. Quando a regra de aparência mora no CSS do componente, o próximo profissional que abrir aquele arquivo entende a intenção sem caçar o script que sobrescreve tudo.

Onde eu ainda seguro a mão

Não uso if() em e-mail marketing, não uso em nada que precise de suporte garantido em navegador antigo de empresa, e não uso @function como única fonte de verdade dos tokens. Meus tokens continuam em um arquivo neutro, que exporta para código e para Figma, e o CSS consome. Trocar isso por lógica bonita e frágil seria um erro que eu já cometi em outra época com pré-processadores.

Perguntas frequentes

CSS com if() já pode ir para produção em 2026?

Pode, desde que como aprimoramento progressivo. Escreva o valor padrão primeiro e coloque o if() dentro de @supports. Assim nada quebra em Firefox ou Safari enquanto o suporte amadurece.

Qual a diferença entre @function e uma custom property?

A custom property guarda um valor. A @function recebe argumentos e devolve um valor calculado, podendo inclusive variar por media query. Na prática, uma é memória e a outra é raciocínio.

Isso substitui o JavaScript no front-end?

Não, e nem deveria. Substitui a camada de JavaScript que só existia para decidir aparência. Interação, dados e estado de aplicação continuam no seu lugar.

Vale reescrever um site atual para usar isso?

Na minha opinião, não vale reescrever por reescrever. Vale adotar no próximo componente novo e nas próximas trocas de tema, que é onde o retorno aparece rápido.

O que eu levo disso

Eu gosto de tecnologia que devolve simplicidade, não que adiciona camada. É por isso que essa geração de CSS me animou mais do que quase tudo que apareceu em 2026: ela deixa o site mais leve, o time menos dependente de mim e a marca mais fácil de ajustar. Um bom sistema é aquele que o cliente consegue mexer sem medo.

Se você tem um site que precisa de um programador toda vez que a marca muda de cor, isso é sintoma de arquitetura, não de orçamento. Me chama para conversar, eu gosto desse tipo de problema.