Resumen

  • El primer borrador público de Wake Lock, de 2015, usaba document.keepScreenAwake en un ejemplo de cocina. El documento expresaba una preferencia y el navegador la trasladaba al sistema si la página y el dispositivo seguían en condiciones de hacerlo.
  • La Recomendación Candidata de 2017 hablaba de bloqueo de pantalla y de sistema. Desde 2020, un borrador específico para la pantalla presenta una solicitud y una WakeLockSentinel liberable, sujetas a visibilidad, permisos y energía.

El temporizador que apaga la pantalla es un empleado aplicado. Ahorra batería cuando nadie mira y, de vez en cuando, interrumpe una receta en el peor instante: manos cubiertas de harina, agua hirviendo, cantidades a medio leer. Una web puede explicar por qué necesita la luz unos minutos más. El navegador, el sistema operativo y la persona que paga la carga tienen otras razones. La historia de esta API consiste en convertir la petición de la página en una negociación con límites.

El primer borrador público del W3C, fechado el 12 de febrero de 2015, proponía poner document.keepScreenAwake = true mientras se mostraba una receta y volver a false al terminar. Parecía un interruptor en manos de la página. El propio texto explicaba que era una bandera de solicitud. El navegador reunía las solicitudes de los documentos relevantes y pedía al sistema operativo aplicar el bloqueo si el estado del dispositivo lo permitía. La web hacía una solicitud; el mando de la pantalla permanecía en otro sitio.

¿Qué cuenta como documento relevante? En 2015 importaban su actividad y su presencia delante del usuario. Cambiar de pestaña o minimizar el navegador quitaba fuerza a la petición de esa receta. El diseño impedía que una página olvidada secuestrara la luz de un dispositivo compartido. El sitio sabía cuándo su contenido necesitaba verse; el navegador sabía cuál de las muchas páginas estaba realmente a la vista.

La Recomendación Candidata de diciembre de 2017 amplió el mapa. Distinguía entre mantener encendida la pantalla y evitar que el sistema dejara de procesar. Una receta requiere ojos sobre el texto. Un trabajo de fondo plantea otra clase de consumo. El documento de 2017 introducía objetos de solicitud y reglas para cambiar el estado según la visibilidad y las condiciones del dispositivo. La misma palabra, «despierto», escondía dos facturas energéticas distintas.

El borrador Screen Wake Lock de septiembre de 2020 concentró la atención en el brillo que necesita quien está leyendo. Solo un documento visible podía obtener el bloqueo. Una WakeLockSentinel permitía soltar la petición y enterarse de su liberación. El dispositivo podía estar bajo de batería, entrar en ahorro de energía o perder de vista la página. La promesa se volvió más clara precisamente porque dejó de sonar absoluta.

El historial de publicaciones del W3C muestra la secuencia: borrador inicial en 2015, candidato en 2017, texto exclusivo para la pantalla en 2020 y nuevas versiones después. Es una evolución de las reglas, no una estadística de cocinas con tabletas. Sirve para ver cómo una petición amplia de «no duermas» acabó pareciéndose a un préstamo temporal de luz.

En el borrador fechado en septiembre de 2026, cuentan la visibilidad, el permiso, la política de acceso y el estado del sistema. El navegador puede liberar el bloqueo; el sistema operativo puede no mantenerlo por poca batería o por ahorro de energía. La solicitud al sistema tiene carácter consultivo. La página no adquiere la batería por presentar una buena receta.

Una web respetuosa pide la pantalla mientras la persona sigue los pasos, observa la liberación y ofrece una manera sencilla de recuperar el lugar de lectura. Cuando el plato está listo, termina el préstamo. Si insiste en mantener la pantalla encendida para que nadie deje de mirar anuncios, la cocina deja de ser la razón. Los usuarios reconocerán quién consume la energía.

La masa sigue esperando. El sitio puede pedir luz para terminarla. La última palabra, sensatamente, no sale del recetario.