[css-images] Should CSS decorative images respect EXIF-orientation by default

[smfr]

https://drafts.csswg.org/css-images/#the-image-orientation says that image-orientation only affects content images, not decorative images.

But what is the default orientation for a decorative image (e.g. CSS background) which has EXIF data that describes a rotation?

[tabatkins]

Undefined by this specification!

But it obviously makes sense to align with image-orientation, and say that you respect EXIF.

[frivoal]

That makes sense indeed, but is it web compatible?

[smfr]

It's also odd that image-resolution is specified to affect "all raster images used in or on the element. It affects both content images (e.g. replaced elements and generated content) and decorative images" but image-orientation is not.

Another option would be to have an argument to the image() function that allows image-orientation-like control.

[css-meeting-bot]

The CSS Working Group just discussed Should CSS decorative images respect EXIF-orientation by default, and agreed to the following:

• RESOLVED: default behavior for all images to respect exif orientation

The full IRC log of that discussion

<dael> Topic: Should CSS decorative images respect EXIF-orientation by default
<dael> github: https://github.com//issues/4165
<dael> astearns: Added by smfr
<dael> smfr: Cleaning up issues for if images respect EXIF. Question came up if decorative ones should respecte exif. Should we allow authors to control orienation in decorative images?
<dael> smfr: Simple question is do decorative images respect exif by default
<dael> AmeliaBR: I think default behavior should be to respect it, esp if that's the default for content images. We should be consistent unless there is webcompat reasons
<dael> AmeliaBR: Like having extra param that can change things. Adding the extra shouldn't delay spec default
<dael> fantasai: Default behavior will have to go in L3, image function is in L4 so it would go there
<dael> smfr: One data point I don't think w have web compat data b/c no platform has respected exif for decorative images by default
<dael> astearns: Disctinction between content and docorative is backgroud?
<dael> smfr: Yeah. Content images are images in replaced elements
<dael> AmeliaBR: Instead of decorative we should say css images. Images spec through css prop. Exception is content property. New image orientation would effect images embedded using content
<dael> fantasai: Yeah. Early defined replaced to work using content property. Def interchangable. List markets and background images and stuff are not replace in box tree. Content images are
<dael> smfr: Images in SVG too which we haven't talked about
<AmeliaBR> s/New image orientation/New image-orientation property/
<dael> astearns: Concern was on compat for spec default to honor exif. Do you have any idea of what % images used on web have exif data?
<dael> smfr: TabAtkins had data. It's less common to use thing with exif data as decorative. I'm not as concerned as I was with content images. We can try and see what happens
<dael> astearns: I know people use background image for content data. I think it would be surprising to take a URL that's an image, but it in background and it flips
<TabAtkins> Yeah agree.
<dael> fantasai: Agree with AmeliaBR default should be consistent between all the images
<TabAtkins> Should agree unless there's compelling compat data.
<dael> smfr: Happy to resolve now and come back if compat
<dael> astearns: Prop: default behavior for all images to respect exif orientation
<dael> astearns: Additional concerns?
<dael> astearns: Obj?
<dael> RESOLVED: default behavior for all images to respect exif orientation
<dael> astearns: My understanding is we do not yet have param in image function to override in next module
<dael> fantasai: No. Inclination is not to add unless authors say they want this. We've historically had problems getting image-orientation impl so I'd rather not add without demand
<fantasai> s/image-orientation/image()/
<dael> AmeliaBR: Have vauge resolutions to add params to control image for things like lazy-load. Once we get all that ecosystem of params maybe this gets added in if there is demand
<dael> astearns: Seems fine place to leave it. Anyone want to fight to put in a param now?
<dael> smfr: I think it's fine. Agree with fantasai to wait
<dael> smfr: It is odd we have image-resolution apply to all aster but image-orientation is content images. Should think in the future
<dael> AmeliaBR: Re-access image resolution?
<dael> smfr: I would go in other where image-orientation should effect all images.
<dael> astearns: Since we're consistent in orientation data, consisten in orientation prop makes sense
<dael> fantasai: Reason why not is that images typically come from different sources. Might have a bunch of SVG used for background or border. NOt going to want to have that roate but might correct rotatio os a photograph. Discussed this in the past and decided does not effect anything other then content and images
<dael> fantasai: Makes sense to be consistent on exif. I don't think explicit values need to be everywhere. I don't think orientation wants to effect decorative and content
<dael> smfr: from-image is the only one you'd care abuout for css images
<dael> AmeliaBR: ONly you can assume applies to many images. If you had content and bg images wouldn't nec. align. Prob try for image-resolution prop. might be worth considering finger grain control there. I don't know if there are impl of that to get author feedback
<dael> fantasai: Idea was for css images that we would address use case to override explicit orientation through image()
<dael> astearns: Sounds like we're toward no change for rest of questions in issue. Correct?
<dael> fantasai: Open to adding image oritentation overrides in image() if there's demand. Defeault is respect exif
<dael> astearns: Then let's close this issue.

[zcorpan]

Can it be clarified what the above resolution means, in more detail? (To the extent that I or someone else could propose a PR and write tests.)

[heycam]

It's unclear from the meeting minutes whether it's intended that image-orientation affects CSS images used in an element, or if the orientation metadata in the image should unconditionally be honored.

Chrome Canary does look at image-orientation on the element, and a recent WebKit build with support for image-orientation does not (and always follows the orientation metadata).

[svgeesus]

@zcorpan wrote:

Can it be clarified what the above resolution means, in more detail? (To the extent that I or someone else could propose a PR and write tests.)

It seems to mean that EXIF orientation is always respected, if it occurs before the image data in the file; and always ignored, if it is afterwards.

[svgeesus]

@tabatkins @fantasai @LeaVerou