Resumo

  • O primeiro rascunho público do W3C, em 2015, usava document.keepScreenAwake numa receita. O documento registrava uma preferência; o navegador decidia quando encaminhá-la ao sistema operacional.
  • A Candidata a Recomendação de 2017 tratou de bloqueios da tela e do sistema. A partir de 2020, o texto específico para a tela passou a usar um pedido e uma WakeLockSentinel que pode ser liberada, sob condições de visibilidade e energia.

O apagamento automático é útil até encontrar uma panela no fogo. Nesse momento, o cozinheiro não tem uma mão limpa para tocar na tela, e a tela resolve economizar energia bem na linha que diz quanto tempo esperar. Uma página de receita pode pedir que ela fique acesa. O tablet também tem dono, bateria e configurações. O problema técnico é negociar essas vontades sem permitir que cada site trate a tomada como herança de família.

O primeiro rascunho público Wake Lock do W3C, de 12 de fevereiro de 2015, escolheu a receita como exemplo. O código punha document.keepScreenAwake em true enquanto ela era exibida e devolvia a false no fim. A forma parecia um interruptor. O mecanismo era um sinalizador de pedido no documento. O navegador avaliava se aquele documento estava em uso e à vista; depois solicitava o bloqueio ao sistema operacional, caso o aparelho permitisse. A página fazia o pedido, não guardava a chave da bateria.

O texto de 2015 levava a sério a troca de aba e a perda de foco. Se a receita saiu de cena, sua razão para manter a tela desperta enfraqueceu. O navegador reunia demandas de várias páginas e as relacionava ao estado real do aparelho. Sem isso, uma aba esquecida de manhã poderia continuar fazendo hora extra em nome de uma torta que já saiu do forno.

A Candidata a Recomendação de dezembro de 2017 abriu duas frentes. Um bloqueio mantinha a tela ligada; outro dizia respeito ao sistema continuar processando. Para ler a quantidade de farinha, a primeira importa. Para uma tarefa em segundo plano, a segunda cria outra discussão sobre energia. O documento descrevia objetos de pedido e ajustes automáticos quando visibilidade e condições do dispositivo mudavam. Era um momento em que a web dizia «mantenha-se acordado» sem falar sempre da mesma parte do corpo.

O rascunho Screen Wake Lock de setembro de 2020 delimitou o assunto: a luz da tela. Um documento visível podia solicitar o bloqueio e receber uma WakeLockSentinel, que podia liberar o pedido e informar sua liberação. Bateria baixa, economia de energia ou a página escondida podiam encerrar o acordo. O site ganhou um comprovante para um empréstimo temporário, não uma escritura do display.

O histórico de publicações do W3C registra a primeira versão de 2015, o candidato de 2017, o rascunho especializado de 2020 e revisões posteriores. Essa sequência explica a mudança de escopo. O primeiro pedido amplo de vigília virou uma negociação mais clara sobre manter apenas a tela visível enquanto alguém realmente precisa dela.

No rascunho datado de setembro de 2026, o documento precisa estar visível; permissão, política e condições do aparelho entram na decisão. O navegador pode liberar o bloqueio, e o sistema operacional pode não aplicá-lo sob bateria fraca ou modo de economia. O pedido ao sistema é consultivo. A receita explica a necessidade; a máquina decide se consegue atendê-la.

O comportamento editorial aparece no fim da tarefa. Pedir luz enquanto alguém prepara a comida é útil. Ouvir a liberação e permitir retomar a etapa também. Manter a tela acesa quando a pessoa foi embora, só para prolongar a vitrine de anúncios, é outra escolha. A API não controla a boa educação de quem publica, mas expõe o momento em que ela falta.

A massa não vai se sovar sozinha. A tela pode ajudar ficando acordada. Se a bateria decidir dormir, talvez seja hora de limpar um dedo e acordá-la de novo.