1725 1228 1108 1832 1685 1490 1797 1179 1200 1758 1799 1246 1041 1046 1963 1038 1481 1123 1494 1035 1448 1033 1276 1266 1810 1180 1059 1766 1718 1463 1906 1709 1763 1432 1886 1572 1981 1631 1510 1679 1478 1046 1620 1397 1813 1352 1548 1838 1304 1095 1885 1088 1011 1725 1907 1445 1609 1131 1163 1042 1648 1850 1986 1707 1344 1866 1809 1140 1768 1439 1462 1167 1383 1406 1239 1939 1033 1688 1360 1048 1205 1724 1803 1767 1763 1716 1336 1092 1719 1152 1130 1059 1752 1521 1380 1239 1972 1913 1285 One decade waiting for web APIs [blog] | PHPnews.io


One decade waiting for web APIs [blog]

Written by Remy Sharp / Original link on Jun. 13, 2022

In the last couple of years (rather slowed by the pandemic), a number of new browser APIs have started to land that I had wanted over a decade ago. That's not to say that the process is slow, more that the technology simply didn't exist a 10 years ago, and now the APIs exist, it took me a matter of hours to build the small bit of software I so desperately needed back then.

What I needed

In August 2010, a personal tragedy struck. If you know my story, you'll know what this is (and in fact it's critical to how much I needed the right technology). The night I arrived home and I lay in bed trying to sleep, or rather become unconscious so I didn't need to face reality.

I brought up a photo that had been taken that day that I needed to burn into my memory.

I did this using my phone propped up and the photos app to bring up the photo. The problem was that my phone kept dimming the screen, and eventually turning it off.

I know this is typically the best practice for a device to follow (to avoid screen burn), but at this particular point in time I needed the picture to remain on. I needed it to be the first thing I saw when I opened my eyes.

There wasn't an app I knew of and getting a photo printed (though it's what we did as soon as we could) didn't give me the photo quickly enough.

A decade later I am able to write this software using browser technology as plain text without the need for build tools, special libraries or any hacks.

Caveat: it's important to point out that not all these APIs work in all browsers. What's important to me was that I could write this software for myself and this post is meant to share what's possible today.

The criteria

I wanted a web app that could load any photo off my phone, work without an internet connection (if required) and then put the photo on the screen, using all the available space and without turning the screen off.

The parts

To create a persistent picture frame, I would need the following technology available in the browser:

Again, I wanted to do this without the need for libraries and without the need for build tools.


Besides general decorative and instructional markup, the few important bits that I needed were:

<link rel="manifest" href="/manifest.webmanifest">
<input id="file" type="file" accept="image/*">

Obviously I'm going to be adding script tags, but the above two tags give me the setup for a PWA and the input tag gives me a file picture that's going to filter to images.

The JavaScript

Due to how permissions work that require "user gestures" there's a two-tap process to actually getting the image to render. The first is to pick the image, the second is to launch to full screen and to handle any screen rotation and finally setting the wake lock.

1. Getting the file as an image url

When the input[type=file] has it's change event firing, it means the visitor has selected an image and we're ready to go to work.

To get a URL that I can put into an image tag, I need to read the target.result into a Blob and then create a URL to that blob.

input.addEventListener('change', async (e) => {
  // new FileReader gives us a way to convert to file
  // formats, but specifically an ArrayBuffer
  const fileReader = new FileReader();
  fileReader.onloadend = function (e) {
    // now we have an ArrayBuffer, we can make this
    // into a blob
    const blob = new Blob([e.target.result], {
      type: 'image/png',

    // and now a URL
    url = URL.createObjectURL(blob);

    // after which we'll change the button so we
    // can show the visitor the "start" button
    input.parentNode.hidden = true;
    start.hidden = false;

Now that I have a URL to the image, it's ready to be rendered, but first I need the screen setup.

2. Trigger all the "user gestured" tasks

As the title says, to go full screen, and to lock the orientation and to request a wake lock, this must be done via a "user gesture" - that's to say, I can't just trigger a wake lock with you having requested something first.

Though, funnily enough, Henrik Joreteg wrote a polyfill for wake lock that works rather well and by it's nature does not require user permission!

What follows is an abbreviated version of the actual code used (specifically I'm skipping some of the more verbose checking I would do for brevity of this post):

// when "start" is clicked, now we:

// set the entire document to full screen.
await document.documentElement.requestFullscreen();

// request a wake lock (usually wrapped in try/catch)
await navigator.wakeLock.request('screen');

// now create a new image to load our `url` into,
// but creating an image we'll wait until it's loaded
// to then read the dimensions and work out what
// orientation to lock the screen in too.
const i = new Image();
i.onload = async () => {
  // read the current screen orientation
  let { type } = screen.orientation;
  const currentType = type;

  const portrait = type.startsWith('portrait');

  // if we need to change to portrait
  if (i.width < i.height && !type) {
    type = 'portrait';
  // else if we need to change to landscape
  } else if (i.width > i.height && type) {
    type = 'landscape';

  // now lock the orientation
  await screen.orientation.lock(type);

  // finally add the image to the document, note that
  // CSS will also have this fill the element using
  // img { object-fit: cover; width: 100%; height: 100% }

// now that the `onload` is set up - actually load the image:
i.url = url; // url = the blob from the previous function

And that's it. There's really nothing more to the software than that. No build process and it all works in the browser exactly as I needed.

Here it is, a simple PWA:

The full source code is available on GitHub, and you can try the demo (again, this is chrome only for the time being for reasons I explained before) here: https://phrame.isthe.link (ignore the stupid name!).

Bits that still don't quite work

Here's an unordered list of things I've noticed that are a bit…weird:

Originally published on Remy Sharp's b:log


« Web Share API - Why Your Company Needs APM: Business Application Monitoring »