Summary

  • O W3C publicou em 2 de junho de 2011 um rascunho de Page Visibility que oferecia à página um estado de visibilidade e o evento visibilitychange quando ele mudasse.
  • O exemplo era uma caixa de e-mail: visível, poderia procurar novas mensagens a cada poucos segundos; oculta, poderia espaçar a consulta para alguns minutos. A aplicação escolhia o intervalo.

O e-mail ficou atrás de um mapa, de uma reportagem e de uma receita. Seu dono já está em outro assunto. A aba, porém, segue abrindo a caixa postal. Abre de novo. E mais uma vez. É um funcionário zeloso tocando a campainha de um escritório vazio. Em um navegador cheio de abas, esse zelo consome trabalho de máquina e energia sem encontrar leitor.

O rascunho do W3C de 2 de junho de 2011 partiu dessa diferença de informação. O navegador sabe qual aba aparece na frente, quando uma janela é minimizada e se o documento está visível em alguma tela. A página passou a consultar document.hidden, ler um estado de visibilidade e receber visibilitychange quando esse estado mudava. O navegador comunicava uma observação própria; a aplicação reavaliava o que valia a pena fazer.

Os autores não precisaram imaginar um laboratório. Usaram o correio web. Com o usuário olhando a caixa de entrada, verificar mensagens a cada poucos segundos pode ser uma escolha sensata. Ao esconder a aba, o serviço poderia aumentar o intervalo para alguns minutos. O site conhece a urgência das mensagens que oferece. O navegador conhece a posição da página diante dos olhos do usuário. A cooperação começa quando cada um diz o que sabe.

A proposta debatida em janeiro de 2011 na lista pública do W3C trazia outras cenas: parar o relógio de um quebra-cabeça quando o jogador sai, reduzir a busca periódica por novidades e esperar uma aba ser vista antes de iniciar o vídeo. O mesmo sinal produzia políticas diferentes. O jogo protegia o tempo de quem joga. O e-mail fazia menos perguntas. O vídeo aguardava a plateia chegar.

O rascunho ainda precisava definir o que significa estar escondido. Uma aba em segundo plano, um navegador minimizado e a tela bloqueada apareciam como exemplos. Se pelo menos parte da página fosse mostrada em uma tela, ela era visível. Havia atenção também a ferramentas de acessibilidade que cobrem a tela enquanto mostram o documento ampliado. A condição vinha do modo como o navegador apresentava o conteúdo, com mais precisão do que a página poderia deduzir apenas de foco e desfoque.

visibilitychange fazia o aviso chegar durante a vida da página. Uma consulta única no início não acompanha quem abre o correio, vai ler outra coisa e retorna meia hora depois. O rascunho de última chamada de julho de 2011 preservou os exemplos cotidianos enquanto refinava a interface. A cada mudança de posição, o programa ganhava uma oportunidade para mudar seu expediente.

A Recomendação de 14 de maio de 2013 consolidou hidden, visibilityState e visibilitychange, além de descrever estados possíveis em casos como pré-renderização e descarregamento. A segunda edição, de outubro daquele ano, teve uma emenda deliciosamente pequena: corrigir um erro de grafia no nome de visibilitychange na seção 4.3. Depois de estabelecer quando a página está à vista, ainda foi preciso soletrar corretamente o aviso. Padrões também precisam de revisão de texto.

O problema é diferente daquele resolvido por Web Workers. Um worker põe cálculos demorados em outro espaço de execução para deixar a página responder aos cliques. Page Visibility informa à aplicação quando convém fazer menos trabalho ou adiá-lo. Um correio pode usar os dois recursos: processamento em separado e menos consultas quando está escondido. Onde o trabalho acontece e qual horário ele cumpre são perguntas distintas.

O objetivo declarado em 2011 era ajudar a criar aplicações mais eficientes em processamento e consumo de energia. A ideia tinha tamanho de recado doméstico. Se ninguém está na sala, o carteiro pode parar de bater à porta a cada poucos segundos. O navegador sabia que a sala estava vazia. Finalmente pôde contar isso à página.