What is the issue with the HTML Standard?

UPDATED: April 23, 2026

The video element currently offers a single poster attribute, which allows us to load one poster image source. This is limiting when attempting to deliver an appropriate poster image size depending on browsing conditions and art-directed video sources. Additionally, the poster frame itself does not offer a means of describing/exposing the poster image itself in the accessibility tree.

Primary proposed solutions in exploration

In the discussion thread below, two approaches are being explored as potential ways to bring responsive image selection to poster, and make poster accessible:

Approach 1.

Allowing an img element (and optional picture element parent) to be valid child elements of the video element, with the child img's currentSrc property acting as a controller for the value of the video poster (overriding the poster attribute when present). A new posterfromimg attribute would enable this relationship, and serve a dual purpose of preventing pre-existing arbitrary fallback img content from controlling a poster, and notifying browsers to not immediately fetch the poster attribute and look within instead. The full plan for this proposal is bulleted out here, and the original idea for this was here.

<!--basic, common usage for resolution-based switching -->
<video src="video.webm" poster=”video.webp” posterfromimg>
   <img srcset="video-small.webp 500w, video.webp 1000w" sizes="(max-width: 500px) 100vw, 100vw" alt="a description of the poster image here">
</video>

<!--art-directed usage-->
<video src="square-crop.webm" poster=”square-crop.webp” posterfromimg>
       <source media="(min-width: 60em)" src="wide-crop.webm">
       <picture>
         <source srcset="wide-crop.webp" media="(min-width: 60em)">
         <img src="square-crop.webp" alt="a description of the poster image here">
    </picture>
</video>

The pattern uses for resource selection, fetching, and defining alternative text, honoring its own src/srcset/sizes/alt/crossorigin/referrerpolicy/fetchpriority/decoding/loading attributes where relevant. The width and height attributes will be ignored, instead using the <video> element’s layout box. The alt text for the poster should be described through the UA's video player interface, and only while the poster is displayed (not while the video is playing).

Approach 2.

Extend the video and its source element childnodes with new attributes: postersrcset, postersizes, and posteralt, which could be set initially on the video element to provide srcset-style image resolution switching, and on child source elements to override the parent video element's attributes when a source matches. Whether there's good reason to have posteralt on video and source elements or just the video element is debatable.

<!--basic, common usage for resolution-based switching -->
<video src="video.webm" poster=”video.webp” postersrcset="video-small.webp 500w, video.webp 1000w" postersizes="(max-width: 500px) 100vw, 100vw" posteralt="a description of the poster image here">
</video>

<!--art-directed usage-->
<video src="square-crop.webm" poster=”square-crop.webp” posteralt="a description of the poster image here">
       <source media="(min-width: 60em)" src="wide-crop.webm" postersrcset="wide-crop.webp">
</video>

Pros & Cons

Both options appear roughly comparable in their ability to address the core needs of the issue.

The benefits of approach 1 are that it leans on existing HTML elements and uses composability, and brings some unique control to poster such as the ability to use fetchpriority for posters on LCP elements, and crossorigin and image decoding features that poster cannot currently use. It'll also benefit from any future improvements to the img and picture element.

Approach 2 on the other hand, brings benefits of being less verbose for art-directed use cases: existing video source elements can gain postersrcset attributes to override the poster image and share the existing <source> elements' media attributes. On the other hand, this approach some surface area to two HTML elements' IDL with the addition of 3 new-to-HTML attributes each. Browser implementations for postersrcset, postersizes, and posteralt would need to freshly introduce these concepts to elements, likely by reusing srcset and accessibility helpers from other elements that use these patterns already.

Comparison Table

This comment attempts to summarize the pros and cons in more depth.

Thanks!