[css-images] Should EXIF image orientation data be ignored if it comes after the image data in the encoded image?

[smfr]

There was some discussion in https://github.com/w3c/csswg-drafts/issues/4165 about whether, in CSS images, EXIF image orientation should be ignored based on where it occurs in the encoded image file. Browsers seem, to some extent, to only respect EXIF if it occurs before the image data. If it comes at the end of the file, respecting it there might result in layout shifts as progressively loaded images rotate after loading.

Spec text is here.

[smfr]

Some complications:

• What if some future image format puts EXIF in the middle of the file?
• EXIF is per-frame, so for an animated (or multi-representation) image, the spec needs to be more nuanced.
• Implementations may not know, from their underlying image decoders, where the data is located in the file.

[smfr]

@svgeesus

[svgeesus]

Related:

• https://github.com/w3c/png/issues/310

[smfr]

I confirmed that Core Graphics/ImageIO APIs on macOS/iOS don't tell us the ordering of the EXIF metadata in the file. Behavior differences here may be happenstance based on when we try to access the data.

[jfkthame]

FWIW, it seems fundamentally wrong to me that we should get a different result depending where in an image file the EXIF metadata occurs (unless, of course, the image file format specifies that it's only valid in a certain place).

I understand there's a concern that

If it comes at the end of the file, respecting it there might result in layout shifts as progressively loaded images rotate after loading

but to address that, authors should be advised to web-optimize their images by ensuring the EXIF metadata is at the beginning. (Surely there must be tools available that can do this?)