Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

Something I think is essential to landing this would be a documented (and very sharp) definition of what qualifies as support for these features. Though they implicate support for HTML, CSS, and web API features, the new top-level namespace implies a different scope. It'd be great to be explicit about what that scope is.

(Automated tests could also serve as a definition of supported, but I don't know how practical that is.)

We discussed this in today's BCD meeting, and agreed to (1) compare the data with caniuse to spot any important omissions, and to also (2) ask @Fyrd if and how he would merge this data into the existing caniuse data for image formats.

What's being proposed here for image formats looks sensible to me. Even though images can be used in many contexts (<img>, CSS backgrounds, ImageDecoder, canvas toBlob(), favicons, etc.) I think it basically make sense to talk about support for AVIF as one thing, and use notes of subfeatures for things of interest that don't work.

For audio and video codecs, it's a bit trickier since it's a combination of container and multiple codecs. https://caniuse.com/webm tracks a specific combination of container and codecs, but https://caniuse.com/av1 tracks a specific video codec without reference to a container. There's also a more complicated history of support for codecs in specific containers, having decode-only vs. decode and encode, etc.

But this PR isn't about audio and video codecs, so we don't need to settle those questions here.