5 ms·

For SVG there are standards that define how to interact with unknown elements, and a set of standard elements which are actually part of the spec. With PNG, the

by jdiff 2y ago

For SVG there are standards that define how to interact with unknown elements, and a set of standard elements which are actually part of the spec. With PNG, there's a minimum set of chunks that are required, and you can safely stick with those and get something that works for the vast majority of cases. This is totally different from a container which can contain any type of data in any type of format. If you get a valid PNG, you can load something meaningful from it. If you get a generic container, you might be able to inspect it at a surface level but there's no guarantee that the contents are even conceptually meaningful to you.

layer8 2y ago
Effectively the same is true for IFF-compliant formats like ILBM and AIFF, which are usually distinguished either by file extension or by file-system metadata. It’s a bit like criticizing a format for being XML-based, under the argument that XML can represent all kinds of payloads.
- jdiff 2y ago
  That's exactly what I'm working towards. It's the difference between just using an XML file and using an XML file with a unique extension tacked onto it. It represents a subset with set expectations for behavior. That expectation is what matters. For generic containers, there are no expectations on what's inside. If I'm making a video player, do I support MKV? Well, some of them. Not all of them. You have to try it and find out. Heck, even within a single codec it's hard to find complete support. Last I checked, browsers won't touch an H264 stream unless it's also YUV420p which also places certain restrictions on physical dimensions of the data and probably some other stuff that's escaping my mind. If I'm making an image viewer, do I support SVG or PNG? For this example, let's say I only support PNG, but I can tell from the outset what's inside any file I might try to load. I can confidently say I can meaningfully load and display anything that uses the established standards of the PNG format to store image data. Sure, there are extensible bits, but they're not part of those core expectations surrounding the core part of the format, the image data I care about. And I didn't have to try and open the PNG first to see if it was actually an SVG. I can recognize not-bitmaps at a glance without having to inspect them any deeper than their extension.

by jdiff 2y ago

layer8 2y ago

Effectively the same is true for IFF-compliant formats like ILBM and AIFF, which are usually distinguished either by file extension or by file-system metadata. It’s a bit like criticizing a format for being XML-based, under the argument that XML can represent all kinds of payloads.

jdiff 2y ago
That's exactly what I'm working towards. It's the difference between just using an XML file and using an XML file with a unique extension tacked onto it. It represents a subset with set expectations for behavior. That expectation is what matters. For generic containers, there are no expectations on what's inside. If I'm making a video player, do I support MKV? Well, some of them. Not all of them. You have to try it and find out. Heck, even within a single codec it's hard to find complete support. Last I checked, browsers won't touch an H264 stream unless it's also YUV420p which also places certain restrictions on physical dimensions of the data and probably some other stuff that's escaping my mind. If I'm making an image viewer, do I support SVG or PNG? For this example, let's say I only support PNG, but I can tell from the outset what's inside any file I might try to load. I can confidently say I can meaningfully load and display anything that uses the established standards of the PNG format to store image data. Sure, there are extensible bits, but they're not part of those core expectations surrounding the core part of the format, the image data I care about. And I didn't have to try and open the PNG first to see if it was actually an SVG. I can recognize not-bitmaps at a glance without having to inspect them any deeper than their extension.