[css-images] Consider changing initial value of 'image-orientation' to from-image

[zcorpan]

Spec: https://drafts.csswg.org/css-images/#propdef-image-orientation

See related issue in HTML: whatwg/html#4495 (and earlier discussion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 )

or, we could change the initial value of image-orientation from none to from-image (cc @tabatkins ), so all images are rotated "correctly" by default. Use counter data from 2016 found affected images to be ~0.00% of all images.

Browsers not respecting EXIF orientation of images by default everywhere on the web seems to continue to be an annoyance for web developers. Earlier analysis suggests that it would be a net benefit to make this change, and the risk of breakage is at most ~0.00% of images. There has been interest from some implementors to try to change the default, but it hasn't happened yet (except for iOS Safari to some extent).

[drewm]

I'm a commercial CMS developer and encounter people confused by the current default not acting in the same way as literally all the rest of the software they're using. Nobody I've encountered is seeing this and just leaving it wrong on their site, so low in-the-wild numbers make sense, but also mask the level of frustration and extra work that might result from the current default.

If changing the default would only impact images that contain orientation data with a value other than 1 (0deg), which are therefore currently rendering incorrectly, I'd suggest that's a very sensible change to make.

As a side note, the spec for from-image focuses on the angle value. As half of the 8 EXIF values are for flip, I think it would be beneficial to mention that too, lest it gets overlooked.

[zcorpan]

New use counter data:
whatwg/html#4495 (comment)

[tabatkins]

Agenda+ to discuss this. Elika and I are fine with making the change; the only reason we haven't done so is for compat reasons.

However, Blink's data shows that there are trillions of images for which this would produce no change, and ~200 million (aka roughly .0001%) that would have a behavior change; it's likely that a significant chunk of those would be improved by the behavior change, as they're currently rotated wrongly, but we can't tell how many that would be the case for.

(I know, anecdotally, that I fairly frequently see images posted with wrong rotation on a message board I frequent. These would be fixed automatically by this change.)

In any case, this seems like a very safe change to make, and it appears from author feedback that it would improve the general authoring experience (by making the web match most other image renderers by default).

[fantasai]

Some earlier discussion on this issue: https://lists.w3.org/Archives/Public/www-style/2012Mar/0006.html and https://lists.w3.org/Archives/Public/www-style/2012Feb/0311.html and https://lists.w3.org/Archives/Public/www-style/2012Jan/0573.html

[smfr]

As a data point, WebKit (stupidly) respects EXIF orientation in iOS but not macOS, which has been a continual source of confusion. I'm happy to have this standardized, forcing us to rip off the band-aid and do it everywhere.

[css-meeting-bot]

The CSS Working Group just discussed Consider changing initial value of 'image-orientation' to from-image, and agreed to the following:

• RESOLVED: Accept proposal with an added note current solution is experimental and may change

The full IRC log of that discussion

<dael> Topic: Consider changing initial value of 'image-orientation' to from-image
<dael> github: https://github.com//issues/3799
<dael> TabAtkins: Some time ago when wrote image-orientation we set initial to none. People requested inital to be from-image so it can auto rotate based on what camera captured. Some safari does and some don't. smfr wants apple stuff consistent
<dael> TabAtkins: We did use counter and found numbers reasonable. Lots of images have default xif value.
<dael> TabAtkins: Less then a millionth have orientation data so will be changed. We don't know how many will change for the better and which for the worse. From personal experience I suspect a lot will be fixed. I see a lot incorrect on the web.
<dael> TabAtkins: Given tiny % of poss breakage we recommend init value is from-image
<tantek> wow I'm guessing lots of bad invisible EXIF data that's been neglected to date is going to start screwing up images
<dael> plinss: A little concerning to me. I wrote code that does exif determination. How do you make that work in fallback if browser won't do that.
<tantek> is there a way to query any web image search service for the EXIF properties (or even existence thereof) ?
<dael> TabAtkins: If you have control over image correct is rotate and fix exif or remove the exif and do the transform on browser side. Either works consistently regardless of browser initial value
<dael> dbaron: It seems like it would be good if you make change to spec you should note it's experimental and might change back if there's compat problems.
<dael> TabAtkins: Yep
<dael> smfr: iOS has been this way for many years. I think...there will be compat problems but benefits outweigh. Most common images with exif orientation are those from mobile devices. This benefits those images most which is common.
<dael> plinss: Agree it's desired. Just concerned on compat and make sure websites can manage if they need to.
<dael> smfr: Can with image-orientation css prop
<tantek> +1 to dbaron's suggestion, and what plinss said
<dael> plinss: Yeah, worst case can change behavior
<dael> dbaron: Is iOS detectable by looking at computed value of image orientation?
<dael> smfr: I don't think we support image orientation yet. Just respect exif. Want to both everywhere at the same time. On iOS I don't think it's detectable by web content if image rotated through exif data
<dael> plinss: I don't remember details. I remember a lot of work to make it cross browser. Don't object right now. I'll look at what I did and see if it's problematic and if it is I'll bring it up.
<dael> Rossen_: Sounds like leaning toward accepting proposal with an added note current solution is experimental and may change
<tantek> no objections, but expecting breakage
<dael> RESOLVED: Accept proposal with an added note current solution is experimental and may change

[fantasai]

This was fixed by @tabatkins in bacb9b7#diff-8125531432177df24536a45faa47a870

[zcorpan]

Thanks!

Next steps:

• write wpt tests (see tutorial on how to write a reftest and testharness.js docs. Ask for help if you get stuck. I'm also happy to mentor anyone with writing tests!)
• comment in existing browser bugs, or file new ones, to implement this change
  • chromium
  • webkit
  • gecko
• maybe write something to make web developers aware of this change, and what they should do if their existing workaround breaks

[zcorpan]

Also see #4165

[AmeliaBR]

what they should do if their existing workaround breaks

Specifically, it would be nice if someone could put together a feature-detection test, something that could be submitted to Modernizr or used on its own. The support test (for content images, anyway) could load a minimal 1×2px JPEG data URI with the relevant EXIF tag to rotate it to 2×1, and then read back the dimensions. (Not sure how you'd extend that to detecting support in background images, where there's no way to read back the dimensions.)

[eeeps]

Do we need a note that the orientation metadata must appear before the image data, for it to have an affect?

See:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1627423#c3
• https://bugs.webkit.org/show_bug.cgi?id=210021#c4

[tabatkins]

I opened an issue (#4929) to make it a normative statement instead.