Resumo

  • O Working Draft do W3C de 3 de julho de 2012 descreveu o pedido de tela cheia por um elemento, a saída pelo documento, a camada superior de exibição e o encerramento por ordem do usuário.
  • Em 2014, o W3C interrompeu o trabalho naquele documento e apontou para a especificação da WHATWG. O padrão atual normalmente exige uma ativação recente do usuário, controla conteúdo incorporado e pede uma saída que sempre funcione.

Imagine um festival de cinema administrado por páginas web. O vídeo quer escurecer a sala, o jogo pede a parede inteira e os slides acham que a moldura do navegador está roubando a cena. O gerente aceita. Então alguém pergunta onde fica a saída. A conversa sobre o tamanho da projeção vira uma conversa sobre quem pode apagar as luzes e quem pode acendê-las de novo.

O primeiro Working Draft público do W3C, de 3 de julho de 2012, tinha uma interface direta. Um elemento chamava requestFullscreen() para pedir a tela cheia. O documento podia chamar exitFullscreen() para encerrá-la. fullscreenElement revelava qual elemento estava ocupando a tela. Naquele texto, os métodos retornavam void. A data é a de um rascunho de padrão, não a de uma Recomendação do W3C nem uma medição de quando navegadores específicos passaram a oferecer o recurso.

A novidade não se resumia a esticar um retângulo. CSS já permitia desenhar caixas enormes. O rascunho colocava o elemento em uma pilha de tela cheia e na camada superior do contexto de navegação, aquela desenhada mais perto de quem olha. O pedido mexia na relação entre a página, a janela do navegador e a tela. Um div convencido de seu talento dramático ainda precisava bater à porta antes de tomar o palco.

Havia condições. O algoritmo examinava se o elemento pertencia a um documento, se os contextos envolvidos permitiam tela cheia e se estados aninhados criavam conflito. O rascunho também trazia uma condição ligada à permissão para mostrar pop-ups e reconhecia preferências preexistentes do usuário, riscos de segurança e limitações da plataforma. A página podia solicitar. O navegador podia recusar. Alugar o auditório não incluía a escritura do prédio.

A saída já estava no projeto. Quando o usuário instruísse o navegador a encerrar uma sessão iniciada pela API, o texto mandava sair completamente. Ele também previa a possibilidade de mostrar como fazer isso. O evento fullscreenchange avisava a página de mudanças de estado, inclusive quando o pedido de saída vinha de fora do seu código. O reprodutor podia reorganizar os controles depois que a cortina baixasse; não podia exigir que a plateia ficasse sentada.

O registro histórico dá uma curva em 18 de novembro de 2014. Uma nota do W3C declarou encerrado o trabalho naquele documento e indicou a especificação Fullscreen da WHATWG como referência. Isso não transformou o rascunho de 2012 em Recomendação, nem apagou o recurso. A oficina onde o contrato era escrito mudou de endereço. O problema prático — oferecer imersão sem prender a plateia — continuou exatamente na frente dos olhos.

O Living Standard atual da WHATWG detalha a entrada. requestFullscreen() e exitFullscreen() retornam promessas. Em condições normais, o pedido exige ativação transitória do usuário, como uma interação recente; o texto registra ainda o caso específico de uma mudança de orientação produzida pelo usuário. Quando o pedido é aceito, a ativação é consumida. Clicar para ampliar um vídeo e ser levado à tela cheia no carregamento da página são situações diferentes.

No modelo atual, o elemento em tela cheia é o mais alto na camada superior com a marca apropriada. A pseudoclasse :fullscreen ajuda a compor a apresentação. fullscreenchange e fullscreenerror comunicam mudança e falha. São mecanismos do texto atual. Colocar as promessas e a política de permissões na boca do rascunho de 2012 seria como entregar um controle remoto novo a uma fotografia antiga: divertido, mas historiografia ruim.

Um vídeo de terceiros dentro de um iframe deixa a disputa ainda mais clara. O visitante entrou no site hospedeiro; a empresa incorporada pode tomar a tela por conta própria? A política de permissões atual trata fullscreen como recurso controlado, com lista padrão 'self'. Conteúdo aninhado precisa de autorização explícita, por allowfullscreen, allow ou um cabeçalho de política adequado. Um teatro recebe companhias convidadas. O prédio continua tendo um responsável pelas chaves.

O padrão atual também pede ao navegador que mostre ao usuário que há conteúdo em tela cheia, ofereça um modo de sair que sempre funcione e explique como usá-lo. O motivo é concreto: uma página em tela cheia pode fingir ser o navegador ou até o sistema operacional. O navegador pode encerrar a sessão quando julgar necessário. A luz verde acima da porta é uma parte técnica do espetáculo, porque a tela cheia remove justamente as pistas visuais que costumam dizer onde a página termina.

A Fullscreen API ajudou a web a virar cinema, sala de aula e console sem entregar a cada site o regulamento de evacuação. O conteúdo pode preencher o monitor. O direito de levantar da cadeira permanece com a pessoa que o está usando.