The current situation with megabytes of JavaScript is pretty bad, but at the time, there was still a fair bit of dialup active, and mobile web was just starting to be a thing - on EDGE and barely 3G. It would take minutes to load.

Also, Steve Jobs had it in for Flash and that’s what ultimately killed it off, I think.

Yeah, this was my first thought. How many slightly older, no-longer-being-updated pieces of software will fail to open the new version? Hopefully it’s built in a way that it just falls back to legacy and ignores the extra information so you can at least load the file.

But is it backwards compatible with an old version that can't be updated?

I could have sworn animated pngs were a thing in the Macromedia Fireworks days. Really dating myself with that ref.

APNG is what they're using in v3, so all many libraries need to do* is update that code for HDR.

* surely that's easy, right?

Popular photo and video editing apps like Photoshop, DaVinci Resolve, and Avid Media Composer already support it, alongside Chrome, Safari, and Firefox. Apple’s iOS and macOS also work with the new file standard.

This is all the article mentions. I hope you’re right about the backwards compatibility.

It makes sense, right? Is there a way around that when adding new features to a file format?

The alternative is to make another file format for clarity, but it's not really what you want to do.

I mean, that's already how animated .gifs work. If somehow you manage to load one into a viewer that doesn't support the animation functionality it will at least dutifully display the first frame.

How the hell you would manage to do that in this day and age escapes me, but there were a fair few years in the early '90s where you might run into that sort of thing.

I mean, that's already how animated .gifs work. If somehow you manage to load one into a viewer that doesn't support the animation functionality it will at least dutifully display the first frame.

How the hell you would manage to do that in this day and age escapes me, but there were a fair few years in the early '90s where you might run into that sort of thing.

I remember the Wild West Web days when it was a toss up seeing if animated Gifs, transparencies in images, or the specific hexadecimal for your personal shade of purple you created would render properly between browsers.

One example is piefed unfortunately. Animated gifs as avatar or banner don't animate currently as far as I can tell.

Those are displayed in browser, right? The only reason that would be happening is if Piefeed is recompressing images and their code is not smart enough to identify an animated .gif and act accordingly.

Yeah in browser. I should probably open an issue ticket if nobody else noticed yet.

Lies! That gif is sped up 2000%!

But is it backwards compatible with an old version that can't be updated?

That depends. Something like HDR should be able to fall back to non-HDR since it largely just adds data, so if the format specifies that extra information is ignored, there's a chance it works fine.

I'm probably gonna be massively downvoted for saying the forbidden word but I asked AI to do a summary with references of the forward and backward compatibility of PNG's new version:

!

Based on recent search results, the new PNG specification (Third Edition) and its reference library (libpng) maintain strong backward compatibility while introducing modern features. Here's a detailed compatibility analysis:

1. Backward Compatibility (Viewing Old PNGs with New Lib)

• Full Support: The new libpng (1.6.49+) and PNG Third Edition fully support legacy PNG files. Existing PNGs (conforming to the 2003/2004 spec) will render correctly without changes .
• Implementation Stability: Libpng's API evolution (e.g., hiding png_struct/png_info internals since 1.5.0) ensures older apps using png_get_*/png_set_* functions remain compatible. Direct struct access, deprecated since 1.4.x, may break in libpng 2.0.x (C99-only) .
• Security Enhancements: Critical vulnerabilities (e.g., CVE-2019-7317 in png_image_free()) were patched in libpng 1.6.37+, making the new lib safer for decoding old files .

️ 2. Forward Compatibility (Viewing New PNGs with Old Lib)

• Basic Support: Older libpng versions (pre-1.6.37) can decode new PNGs if they avoid new features. Core chunks like IHDR or IDAT remain unchanged .
• New Feature Limitations:
  • HDR Imagery: Requires libpng 1.6.45+ and apps supporting the mDCv chunk. Older libs ignore HDR data, falling back to SDR, which may cause color inaccuracies .
  • APNG Animation: Officially standardized in PNG Third Edition. Older libs (e.g., <1.6) treat APNG as static images, showing only the first frame .
  • EXIF Metadata: New eXIf chunks are ignored by legacy decoders, losing metadata like GPS or copyright info .
• Security Risks: Older libs (e.g., ≤1.6.36) contain unpatched vulnerabilities (e.g., CVE-2015-8126). Parsing malicious new PNGs could exploit these flaws .

Compatibility Summary

Scenario	Compatibility	Key Considerations
Old PNG → New Lib	Excellent	Legacy files work flawlessly; security improved.
New PNG → Old Lib	️ Partial	Basic rendering works, but HDR/APNG/EXIF ignored. Security risks in unpatched versions.
New Features	Conditional	Requires updated apps (e.g., Photoshop, browsers) and OS support .

3. Implementation and Industry Adoption

• Broad Support: Major browsers (Chrome, Safari, Firefox), OSs (iOS, macOS), and tools (Photoshop, DaVinci Resolve) already support the new spec .
• Progressive Enhancement: New features like HDR use optional chunks, ensuring graceful degradation in older software .
• Future-Proofing: Work on PNG Fourth Edition (HDR/SDR interoperability) and Fifth Edition (better compression) is underway .

Conclusion

• Upgrade Recommended: New libpng (1.6.49+) ensures security and full compatibility with legacy files.
• Test Workflows: Verify critical tools handle new features (e.g., APNG animation in browsers).
• Fallbacks for Old Systems: For environments stuck with outdated libs, convert new PNGs to legacy format (e.g., strip HDR/APNG) .

For developers: Use png_get_valid(png_ptr, info_ptr, PNG_INFO_mDCv) to check HDR support and provide fallbacks .

!<

The current situation with megabytes of JavaScript is pretty bad, but at the time, there was still a fair bit of dialup active, and mobile web was just starting to be a thing - on EDGE and barely 3G. It would take minutes to load.

Also, Steve Jobs had it in for Flash and that’s what ultimately killed it off, I think.