Dois, três ou nenhum estado: a linha do tempo do debate sobre toggle de dark mode

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 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.

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:

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.

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.

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)