Skip to content

Add image formats #27168

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
+639 −0
Open

Add image formats #27168

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
e1e70dd
Add image formats
caugner Jun 27, 2025
be139cd
Add new media top-level object to README
caugner Aug 14, 2025
cfc75b4
Merge branch 'main' into 6971-image-formats
caugner Aug 14, 2025
e6eb726
Merge branch 'main' into 6971-image-formats
caugner Aug 26, 2025
6381f06
Chromium unshipped JPEG XL
caugner Aug 26, 2025
fdf5942
Remove GIF animation (same support as parent)
caugner Aug 26, 2025
d74068b
Add HEIC/HEIF bugs
caugner Aug 26, 2025
39ed6e2
Rename HEIC to HEIF
caugner Aug 26, 2025
08676cd
Refine Safari data for AVIF
caugner Aug 26, 2025
71439fb
Safari doesn't support JPEG XL with animated images
caugner Aug 26, 2025
aabc88e
Add Edge/IE image format data
caugner Aug 26, 2025
9b5bc6e
Add WebP subfeatures
caugner Aug 26, 2025
cedc106
Refine Opera data for WebP
caugner Aug 26, 2025
a13d724
Merge branch 'main' into 6971-image-formats
caugner Oct 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/labeler.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,10 @@ data:mathml:
- changed-files:
- any-glob-to-any-file:
- "mathml/**"
data:media:
- changed-files:
- any-glob-to-any-file:
- "media/**"
data:svg:
- changed-files:
- any-glob-to-any-file:
Expand Down
1 change: 1 addition & 0 deletions .github/workflows/system-file-changes.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@ on:
- "!javascript/**.json"
- "!manifests/**.json"
- "!mathml/**.json"
- "!media/**.json"
- "!svg/**.json"
- "!webassembly/**.json"
- "!webdriver/**.json"
Expand Down
1 change: 1 addition & 0 deletions .vscode/settings.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@
"/javascript/*.json",
"/manifests/*.json",
"/mathml/*.json",
"/media/*.json",
"/svg/*.json",
"/webdriver/*.json",
"/webextensions/*.json"
Expand Down
8 changes: 8 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,6 +183,14 @@ Data for [MathML](https://developer.mozilla.org/en-US/docs/Web/MathML) features,

- `elements` - Elements

### [`media`](./media)

Data for [Media format](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats) features, including:

- `formats/image` - Image formats

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`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ddbeck Is the above an acceptable compromise?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### [`svg`](./svg)

Data for [SVG](https://developer.mozilla.org/en-US/docs/Web/SVG) features, including:
Expand Down
Loading