I think the way to go for browsers is to support new codecs (as long as they're plausibly useful for the web, royalty-free, etc), but to avoid getting stuck wit

I think the way to go for browsers is to support new codecs (as long as they're plausibly useful for the web, royalty-free, etc), but to avoid getting stuck with them by having web devs assume they can use codecs without content negotiation / fallbacks. So e.g. they could randomly in 1% of the requests pretend only to support the legacy codec (say jpeg and png for images, or h264 for video), which basically forces web devs to put proper fallbacks in place (using multiple sources, or using http content negotiation) since otherwise random parts of their website would just be broken. Putting those fallbacks in place is needed anyway: it's just a bad practice to ignore the long tail of browsers that don't support the latest codecs yet. The 1% "fallback-only" requests would mainly be a way to force web devs to take that long tail seriously since they would notice the failures even when testing only on Chrome. That way, we can get 99% of the compression gains of new codecs right now, without having to wait until a codec gets sufficient traction outside the web, and without getting stuck with the codec forever if it turns out not to be that great after all, or if a better alternative shows up. If it does turn out to be great and it gets ubiquitous support everywhere (like JPEG and PNG), then it can be considered to make it a permanent addition to the web platform, i.e. make it part of the "fallback formats" pool instead of the "99% of the requests" pool. The web platform needs a long-term media codec deprecation strategy. It needs to be a better strategy than just resisting any change until a codec has become ubiquitous and unavoidable — the web is an extremely important use case for media compression, and it's at this point unlikely that new codecs can even become ubiquitous when they cannot be used for this key use case. I think the strategy of "enable by default but only for 99% of requests", as bizarre as it may seem at first glance, would be a good way to make progress without adding irreversible bloat to the web platform at every step.