Todo grande cliente de e-mail remove tags <script> antes de renderizar uma mensagem — sem exceções, sem opção de desativar por remetente. Então, quando um e-mail traz um carrossel funcional, um acordeão que expande ou um quiz que pontua uma resposta, nada disso é JavaScript. É um checkbox oculto, um seletor CSS e uma técnica que a comunidade de desenvolvimento de e-mail chama de máquina de estado.
O problema: clientes de e-mail removem <script>
A interatividade na web quase sempre assume que o JavaScript está disponível. O e-mail não pode assumir isso de jeito nenhum — Gmail, Apple Mail, Outlook e todo outro grande cliente remove tags <script> na chegada, como medida básica de segurança, independentemente do que o remetente inclua ou de como a mensagem é assinada. Qualquer coisa que se comporte como um aplicativo dentro de um e-mail precisa ser expressável inteiramente em HTML e CSS, porque isso é genuinamente tudo o que resta de pé no momento da renderização.
A técnica: inputs ocultos e combinadores de irmãos
O mecanismo é a pseudoclasse CSS :checked, aplicada a controles de formulário HTML reais:
- Um
<input type="radio">ou<input type="checkbox">oculto controla um pedaço do estado — qual slide do carrossel está ativo, se um painel do acordeão está aberto, qual resposta do quiz foi escolhida. - Um
<label for="...">visível envolve o que quer que o destinatário deva poder clicar — uma seta "Próximo", um cabeçalho de acordeão, uma opção de enquete — e alterna o estado marcado do input ao ser clicado, sem nenhum script envolvido; esse é o comportamento nativo do navegador para<label>/<input>. - Um combinador de irmãos CSS (
:checked ~ .panel,:checked + .content) estiliza outros elementos com base no estado marcado desse input — exibindo um slide, expandindo um painel, revelando uma mensagem do tipo "você escolheu B".
Empilhe o suficiente disso — um input por estado, uma regra de combinador por mudança de estilo resultante — e o resultado se lê como uma interface genuinamente com estado, construída inteiramente a partir de marcação que o processo de remoção de <script> de um cliente nunca toca, porque não há script algum para remover.
Suporte no mundo real: um panorama cliente por cliente
Segundo o painel de clientes testados do caniemail.com:
| Nível de suporte | Clientes | | --- | --- | | Suporte total | Gmail (todas as plataformas, desde março de 2020), Apple Mail (macOS 12.4+ / iOS 13.3+), Yahoo Mail, ProtonMail | | Suporte parcial | Outlook.com, Novo Outlook e Outlook mobile ("suportado apenas em seletores de tipo"); Samsung Email (Android 7.0+) | | Sem suporte | Outlook clássico do Windows (2007–2019); webmail Orange e SFR (removem elementos de input por completo) |
Esse é um número materialmente diferente do alcance real de ~91%+ que O Estado da Renderização de Clientes de E-mail em 2026 relata para o CSS cinético de forma geral — o número do caniemail conta os clientes igualmente, independentemente de quantos destinatários realmente usam cada um, enquanto o número de alcance pondera pela participação real nas aberturas rastreadas. O Outlook clássico do Windows falha completamente nessa técnica, mas também é uma minoria cada vez menor de uma categoria de participação de mercado que o Apple Mail sozinho já ofusca — por isso ponderar pelo uso real, e não pela contagem de clientes, é o número que deveria orientar uma decisão de design.
O que acontece onde :checked não é respeitado
Em um cliente que não suporta :checked de forma alguma, os inputs ocultos e a marcação extra simplesmente renderizam de forma inerte — sem erro, sem layout quebrado, apenas sem interação. O bloco recorre ao que quer que sua ordem de marcação padrão mostre: o primeiro slide do carrossel, um acordeão fechado, uma lista estática simples de opções do quiz. Projetar esse fallback deliberadamente, em vez de deixar um cliente sem suporte exibir algo meio quebrado, é a função de fato do motor de fallback — veja Como os fallbacks funcionam para o modelo completo de três níveis dentro do qual essa técnica se encaixa.