W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2019

Re: [csswg-drafts] [css-images] Should CSS decorative images respect EXIF-orientation by default (#4165)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Aug 2019 23:24:32 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-519304078-1565220271-sysbot+gh@w3.org>
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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Should CSS decorative images respect EXIF-orientation by default<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4165<br>
&lt;dael> astearns: Added by smfr<br>
&lt;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?<br>
&lt;dael> smfr: Simple question is do decorative images respect exif by default<br>
&lt;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<br>
&lt;dael> AmeliaBR: Like having extra param that can change things. Adding the extra shouldn't delay spec default<br>
&lt;dael> fantasai: Default behavior will have to go in L3, image function is in L4 so it would go there<br>
&lt;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<br>
&lt;dael> astearns: Disctinction between content and docorative is backgroud?<br>
&lt;dael> smfr: Yeah. Content images are images in replaced elements<br>
&lt;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<br>
&lt;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<br>
&lt;dael> smfr: Images in SVG too which we haven't talked about<br>
&lt;AmeliaBR> s/New image orientation/New image-orientation property/<br>
&lt;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?<br>
&lt;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<br>
&lt;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<br>
&lt;TabAtkins> Yeah agree.<br>
&lt;dael> fantasai: Agree with AmeliaBR default should be consistent between all the images<br>
&lt;TabAtkins> Should agree unless there's compelling compat data.<br>
&lt;dael> smfr: Happy to resolve now and come back if compat<br>
&lt;dael> astearns: Prop: default behavior for all images to respect exif orientation<br>
&lt;dael> astearns: Additional concerns?<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: default behavior for all images to respect exif orientation<br>
&lt;dael> astearns: My understanding is we do not yet have param in image function to override in next module<br>
&lt;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<br>
&lt;fantasai> s/image-orientation/image()/<br>
&lt;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<br>
&lt;dael> astearns: Seems fine place to leave it. Anyone want to fight to put in a param now?<br>
&lt;dael> smfr: I think it's fine. Agree with fantasai to wait<br>
&lt;dael> smfr: It is odd we have image-resolution apply to all aster but image-orientation is content images. Should think in the future<br>
&lt;dael> AmeliaBR: Re-access image resolution?<br>
&lt;dael> smfr: I would go in other where image-orientation should effect all images.<br>
&lt;dael> astearns: Since we're consistent in orientation data, consisten in orientation prop makes sense<br>
&lt;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<br>
&lt;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<br>
&lt;dael> smfr: from-image is the only one you'd care abuout for css images<br>
&lt;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<br>
&lt;dael> fantasai: Idea was for css images that we would address use case to override explicit orientation through image()<br>
&lt;dael> astearns: Sounds like we're toward no change for rest of questions in issue. Correct?<br>
&lt;dael> fantasai: Open to adding image oritentation overrides in image() if there's demand. Defeault is respect exif<br>
&lt;dael> astearns: Then let's close this issue.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4165#issuecomment-519304078 using your GitHub account
Received on Wednesday, 7 August 2019 23:24:35 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:51 UTC