Video Elements Lost the Ability to Adapt

Scott Jehl has been vocal about a regression in the HTML spec: <video> used to accept a media attribute on its <source> children, letting authors declare different files for different screen sizes. That capability was implemented and then removed from browsers and the specification. The one holdout is WebKit, so Safari still honors it today.

Jehl’s complaint is straightforward: without media support, every video embed forces a binary choice — serve a file that is too large for small devices or one that is too small for large screens. The result is wasted bandwidth, slower loading, or degraded quality, with the only alternatives being custom server logic, JavaScript, or a third-party host.

A Deviation from Platform Norms

The web platform is famous for preserving backwards compatibility. A removal like this is rare; removing a feature and leaving no replacement is rarer still. The trace of this decision exists in a GitHub issue where the reasoning behind the removal was questioned, but the outcome stands.

The irony is that responsive images — which used to be the feature that people explained by analogy to video — worked out well. The sizes and srcset attributes on <img> are broadly adopted and have saved considerable bandwidth since their introduction.

What Works Today Without Native Support

In the absence of a platform feature, one common interim approach is to use an image and video CDN that supports dynamic resizing. Cloudinary, for instance, can accept a video URL and automatically select a codec while constraining the output width, as in this example:

https://res.cloudinary.com/css-tricks/video/upload/c_scale,q_auto,vc_auto,w_400/v1612795501/intro-patreon_jpd8er.mp4

This kind of flexibility is useful for a production site, but it also highlights the gap: a platform feature that once existed would let us handle responsive video without leaning on an external dependency.