Scott Jehl doesn’t mince words here:
Removing
media
support from HTML video was a mistake. It means that for every video we embed in HTML, we’re stuck with the choice of serving source files that are potentially too large or small for many users’ devices (resulting in poor performance, wasteful data consumption, and even sub-optimal quality on larger screens), or resorting to more complicated server-side or scripted or third-party solutions to deliver a correct size.
I remember when responsive images were just starting to come out. One way to explain it was to say it’s like <video>
in that you can have multiple <source>
elements inside which (in supporting browsers) allowed you to specify attributes like type
(e.g. video format) and media
(e.g. screen size). But then…
Despite being implemented in multiple browsers, the feature was removed from browsers and the HTML specification, without any proposed replacement for the functionality it once provided. One exception is the feature was never removed from Webkit, so it still works in Safari browsers, which is great.
I don’t remember that. That feels like a big WTF moment (some background). I think of the web as being tremendous at backwards compatibility. It’s a rare day when we just yank stuff, and even more rare is a yanking with no alternative whatsoever.
So now with responsive images being a success (it’s a success, right? I can’t imagine how incredibly much bandwidth it has saved the world)… can’t we… put it back?
When I have an immediate need for this, I always think of Cloudinary, because I can alter the size and format of video by changing the URL. Like here’s a video URL where the video codec is automatically determined and the size is forced down to 400px:
https://res.cloudinary.com/css-tricks/video/upload/c_scale,q_auto,vc_auto,w_400/v1612795501/intro-patreon_jpd8er.mp4
It’s nice to have tools like this, but that doesn’t mean the platform shouldn’t be helping.
Hopefully, as tooling and browser support around HLS/DASH and CMAF improves, this problem will fade away.
In other words, the build process will, as seamlessly as possible, include a step to “take this 4K ultra-high-quality source video as input, and output a manifest with a suitable variety of video streams to serve a reasonably wide range of devices and bandwidth conditions.”
We’re not there yet, but there has been progress (e.g. AWS Elemental MediaConvert).
Video resources are responsive, in a much better way than most web resources: modern video codecs/containers already handle both static and dynamic variation in client capabilities. The client host (browser) really does know better than the end users (developers).
I wish more effort was put into eliminating similar conditionals from other web technologies like fonts and images and, especially, JS. We could be so lucky as to have basic dev primitives that automatically adapt to bandwidth and user preference without a zillion articles and workarounds.
Its great idea