# Dois, três ou nenhum estado: a linha do tempo do debate sobre toggle de dark mode
> De uma issue no guia do Chrome à conclusão de que o melhor toggle de dark mode é nenhum: os argumentos de Lea Verou e Bramus, e o que sobra de prático.
URL: https://dpw.dev/ui-ux/debate-toggle-dark-mode/
Publicado em: 2026-10-01
Categoria: ui-ux
Tags: usabilidade, css, interface
Autor: Tárcio Zemel
Entre agosto e setembro de 2026, o **toggle de dark mode** virou o assunto mais debatido do frontend. Começou com uma issue no guia de dark mode do Chrome, passou por uma reunião do CSS Working Group em Berlim e terminou numa conclusão que ninguém tinha proposto no início: talvez o melhor toggle seja não ter toggle nenhum.
Vale acompanhar a discussão inteira, porque ela é uma aula sobre a diferença entre expor o modelo de dados e desenhar para o objetivo de quem usa.
## A linha do tempo
**Final de julho.** Ao navegar pelos guias do Modern Web Guidance do Chrome, Bramus Van Damme percebe que o guia de dark mode recomenda um controle de dois estados. Convencido de que o correto seriam três, ele abre uma issue no repositório pedindo a correção, sem muito argumento, por assumir que aquilo era consenso. A autora do guia, Lea Verou, responde apontando a seção de motivação do próprio guia.
**Primeira semana de agosto.** Por coincidência, o encontro presencial do CSS Working Group acontece em Berlim, com os dois presentes. Eles tentam se convencer mutuamente, não chegam a lugar nenhum e concluem que faltam dados. Cada um vai para as redes sociais buscar respostas: Bramus pergunta quantas opções as pessoas exibem em seus sites, Lea pergunta se alguém já clicou no override que coincide com o próprio sistema operacional.
**6 de agosto.** Lea publica Dark mode toggles: two states are enough, que se torna um dos posts mais lidos do blog dela.
**10 de agosto.** Declan Chidlow publica um design alternativo: três estados no espaço de dois ícones.
**18 de agosto.** Bramus publica a resposta, The Case for Tri-State Dark Mode Toggles.
**Segunda metade de agosto.** O debate transborda para uma competição paralela de quem inventa o pior toggle possível: um de quatro estados, um de cem estados, um "modo capitalismo" em que o dark mode é pago, e um dark mode com holofote.
**2 de setembro.** Lea publica The best dark mode toggle is probably none, mudando a própria posição.
**3 de setembro.** Chris Coyier resume o episódio no blog do Frontend Masters com a posição mais diplomática possível: concorda com todos os lados, porque sites diferentes têm públicos diferentes.
*O controle de três estados: sistema, claro e escuro, todos visíveis ao mesmo tempo.*
## O caso dos dois estados
O ponto de partida de Lea é que **o modelo de dados precisa ter três estados, mas um deles é sempre irrelevante para o objetivo do usuário naquele momento**.
Ninguém procura um toggle de tema para expressar a intenção de que as coisas continuem como estão. As pessoas procuram o controle quando algo precisa mudar: a página está clara demais na cama, ou escura demais no sol. É um ajuste de conforto imediato e situacional, não uma posição de longo prazo sobre esquemas de cor.
Nesse enquadramento, existem só dois estados reais do ponto de vista do objetivo:
- O site está confortável, e a pessoa segue com o que realmente foi fazer ali, sem procurar o controle.
- O site está claro ou escuro demais, e a pessoa quer corrigir.
O terceiro estado pressupõe um cenário em que alguém visita um site que está perfeitamente confortável e ainda assim procura o toggle para garantir que continue assim no futuro. O argumento é que isso quase não acontece, e não justifica o atrito permanente.
Pior: o controle de três estados obriga a escolher entre opções que produzem o mesmo resultado visível, o que viola o princípio de feedback. Duas das três opções não mudam nada na tela.
*Exemplo de controle de três estados, no site do Tailwind.*
### Expor o modelo de dados é o erro clássico
O diagnóstico de Lea é que o toggle de três estados é interface guiada pela implementação. Um dos erros mais comuns de UX é desenhar a interface em volta do modelo de dados em vez do objetivo de quem usa, e boas interfaces abstraem o modelo.
### O toggle de dois estados que funciona
Boa parte da rejeição aos controles de dois estados vem de implementações ruins, e nisso os dois lados concordam. Um toggle de dois estados que grava um valor e nunca mais consegue voltar a seguir o sistema é pior que um de três, porque torna a escolha irreversível.
O desenho proposto mantém três estados no modelo e mostra apenas dois por vez:
| Opção | Aparece como | Valor armazenado |
| --- | --- | --- |
| Padrão do sistema | O valor atualmente resolvido (sol ou lua) | Nenhum |
| Override | O oposto do valor atual (lua ou sol) | `light` ou `dark` |
Na primeira vez que o controle é acionado, ele alterna para o oposto do que está na tela e grava o valor literal. Na vez seguinte, volta ao padrão do sistema e apaga o valor gravado.
Duas regras de implementação decidem se isso funciona:
- **Gravar um valor que coincide com a preferência do sistema converte silenciosamente um ajuste temporário em fixação permanente sem saída.** É o erro mais comum.
- **A avaliação só pode acontecer na interação do usuário.** Apagar o valor gravado de forma proativa, quando a preferência do sistema muda, impede quem usa alternância automática por horário de fixar um tema. Se um override gravado passa a coincidir com o sistema porque o sistema mudou, ele deve ser mantido.
Lea montou uma demonstração interativa que percorre esse cenário passo a passo, com os dois controles ao vivo.
*Exemplo de controle de dois estados, no shadcn.*
## O caso dos três estados
Bramus não se convenceu, e o argumento central dele é concreto: **forçar um site em um modo específico não deveria depender da hora do dia.**
O cenário:
- O sistema operacional está configurado para alternar entre claro e escuro conforme o horário.
- A pessoa visita o site de dia e vê o tema claro.
- Ela experimenta o tema escuro no controle de dois estados, não gosta, e volta para o claro.
- Ela visita o site de novo à noite.
Como o controle de dois estados mapeia um dos valores de volta para "sistema", o site agora aparece escuro, embora a pessoa tenha escolhido explicitamente claro na última interação. O resultado provável é um relato de bug.
Além disso, Bramus levanta três pontos:
- **Persistência é intenção.** Se a opção escolhida é gravada, por que ela não poderia ser uma preferência de longo prazo?
- **Existe feedback local.** A página inteira pode não mudar, mas a opção selecionada muda, e isso é feedback visual.
- **Clareza acima de brevidade.** A formulação é de Erik Kroes, citada por Bramus: três opções explícitas comunicam com clareza o que cada botão faz, e não trazem a surpresa de o tema mudar sozinho conforme o horário.
Bramus também aponta que a ressalva de Lea sobre painéis de configuração exige muito de quem desenvolve, porque a maioria dos sites nem tem painel de configuração.
### As concessões dele
Ele não é totalmente contra os dois estados, desde que o controle comunique o que está acontecendo. Duas formas de fazer isso:
1. **Rotular explicitamente o estado de sistema**, com um "auto" ou ícone equivalente no valor que segue o sistema. Foi o que ele fez na extensão de Chrome que criou como prova de conceito.
2. **Gravar valores explícitos** (`light` ou `dark`, nunca `system`), o que exige oferecer uma opção de reset. Como ele mesmo reconhece, nesse ponto já vale transformar o controle em um de três estados.
### O desenho que agradou os dois
A alternativa de Declan Chidlow foi a mais celebrada: dois controles que ainda expressam três estados.
Por padrão, quando o site segue o sistema, nenhuma das opções está destacada, e esse estado neutro representa implicitamente "sistema". Ao clicar em claro ou escuro, a escolha é destacada e gravada. Clicar de novo no valor já escolhido volta ao estado neutro.
[Exemplo no CodePen](https://codepen.io/OuterVale/pen/019fe98c-2d9b-71e4-849d-726543589635)
## A tréplica
Lea respondeu a cada objeção, e é aqui que o debate fica mais interessante do que a decisão em si.
**Sobre a alternância por horário.** O controle de dois estados cobre as três intenções com um clique. Não um clique por sessão: um clique, uma vez. O que varia é *quando* esse clique acontece.
**Sobre a enquete.** Bramus perguntou a desenvolvedores qual controle eles *constroem*, e usou o resultado (43 a 7 a favor dos três estados) como evidência de qual controle é mais *usável*. São perguntas diferentes: preferência de quem desenvolve se confunde com convenção e conveniência de implementação. Se perguntar a desenvolvedores o que eles constroem produzisse dados sobre usabilidade, teste com usuário nunca seria necessário.
**Sobre o feedback local.** O botão destacar-se é melhor que nada acontecer, mas o botão é o meio, não o fim. Quem clicou queria mudar a *página*, não o *botão*. Quando o controle muda e a página não, a pessoa agiu e o mundo não respondeu, o que é exatamente o golfo de avaliação de Norman.
**Sobre simplicidade.** Bramus escreveu que não há nada complexo em um controle de três estados, que ele é "a abordagem mais burra possível". Lea concorda com a descrição e diz que era justamente o ponto: simplicidade de implementação não é o mesmo que baixa carga cognitiva. O objetivo real de quem usa é concreto (claro ou escuro), enquanto "sistema" é uma variável, não um valor. Usar o controle de três estados exige uma tradução mental, curta mas desnecessária. Evitar exatamente esse tipo de processamento era a tese de *Don't Make Me Think*, livro que Bramus cita a favor da posição dele.
**Sobre "clareza acima de brevidade".** É uma dessas frases com que todo mundo concorda e que sustenta posições contraditórias. A pergunta que resolve é: clareza sobre o quê? Clareza sobre a máquina de estados da implementação não é clareza sobre o resultado. O controle de três estados é otimizado para quem já carrega o modelo do sistema na cabeça, ou seja, para quem desenvolve.
**Sobre a severidade.** Problemas de usabilidade se priorizam por frequência, impacto e persistência, e o cenário de Bramus pontua baixo nos três: exige alternância automática no sistema, mais experimentar e voltar atrás na mesma sessão, mais revisitar o site depois da troca, mais lembrar da interação anterior. O controle de três estados, em contrapartida, cobra um imposto em toda interação por um estado que a maioria nunca precisa.
E há um viés que atravessa a discussão: **depois de gastar muito tempo e esforço em algo, superestima-se o quanto aquilo importa para os outros.** Quem desenvolve passou dias nesse controle, quem usa vai passar meio segundo. É o efeito IKEA encontrando o efeito de falso consenso.
## A virada: e se não houver toggle?
O que fez Lea mudar de posição não foi o debate técnico. Foi enviar o artigo para um colega, também doutor em interação humano-computador, mas com trabalho mais voltado a pessoas do que a detalhes técnicos da web.
A resposta que ela esperava era concordância ou crítica construtiva. O que veio foi que o colega **não tinha ideia de que controle o artigo estava falando**. Ele nunca havia visto um toggle de dark mode. Ou, mais provavelmente, nunca havia prestado atenção em um.
A partir daí, a constatação: todos os toggles persistentes que ela conhecia estavam em sites voltados a desenvolvedores. Não havia um único site de grande público com toggle de dark mode fixo no cabeçalho.
Gmail, Facebook, Bluesky e outros, usados por horas todos os dias, colocam a opção em um painel de configurações, que é um caso de uso diferente.
Isso não é prova de que o toggle seja ruim, porque um padrão pode ser difundido e ainda assim ter usabilidade fraca, e toda inovação de UX começa impopular. Mas, neste caso, a conclusão é que os sites de grande público estão certos: isso importa muito menos para o usuário médio do que importa para quem desenvolve.
"Sempre claro, ou sempre escuro, mesmo contra o sistema" continua sendo uma intenção legítima. Só que é uma intenção rara, e intenções raras pertencem a uma superfície de configurações, atrás de divulgação progressiva, não ao único controle que todo visitante vê.
## Onde os dois concordam
Apesar do tamanho da discussão, a área de acordo é grande:
- O modelo de dados por baixo precisa ter três estados.
- Em um painel de configurações, o controle de três estados é o certo. Ali a pessoa já está no modo de tomar decisões sobre o próprio futuro, não se espera feedback imediato de cada ajuste, e há espaço para explicar.
- Um controle de dois estados mal implementado, que fixa um valor sem caminho de volta, é pior que um de três.
- O mínimo aceitável é seguir a preferência do sistema.
- O ideal seria o navegador oferecer esse controle nativamente, em vez de cada site reimplementá-lo.
## O que fica de prático
- **Site de grande público:** siga a preferência do sistema. Se houver necessidade real de override, coloque em um painel de configurações, com três estados.
- **Site voltado a desenvolvedores ou pessoas de design:** aqui o toggle persistente se justifica, porque o público realmente usa. Dois estados, com as regras de armazenamento acima.
- **Se optar por dois estados:** avalie o estado apenas na interação, e nunca apague um override porque o sistema mudou.
- **Se optar por três estados:** indique o que "sistema" está resolvendo naquele momento, e não gaste espaço permanente do cabeçalho com isso se o público não for técnico.
Um detalhe metodológico que Lea faz questão de registrar: usabilidade é uma propriedade dos resultados de quem usa, e nenhum usuário foi observado em nenhum momento dessa discussão. Os dois lados argumentaram a partir de princípios e experiência.
Teste qualitativo com poucos participantes também serve mal para uma microinteração tão infrequente, porque cada pessoa interagiria com o controle uma vez, na melhor das hipóteses. O caminho seria registrar interações reais em escala e analisar quantitativamente.
## A lição maior
O que sobra do episódio é maior que o toggle. É fácil cair na toca do coelho e se esforçar ao máximo para resolver um problema que não deveria existir.
Para quem tem formação em engenharia, resolver problemas vem naturalmente, e resistir a um problema interessante é difícil. Acontece direto em grupos de padronização: alguém propõe uma funcionalidade e o grupo começa a debater os detalhes antes de decidir se ela deveria existir.
Antes de qualquer tarefa grande de resolução de problema, vale recuar e perguntar se aquele é um problema real que merece solução. A frequência com que a resposta é "não" surpreende.
## Fontes
- Dark mode toggles: two states are enough, de Lea Verou (6 de agosto de 2026)
- The Case for Tri-State Dark Mode Toggles, de Bramus Van Damme (18 de agosto de 2026)
- The best dark mode toggle is probably none, de Lea Verou (2 de setembro de 2026)
- Two vs. Three-State Color Theme Toggles, de Chris Coyier (3 de setembro de 2026)
- O design de três estados em dois controles, de Declan Chidlow (10 de agosto de 2026)
---
Fonte: [dpw - desenvolvimento para web](https://dpw.dev/) (pt-BR).
Guia para agentes: https://dpw.dev/llms.txt
Índice completo: https://dpw.dev/sitemap-index.xml
Feed: https://dpw.dev/rss.xml