[css-images-3] Inconsistent but non-normative advice regarding image metadata and streamability/progressive display

[svgeesus]

In 2.1.2. Image Metadata:

Authors must produce their image files so that such metadata occurs before the image data in the image file. (Note: This is the default for most images already.)

User agents should ignore any layout-impacting metadata (such as orientation or resolution) that occurs after the image data begins in the file. (Note: This rule does not impact metadata that does not affect layout, such as color space information.)

This assumes that layout changes after all the image data has loaded are a problem, while color space changes after all the image data has loaded are a not problem. They are.

As an example, PNG requires that all color space-affecting metadata cHRM, gAMA, iCCP, cICP occurs before the image data (and before the palette, if there is one). This is done specifically to avoid a jarring repaint of the image in different colors.

Other image formats might not impose such a constraint, and thus images will be found where that metadata is after the image data.

Consider a 100-frame animation, which is also on a slow connection; once all the image data loads, suddenly the current frame, all subsequent frames (and for looping animations, all subsequent iterations) have a different appearance.

Suggested fix: delete the informative (and thus, non testable) note "This rule does not impact metadata that does not affect layout, such as color space information".

[svgeesus]

@tabatkins @fantasai @LeaVerou

[ByteEater-pl]

It's unsettling that the fragment mentions files – a concept mostly foreign to Web standards – instead of resource representations. If understood literally, it's narrower and probably doesn't cover over 99% cases of online usage.

[ByteEater-pl]

More to the point raised, it assumes a lot about architecture of user agents. If they rely on an external component, e.g. an OS library, to handle some image format, and that component doesn't support conditionally ignoring metadata based on its location, this requirement becomes unimplementable. It's just a SHOULD, but the outcome of having the metadata ignored in some implementations but not others seems highly undesirable.

Another problem is that it may be difficult for authors to follow this guidance. I know of no graphics authoring software that outputs images in a format allowing metadata to be placed at either location and specifically exposes this choice.