By Scott Jehl
A couple of years ago, having just finished some work to help de-extinct responsive HTML video, I posted a short list of related improvements that I hoped to see next, each paired with tickets filed against the HTML standard.
That list went untouched until last fall when a few Squarespace coworkers joined me to take one of them on as a Hack Week project, which went well enough that the company supported our work to finish the job. That work, standardizing and implementing HTML video lazy-loading, merged into the HTML standard this spring; Chromium browsers quickly picked up support, and browser implementations for Firefox and WebKit (Safari) that my teammates wrote are looking like they'll land any day.
You can read about my team's process as well as how to use that new HTML feature over on the Squarespace Engineering Blog. As a standard feature, HTML video lazy-loading can be used on any website now, and for folks who have a website that runs on Squarespace, they can find handy options in the CMS to take advantage of it for their videos too.
Next Up: <poster>
Hot on the heels of that work, another item on that checklist is now well on its way to getting checked: modernizing video posters. If you don't know them by name, video posters are those images that show before a video has been played, which can display anything from a simple still-frame pulled from the video itself to an elaborate cover slide for a video, complete with burned-in text and an online creator making an incredulous facial expression.
Posters are everywhere on the web, but despite their commonality some may be surprised to learn just how underpowered the HTML video element's poster image is. For the past 20 years (!) since HTML video was spec'd in HTML5, video poster images have been delivered via a single attribute, <video poster="">, which allows authors to reference the URL to one image file. That poster attribute has never offered many of the features that today's web images support, like offering multiple responsive resolutions across devices, or negotiating between art-directed image crops (say, to complement a video that serves in both landscape and portrait orientations), or perhaps most importantly, providing alternative text to describe the poster image to folks who use assistive technology.
Clearly, authors and users alike would benefit from poster getting modern improvements. And soon, they very likely will. Work on this began yet again as a hack project at Squarespace this spring, and it's been great fun to shepherd this effort from spirited, thoughtful debate in the issue tracker to drafting a proposal to introduce a new HTML element: <poster>.
As that proposal describes in more detail than most will care to know, the <poster> element will be valid inside a <video> and serve as a container for an <img> (with an optional <picture> parent). When present, the image inside that <poster> will determine the source to be used for the video's poster image.
Assuming it stays in its current shape, it'll look like this:
<video src="skate-clip.mp4" loading="lazy">
<poster>
<picture>
<source srcset="skater-9x16.avif" type="image/avif">
<img src="skater-9x16.jpg" alt="A skateboarder slides down a handrail above a concrete staircase.">
</picture>
</poster>
</video>
I'm showing just a sampling of the available markup here of course–you might want to coordinate multiple art-directed video and picture sources for example, or load eagerly instead of lazily, and add captions for the video. But broadly, by piggybacking on the features that <img> already provides, <poster> will not only give authors full control over responsive poster image delivery (and features like fetchpriority, sizes="auto", decoding, and lazy-loading). But also, for the first time, using img means that poster images can become perceivable and understandable for users with disabilities who rely on assistive technology–by using alt text to describe the poster image.
Admittedly, even as a member of the Community Group that planned picture and srcset, that point about alt is the one I'm most excited about here (picture me making a YouTube face). And I suppose it's pretty neat that this feature will get an HTML tag of its own as well (hat tip to Simon Pieters for pushing for that over other alternatives).
Follow along
This proposal is steadily moving through the WHATWG stages, and my teammate is working on the web platform tests for it as well. We've presented this proposal at WHATWG meetings and it has already received several rounds of helpful feedback from spec maintainers. Mozilla just weighed in with a positive standards position too, which was great to see.
You can follow that public work here, in the HTML Standard's Github Repo:
HTML PR #12585: Introduce HTML
Here's hoping that we see it in browsers soon. And this fall, catch me in Amsterdam this November where I'll be speaking at Performance.Now() about this journey and more broadly, how to get involved in standards work, even when (or especially when?) that's not your primary gig.