<img>: Have an autorotate="" attribute that honours orientation metadata in the image (e.g. EXIF)

[zcorpan]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508#c26

It seems like there is not enough interest in trying to rotate all images by default. It's also not clear to me that it's a good idea to drop the CSS property, since one might want to rotate e.g. 'content: url(image)' images etc.

I suggest we do this:

• Keep the CSS property.
• Add autorotate to <img>
• Add img[autorotate] { image-orientation: from-image; } to Rendering.
• Clarify that image-orientation affects naturalWidth, drawImage(), etc.
• Require that https://html.spec.whatwg.org/multipage/browsers.html#read-media has an autorotate attribute set on the <img> (for top-level images and images in <iframe>s).

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.

cc @dbaron

[eeeps]

Anecdotally, over the years, I've encountered multiple novice users publishing to platforms like email newsletters who are very confused as to why their images rotate as soon as they enter a web view.

e.g. https://stackoverflow.com/questions/35011966/why-my-image-is-rotate

From the (great!) answer there, it sounds like most default OS viewers respect Orientation. How many point-zero-zeroes do we need on that percentage-of-affected-images to change the initial value to from-image?

[zcorpan]

I filed an issue for the CSSWG since it affects the css-images spec.
w3c/csswg-drafts#3799

[emilio]

Clarify that image-orientation affects naturalWidth, drawImage(), etc.

I don't think that's great. That means that naturalWidth and such need to update layout, which is a common perf footgun that in this case is easy to avoid. Would it be better to have a naturalOrientation on the image or such?

[zcorpan]

Why would it need to update layout?

[zcorpan]

Oh I see. It needs the latest styles in case image-orientation has changed.

[emilio]

Right.

[zcorpan]

Ok. So to be a bit more consistent, there could be orientation that takes CSS into account, and naturalOrientation that reflects just the EXIF Orientation.

[emilio]

I think it's not too hard to just use getComputedStyle() instead of exposing a new attribute, but...

[annevk]

Can we perhaps split the various issues here? I'm counting a lot of them and it's not entirely clear to me where each is at:

1. By default, do images ignore their intrinsic orientation or not? (Status quo is yes, but OP suggests changing that, right?)
2. Should we expose the intrinsic orientation to script?
3. Should we expose the used orientation to script?
4. Should the CSS-declared orientation impact anything beyond the rendering of the img element?
5. Should the intrinsic orientation impact anything beyond the rendering of the img element?
6. Should canvas APIs accept orientation as an input in some manner?
7. Should the img element get an attribute to override the intrinsic/CSS/used orientation or some such?

[noell]

Yeah ^^^^ good questions

https://bugs.chromium.org/p/chromium/issues/detail?id=158753#c56

[zcorpan]

@noell your recommendation in that comment includes

Change the initial value to be "from-image"

I agree. That is issue w3c/csswg-drafts#3799

Because we're defaulting to rotation

• there's no need for an autorotate attribute on HTML <img>.

Also agree.