I've hidden the diversion due to confusion. ^_^

So bringing us back:

Chrome, Safari, and Firefox all now respect image-orientation: from-image on JPGs (in their latest versions, make sure you're updated), as shown in https://ericportis.com/etc/PNG-EXIF-orientation/.

Chrome and Firefox don't currently support it on PNGs at all (but plan to fix that). Safari does support EXIF on PNGs, but only if it comes before the image data (the PNG spec technically allows it to show up before or after). (The test linked above has the EXIF after the image data.)

Orientation data showing up after the image data is hostile to streaming display of the image: it'll progressively render one way, then flip at the very end, and that's assuming your rendering pipeline even allows changing orientation after-the-fact (apparently Safari's doesn't currently).

So! Given that, should the spec allow (or mandate) ignoring image-derived orientation if it comes after the image data?

It would be reasonable for the relatively recent (2017) specification for EXIF in PNG to add a recommendation to put EXIF data before the IDAT (image data) chunk, in section 3.7.3 eXIf Recommendations for Encoders.

I think it should be mandated (and tested), otherwise you get a race to the bottom.

The CSS Working Group just discussed Allow impls to not respect exif data if it's after the image data, and agreed to the following:

• RESOLVED: UAs should ignore exif data that comes after image data
• RESOLVED: Authors MUST NOT put exif data after the image data

See official minutes

It might be helpful to differentiate between render-impacting and non-render-impacting metadata, and not be specific about the EXIF metadata format.

Encoders often want to put non-render-impacting metadata after the image data, so that image data is received (and in the case of progressive formats, can be painted) ASAP. See for instance, the suggested order of "extended" WebP metadata: https://developers.google.com/speed/webp/docs/riff_container#extended_file_format

Some formats may go further and mandate, rather than suggest, that EXIF come after. I think JPEG-XL does this? (though, IIRC, it has special-purpose format-specific metadata fields for render-impacting things like orientation and resolution that must come before image data). cc: @jonsneyers

That's a good clarification, and one I'm happy to adopt.

I'm not happy with @smfr's example and using that as justification for "should" rather than "must". Perhaps it is out of place for CSS to say something about images, but I think for the web we should have a consistent image model across implementations and it definitely shouldn't depend on the size of the image what ends up happening. That will lead to confusion for web developers.

If the concern is really about CSS defining it, perhaps image fetching and decoding should be in its own document?

Can you clarify what makes you unhappy? His justification is that the image decoder in use may simply not have the ability to report that data; as such, making it a MUST requirement would effectively require a switch or rewrite of the image decoder, which seems like a pretty big request to make.

His second reason, about small images, I agree is bad; the size of the image shouldn't have an effect here.

The owner of the requirement won't make any difference to the issues raised here.

Having standardized image decoders across the web platform does not seem like a big request? Why would we accept non-interoperability there?

Because the browser vendors in the room expressed their discomfort at that sort of requirement.

In the JPEG XL file format, you can put the Exif data where you want, but for web use cases, we define an abbreviated 'file format' that is just a 'naked' JPEG XL codestream without any metadata.

All render-impacting metadata is defined in the JXL codestream, and if the optional Exif (or XMP) metadata says something that conflicts with what the codestream says, then a decoder has to ignore the Exif/XMP. The codestream is the single source of truth. This includes image dimensions, bit depth, number of channels, image orientation, intrinsic dimensions, and color space. In the codestream these things are part of the header, and are always put before the actual image data in the bitstream. Otherwise you cannot do meaningful progressive decoding.

Fixed in a426128

@smfr Could you review?

@tabatkins should this issue be closed?

It looks like web-platform-tests/wpt#26915 tests this. Correct?

It looks like the spec edits are done and WPT in place. @fantasai Close?

I'd just asked for a review before closing, but after a year and a half of waiting (and WPT enforcing it) I think it's safe to close as completed. ^_^