Scott Jehl 毫不留情地 指出这里
从 HTML 视频中移除
media支持是一个错误。这意味着对于我们在 HTML 中嵌入的每个视频，我们都只能选择提供可能对许多用户设备而言过大或过小的源文件（导致性能低下，浪费数据消耗，甚至在大屏幕上质量下降），或者求助于更复杂的服务器端、脚本或第三方解决方案来提供正确的大小。
我记得响应式图像刚开始出现的时候。解释它的一种方式是说它就像 <video> 一样，您可以在其中包含多个 <source> 元素（在支持的浏览器中），允许您指定诸如 type（例如视频格式）和 media（例如屏幕尺寸）之类的属性。 但 然后…
尽管该功能在多个浏览器中实现，但它已被从浏览器和 HTML 规范中移除，没有提出任何替代方案来取代它曾经提供的功能。唯一的例外是该功能从未从 Webkit 中移除，因此它仍然可以在 Safari 浏览器中使用，这很棒。
我不记得了。这感觉像是 WTF 的时刻（一些背景信息）。我认为网络在向后兼容性方面非常出色。我们很少只是取消一些功能，而更罕见的是没有替代方案的取消。
所以现在响应式图像已经取得了成功（它成功了吗？我无法想象它为世界节省了多少带宽）… 我们不能…把它放回去吗？
当我急需这个功能时，我总是想到 Cloudinary，因为我可以通过更改 URL 来改变视频的大小和格式。例如，这是一个视频 URL，其中视频编解码器会自动确定，并且大小被强制缩小到 400px
https://res.cloudinary.com/css-tricks/video/upload/c_scale,q_auto,vc_auto,w_400/v1612795501/intro-patreon_jpd8er.mp4拥有这样的工具很好，但这并不意味着平台不应该提供帮助。
希望随着围绕 HLS/DASH 和 CMAF 的工具和浏览器支持的改进，这个问题将逐渐消失。
换句话说，构建过程将尽可能无缝地包含一个步骤，即“将此 4K 超高清源视频作为输入，并输出一个包含各种视频流的清单，以服务于各种设备和带宽条件。”
我们还没有做到这一点，但已经取得了一些进展（例如 AWS Elemental MediaConvert）。
视频资源是响应式的，而且比大多数网络资源更好：现代视频编解码器/容器已经处理了客户端功能的静态和动态变化。客户端主机（浏览器）确实比最终用户（开发人员）更了解。
我希望更多努力投入到消除其他网络技术（如字体和图像，尤其是 JS）中的类似条件语句。我们很幸运能够拥有基本开发原语，它们可以自动适应带宽和用户偏好，而无需无数文章和解决方法。
这是一个好主意