Add image formats

[caugner]

Summary

Introduces the media top level directory, and adds image formats under media.formats.image.

Test results and supporting details

Sources:

• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types (for Edge, Opera, Samsung Internet)
• BrowerStack Live with the following test cases:
  • http://bcd-examples.gh.caugner.de/media/images/ for most browser versions
  • http://bcd-examples.gh.caugner.de/media/images/noscript.html for Safari 1/2/3, and to test inline SVG

Related issues

Part of #6971.

[github-actions]

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

[ddbeck]

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.)

[caugner]

@ddbeck What do you think about this?

PS: Would it be better to move /media/formats/image to /media/image-formats, to avoid the unnecessary nesting?

[ddbeck]

I guess now I'm wondering what the media name space would contain that is not a format? Seems like maybe the top-level key could be formats or media-formats, with images as the next level. The only other thing we've discussed is video formats, right? So maybe the hypothetical future looks like this?

.
├── api
├── css
├── …
└── media-formats
    ├── images
    │   ├── avif.json
    │   ├── bmp.json
    │   ├── gif.json
    │   └── …
    └── video-containers
        ├── 3gp.json
        ├── mov.json
        ├── mp4.json
        ├── ogg.json
        └── …

Also note the pluralization there. Most everywhere else is plural (elements, at-rules, builtins, etc.).

[ddbeck]

Sorry, I didn't answer the original question.

An image format is considered supported if it displays correctly when used in an <img> element's src attribute, or as a CSS background-image.

Some questions back to you:

• "or" suggests that as long as it works in at least one of these, it qualifies as full support. What about something like ico, where the primary use case is neither of the two? Do we make an exception for that?

• "correctly" seems pretty imprecise. How wold you know if it were incorrect? Maybe it'd be better to frame this as a set of specific expected characteristics (e.g., no distorted colors, shows transparency if applicable, aspect ratio corresponding to the image data, etc.) that we could "test" (procedurally if not programmatically)?

  This is a place where some user research or testing would be good—to find out what developers think of when a format is "supported."

[caugner]

I guess now I'm wondering what the media name space would contain that is not a format?

Maybe media.images would be a good compromise, as it avoids the terms codec and format altogether, and we can just use those terms where necessary in the individual feature's key and/or description.

• "or" suggests that as long as it works in at least one of these, it qualifies as full support.

Good point, agree.

• "correctly" seems pretty imprecise.
• frame this as a set of specific expected characteristics (e.g., no distorted colors, shows transparency if applicable, aspect ratio corresponding to the image data, etc.)

Agree that framing around expectation is better, so how about:

Suggested change

	An image format is considered supported if it displays correctly when used in an `<img>` element's `src` attribute, or as a CSS `background-image`.
	An image format is considered supported if it displays as expected (e.g., no distorted colors, shows transparency if applicable, aspect ratio corresponding to the image data, etc.) when used in an `<img>` element's `src` attribute, and when used as a CSS `background-image`.

• This is a place where some user research or testing would be good—to find out what developers think of when a format is "supported."

I don't think user research or further testing is justified at this time.

If we receive feedback that the data is incomplete, incorrect, or misleading, we can refine. Most likely we can address feedback by adding subfeatures, either under the media format, or under the feature that the specific use case or expectation relates to (cf. HTMLCanvasElement: toBlob() method).

[caugner]

@ddbeck Is the above an acceptable compromise?

[ddbeck]

I don't think user research or further testing is justified at this time.

If we receive feedback that the data is incomplete, incorrect, or misleading, we can refine. Most likely we can address feedback by

I think this gets at the heart of the matter for me: it's easy to add things but harder to take them away. If we're wrong we might hear about it, but if we're irrelevant, then we might never get any feedback (and maintain data for no real purpose). Indifference is a failure mode I care about as much as being correct—and perhaps more, in this particular case, given the potential costs of maintaining a deep matrix of support information.

I'm not asking for something heavy-weight here, but I think we should be able to point at something (some blog posts or Stack Overflow questions or social media posts would be enough) that shows that the definition of supported we're choosing matters (to anyone beyond some completionist tech writers 😅).

[ddbeck]

Maybe media.images would be a good compromise, as it avoids the terms codec and format altogether, and we can just use those terms where necessary in the individual feature's key and/or description.

I guess I don't mind that structure, but I worry a little about vagueness. "Media" gets used in lots of places (media queries, media devices, media streams, etc.) and I think being specific in some way would make this easier to talk about and maintain, if nothing else.

[caugner]

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.

[caugner]

Compared the data with Can I use.

[caugner]

According to https://caniuse.com/webp, Chrome 9 added WebP support, but I couldn't confirm this with my own tests. It was possibly only behind a flag.