Resumen

  • El borrador de trabajo del W3C del 3 de julio de 2012 permitió que un elemento pidiera pantalla completa y que el documento la abandonara, con una capa superior y una salida dirigida por el usuario.
  • El W3C dejó de trabajar en aquel documento en 2014 y remitió a WHATWG. El estándar vigente condiciona normalmente la entrada a una activación reciente del usuario, limita el contenido incrustado y reclama una salida que siempre funcione.

Imaginemos un cine administrado por páginas web. El vídeo quiere apagar las luces, el juego reclama toda la pared y las diapositivas consideran una falta de respeto la barra del navegador. El encargado acepta las tres peticiones. Entonces el responsable del edificio pregunta quién abre la puerta al terminar la función. Lo que parecía una discusión sobre píxeles se convierte en una discusión sobre mando.

El primer borrador público del W3C, fechado el 3 de julio de 2012, proponía gestos técnicos muy claros. requestFullscreen() en un elemento solicitaba su presentación a pantalla completa. exitFullscreen() en el documento ponía fin a ella. fullscreenElement identificaba qué elemento estaba en escena. Los métodos devolvían void en aquel texto. Era un borrador de trabajo, no una Recomendación del W3C ni un certificado de cuándo estrenó la función un navegador concreto.

La diferencia con dibujar un rectángulo enorme mediante CSS estaba en la autoridad visual. El borrador colocaba el elemento en la pila de pantalla completa del documento y en la capa superior del contexto de navegación, la más próxima al espectador en el orden de dibujo. Una página siempre pudo hacer cajas muy grandes. Pedir toda la superficie de presentación implicaba al navegador, su ventana y sus reglas. Un div con voz de director no hereda por ello la escritura del monitor.

Había condiciones para entrar. El algoritmo examinaba si el elemento pertenecía al documento, si los contextos correspondientes tenían habilitada la función y si los estados anidados resultaban compatibles. El texto también usaba una condición vinculada al permiso para mostrar ventanas emergentes y contemplaba una preferencia previa del usuario, un riesgo de seguridad o una limitación de la plataforma. La página podía pedir; el navegador podía decir que no. Alquilar el escenario no equivalía a comprar el teatro.

La salida ya formaba parte del diseño inicial. Si el usuario indicaba al navegador que terminara la sesión, el borrador ordenaba abandonarla por completo. También contemplaba mostrar cómo salir. fullscreenchange avisaba a la página de un cambio de estado, aunque su propio programa no hubiera bajado el telón. El reproductor puede reajustar sus controles; no puede tratar la pantalla como un contrato de arrendamiento sin vencimiento.

La historia de los documentos da un giro en la nota del W3C del 18 de noviembre de 2014. Allí se afirma que el trabajo sobre ese documento se ha interrumpido y se señala la especificación Fullscreen de WHATWG como referencia. No hubo ascenso secreto del borrador de 2012 a Recomendación. Tampoco desapareció la función. Cambió el lugar en el que se escribía su contrato, mientras la misma pregunta seguía ante cada pantalla: quién autoriza la inmersión y quién puede terminarla.

El estándar vivo de WHATWG detalla el acuerdo actual. requestFullscreen() y exitFullscreen() devuelven promesas. En el caso habitual, la solicitud exige activación transitoria del usuario, como una interacción reciente; existe además el supuesto específico de un cambio de orientación provocado por el usuario. La activación se consume al admitir la petición. Pulsar un botón para ver un vídeo y descubrir que una página se apropió del monitor al cargar son invitaciones muy distintas.

El elemento mostrado sigue definido por su posición en la capa superior y por su indicador de pantalla completa. :fullscreen permite ajustar la puesta en escena; fullscreenchange y fullscreenerror comunican cambio y rechazo. Estas son piezas del estándar actual. Atribuir las promesas y la política de permisos al borrador de 2012 sería como poner teléfonos inteligentes en una fotografía antigua: quizá la escena resulte vistosa, pero la fecha ya no explica nada.

Una iframe de terceros plantea la versión más aguda del problema. Si un vídeo está incrustado dentro de otra página, ¿quién le concede el derecho a ocupar toda la pantalla? La función fullscreen está sujeta a una política de permisos cuya lista predeterminada es 'self'. El contenido anidado necesita autorización expresa mediante allowfullscreen, allow o una cabecera de política adecuada. El teatro puede recibir a una compañía invitada sin entregar automáticamente las llaves del edificio.

La salida tiene un motivo concreto. El estándar actual pide que el navegador haga visible el estado de pantalla completa, ofrezca una forma de salir que funcione siempre y la anuncie al usuario. Una página a pantalla completa puede imitar la interfaz del navegador e incluso la del sistema operativo. El navegador también puede terminar la sesión si lo considera necesario. Aquella pequeña señal sobre la puerta protege al público de un escenario que finge ser el edificio entero.

La API permitió que la web sirviera para cine, juego y presentación con una interfaz común. El logro no fue sólo llenar de imagen el monitor. Fue conceder espacio a los creadores sin hipotecar la capacidad de levantarse de la butaca. El sitio puede pedir oscuridad; el cartel luminoso de salida se queda encendido.