Função CSS random() dispensa JavaScript e Sass para efeitos aleatórios

Interfaces perfeitamente alinhadas têm um efeito colateral: ficam sem vida. Grades fechadas, tokens de espaçamento rígidos e tipografia idêntica pixel a pixel garantem previsibilidade, mas é exatamente essa previsibilidade que faz muita tela parecer saída do mesmo molde de design gerado por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → sem direção. O front-end↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → developer Brecht De Ruyte, da Bélgica, levanta esse incômodo em artigo no Smashing Magazine e usa a nova função nativa random() do CSS para testar onde a imperfeição controlada cabe num design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → sem virar bagunça.

O ângulo interessa a quem desenha produto porque resolve um atrito antigo: até agora, qualquer efeito "aleatório" no front (cartões levemente tortos, letras com variação sutil, blur tipo bokeh) exigia gerar centenas de linhas de CSS estático num loop Sass, ou subir uma dependência JavaScript só para calcular um ângulo ou uma duração de animação. Com random() direto na folha de estilo, esse cálculo fica embutido na própria linguagem.

Como a função funciona na prática

A especificação formal é random(<random-caching-key>?, <min>, <max> [, by <step>]?), mas no uso real os argumentos entram direto, separados por vírgula:

/* Ângulo aleatório entre -3deg e 3deg */
rotate: random(-3deg, 3deg);

/* Largura aleatória entre 20px e 80px, em passos de 10px */
inline-size: random(20px, 80px, 10px);

Duas regras importam para quem só mexe em CSS no dia a dia. Primeiro, mínimo e máximo precisam ser da mesma unidade (não dá misturar rem com px direto; é preciso resolver isso com calc() antes). Segundo, o terceiro argumento opcional (o step) arredonda o resultado para incrementos fixos: random(0px, 60px, 15px) só produz 0px, 15px, 30px, 45px ou 60px, útil quando a variação precisa cair num grid.

O recurso mais relevante para quem pensa em sistema, e não em efeito isolado, é a chave de cache. Por padrão, cada vez que random() é avaliado numa propriedade, ele gera um valor independente. Isso quebra qualquer coisa que precise de dois valores sincronizados, como largura e altura de um cartão que precisa continuar quadrado:

.card-thumbnail {
 inline-size: random(--square-size, 60px, 120px);
 block-size: random(--square-size, 60px, 120px);
}

Como as duas declarações referenciam a mesma chave --square-size, o navegador compartilha o valor computado entre elas. Sem a chave, o cartão vira um retângulo torto a cada refresh; com ela, o quadrado se mantém perfeito, só muda de tamanho.

Os experimentos que mostram onde isso cabe

Para testar os limites do recurso, De Ruyte construiu uma série de demos no CodePen que valem como catálogo de referência para quem decide se random() entra num projeto real:

• Tipografia imperfeita: cada letra de uma palavra recebe rotação, deslocamento e opacidade levemente diferentes, imitando a irregularidade de uma impressão tipográfica antiga; no hover, tudo volta ao alinhamento perfeito via transição.
• Salto procedural: letras quicando com altura, duração e atraso de animação únicos para cada caractere, usando animation-delay negativo para que todas já estejam em movimento no carregamento da página.
• Cartões inclinados: --tilt e --shift-y aleatórios, com a sombra calculada em função do próprio ângulo de inclinação, para o cartão parecer fisicamente apoiado sobre a mesa.
• Baralho em leque: combina sibling-index() (matemática determinística, para o leque abrir igual não importa quantos cartões existam) com random() (a imperfeição humana de quem embaralhou o baralho), tudo amarrado a animation-timeline: scroll(root).
• Velocidade de marquee: random(15%, 44%) define a velocidade de cada linha de texto que desliza na tela, sem JavaScript calculando transformação por scroll.

Randomness in CSS doesn't have to mean throwing your design system out the window. It's about little imperfections and playfulness. Maybe let's even call it fun.

Randomness in CSS doesn't have to mean throwing your design system out the window. It's about little imperfections and playfulness. Maybe let's even call it fun.Brecht De Ruyte, front-end developer

O que isso substitui: loop de pré-processador e biblioteca JS

Antes de random(), simular essa mesma inconstância exigia um de dois caminhos. Um era escrever um loop Sass que gerasse, em tempo de build, dezenas ou centenas de classes .char-1, .char-2, .char-3 com valores fixos pré-calculados: resolve o efeito, mas infla o CSS final e trava o número de variações no momento do build. O outro era subir uma biblioteca JavaScript (ou escrever Math.random() à mão) para computar o ângulo em tempo de execução e injetar como estilo inline, o que soma peso de bundle e um ponto a mais de JS rodando só para um detalhe estético.

Com random() nativo, esse cálculo acontece no próprio motor de renderização do navegador, sem build step e sem runtime JS. Para quem decide arquitetura de front, isso significa menos dependência para manter, menos CSS gerado estaticamente e a possibilidade de reavaliar o valor a cada repaint, algo que nenhum loop de pré-processador conseguia fazer.

O cuidado que separa efeito bacana de acessibilidade quebrada

Quebrar uma palavra em <span> por letra para estilizar cada caractere individualmente tem um efeito colateral sério: leitores de tela costumam soletrar, lendo "i - m - p - e - r - f - e - i - ç - ã - o" em vez da palavra inteira, ou pausando de forma estranha entre cada letra. É o tipo de problema que só aparece quando alguém testa com tecnologia assistiva, não quando se olha só a tela.

A correção é simples e deveria entrar como item de definição de pronto em qualquer componente que use esse padrão: os spans visuais ficam marcados com aria-hidden="true", e o elemento pai recebe um aria-label com a palavra completa e limpa. Quem usa leitor de tela ouve a palavra normalmente; quem enxerga vê a variação tipográfica. Não é um detalhe opcional, é parte do que torna o efeito publicável.

Quando random() não é a resposta

O próprio De Ruyte reconhece que a maior parte do trabalho de um design engineer é o oposto disso: espaçamento consistente, tipografia travada, grid alinhado. Um cartão de dashboard que pula alguns pixels a cada refresh não é expressão criativa, é bug que alguém vai reportar. Random() faz sentido em contextos específicos:

Sobre suporte de navegador: o Safari foi o primeiro a entregar random(), o Chrome está em processo de lançamento na versão 156, e a Mozilla já sinalizou intenção positiva de implementar no Firefox, sem data confirmada. Enquanto o rollout não está completo, a recomendação é envolver o uso em @supports (rotate: random(-2deg, 2deg)), com um valor fixo como baseline fora do bloco.

Fica pendente ainda random-item(), outra função da mesma especificação, que permitiria sortear entre uma lista de tokens (cores de uma paleta, por exemplo) em vez de um intervalo numérico. Por enquanto nenhum navegador implementa essa variante, o que limita a randomização a valores contínuos ou discretizados por step, não a escolhas de token nomeado.

Fonte: Smashing Magazine