cc'ing Tab so that he's aware of this and can drop image-orientation once I've added it, assuming that's workable.

I presume this will be a boolean attribute; if present, honour orientation, else do the same as now.

Any suggestions for a good name? honor-exif-orientation="" is a bit long.

You don't want EXIF in the name; while that's the metadata scheme used by most image formats, there's nothing special about it that would make this attribute work any differently if we used some other metadata scheme.

Call it "autoorient"?

(Dropping image-orientation in favor of an HTML attribute is already planned: http://dev.w3.org/csswg/css-images/#the-image-orientation)

(In reply to Tab Atkins Jr. from comment #2)
> Call it "autoorient"?

That double “oo” is awkward.

How about autorotate?

autorotate="" is pretty nice.

Yeah, sounds good to me.

(File a new bug about the Index when fixing this)

From my perspective, Tab's proposal at the bottom of this message is the right approach:

http://lists.w3.org/Archives/Public/www-style/2014Apr/0186.html

We really want some support in CSS for document authors to opt in to displaying images with the correct EXIF orientation. (And most sites would surely choose to do this once the feature is widely implemented.) If backwards compatibility were not a concern, the 'from-image' behavior would surely be the default today, given the proliferation of smartphone pictures with embedded EXIF orientation data. Safari Mobile even honors EXIF orientation by default!

(To be clear, I'm just saying that we should retain some form of 'image-orientation' in CSS. I support adding the HTML attribute.)

https://twitter.com/brucel/status/479883882725404672

[[
TIL (thx @zcorpan) that <img autorotate> won't make images spin constantly, but honours orientation data in EXIF 
]]

rotatebymetadata is possibly a better name? (ack @shwetank)

Since we're bikeshedding... I think autorotate="" is better than rotatebymetadata="". In particular, I think the more words you have in an an attribute name, the harder they are to read. "Rotate byme tada ta? Or is it rotate by me tadata?"

(In reply to Ian 'Hixie' Hickson from comment #10)
> Since we're bikeshedding... I think autorotate="" is better than
> rotatebymetadata="". In particular, I think the more words you have in an an
> attribute name, the harder they are to read. "Rotate byme tada ta? Or is it
> rotate by me tadata?"

autorotate is definitely better, even with the possibility of it being interpreted as "constantly rotate". ^_^

"rotate by me, tada! Ta!"

It appears that desktop Safari, Chrome/Opera and Firefox honor EXIF when the image is shown in the top-level page, but not in <img>.

https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/Landscape_6.jpg
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3109

Mobile Safari honors EXIF also in <img>. Other mobile browsers don't.

http://www.browserstack.com/screenshots/5864b36445508e27c01ccb333d17b979c27cdfb7

Are browsers willing to switch to the mobile Safari behavior without opt-in?

Is Apple willing to ignore EXIF for <img> in mobile Safari when there's no opt-in?

(In reply to Simon Pieters from comment #12)
> It appears that desktop Safari, Chrome/Opera and Firefox honor EXIF when the
> image is shown in the top-level page, but not in <img>.
> 
> https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/
> Landscape_6.jpg
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3109

Also note here that I believe this is specifically the *top-level* page, i.e., it doesn't happen with <iframe src="[...].jpg"></iframe>.

> Mobile Safari honors EXIF also in <img>. Other mobile browsers don't.
> 
> http://www.browserstack.com/screenshots/
> 5864b36445508e27c01ccb333d17b979c27cdfb7
> 
> Are browsers willing to switch to the mobile Safari behavior without opt-in?

I think Mozilla folks would prefer not to; see the discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=298619

Summarising the Mozilla and WebKit bug discussion:

* iOS and Android devices use EXIF when taking a picture and email to someone.
* Cameras usually use EXIF.
* Some image editing tools rotate the image by changing the pixels and either remove EXIF, leave it as is, or add a duplicate entry saying "no rotation". https://bugs.webkit.org/show_bug.cgi?id=19688#c64 says Windows Photo Viewer can produce duplicates.
* WebKit/Blink/Gecko (also Geeqie, Nautilus, Eye of GNOME, Thunar) use the last EXIF value when there are duplicates. (I get confused by https://bugzilla.mozilla.org/show_bug.cgi?id=298619#37 -- is it first or last?)
* Windows 7 Photo Viewer, OpenOffice "Insert Picture" and Microsoft Paint ignore EXIF.
* There has been no research yet as to whether always honoring EXIF is a net win or a net loss. Eric Seidel says in https://bugs.webkit.org/show_bug.cgi?id=19688#c61 he thinks it's a net win.

https://bugzilla.mozilla.org/show_bug.cgi?id=298619#c27 suggests things to research. roc thinks supporting EXIF is a bad idea but is an option if research supports it. (https://bugzilla.mozilla.org/show_bug.cgi?id=298619#33 https://bugzilla.mozilla.org/show_bug.cgi?id=298619#34 )

(In reply to Simon Pieters from comment #14)
> * Some image editing tools rotate the image by changing the pixels and
> either remove EXIF, leave it as is, or add a duplicate entry saying "no
> rotation". https://bugs.webkit.org/show_bug.cgi?id=19688#c64 says Windows
> Photo Viewer can produce duplicates.

It's not clear to what extent this it true. It might just be a misunderstanding of what the tag applies to (the primary image or the thumbnail).

https://bugs.webkit.org/show_bug.cgi?id=19688#c124
https://bugzilla.mozilla.org/show_bug.cgi?id=298619#c116

(In reply to Simon Pieters from comment #14)
> * There has been no research yet as to whether always honoring EXIF is a net
> win or a net loss. Eric Seidel says in
> https://bugs.webkit.org/show_bug.cgi?id=19688#c61 he thinks it's a net win.

I've tried to research this a bit.

I've collected the following:

A) total number of sites.
B) total number of <img>s.
C) total number of images with IFD0:Orientation tag that is not Horizontal.
D) total number of images with IFD0:Orientation tag that is not Horizontal where the <img> had width and height attributes.
E) total number of images with duplicate IFD0:Orientation tags where not all are Horizontal.

(I have not collected "total number of images that are taller than wide (ignoring EXIF) and have orientation EXIF".)

(I also didn't collect the number of images that failed to download or decode etc.)

The data set is http://webdevdata.org/ data set 2013-09-01 102,000 pages.

Method:

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -Eio "<img\s[^>]+>" >> ../img.txt
$ cd ..
$ python fetch-img.py # https://gist.github.com/zcorpan/1848552ed84bc3db4935

Results:

A) 2592
B) 43908
C) 0
D) 0
E) 0

No rotated images at all. Not very surprising though, given that the data set is font pages of high-profile sites.

Let's look at a different data set: images on lists.w3.org.

Method:

https://www.google.com/search?q=site:lists.w3.org&tbm=isch
load all results
copy resulting DOM from devtools
filter out imgurl=([^&]+)
run similar script as above

Results:

A) 1
B) 779
C) 3
D) 0
E) 0

The images were:

http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0011/dsc03579.jpg
http://lists.w3.org/Archives/Public/www-archive/2013Oct/att-0018/PepysFootnotes.jpeg
http://lists.w3.org/Archives/Public/www-archive/2013Feb/att-0010/dsc07902-Whiteboard.jpg

relevant HTML pages containing those in <img>:

http://lists.w3.org/Archives/Public/www-archive/2012Feb/0011.html
http://lists.w3.org/Archives/Public/www-archive/2013Oct/0018.html
http://lists.w3.org/Archives/Public/www-archive/2013Feb/0010.html

These three would get the correct orientation if Exif was honored in <img> without opt-in, and no other images in the data set would regress.

I'm happy to look at other data sets if the above is not convincing enough. So far, the data supports Eric Seidel's belief that honoring Exif without opt-in is a net win.

What do people think?

(In reply to L. David Baron (Mozilla) from comment #13)
> Also note here that I believe this is specifically the *top-level* page,
> i.e., it doesn't happen with <iframe src="[...].jpg"></iframe>.

That is true for Firefox but not for Safari, Chrome and Opera. (IE11 appears to ignore Exif both in iframe and top-level.)

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3137

We're (IE) interested in honoring orientation for top-level and iframes though.  Just hasn't happened yet.

For other topics on the thread...

I'd prefer to only have this in HTML or CSS, but not both.  HTML sounds fine to me.

My instinct is that rotating based on metadata by default would cause more layout breakage on long-tail and older sites.  The data below is encouraging, though I'm curious if 0 is the right number given the number of users who upload EXIF-oriented images to various sites.  It's likely that many top sites do fixup server-side but I'd still expect some images to make it through.

For naming, I like autorotate, assuming that this is Boolean as Ian mentioned.  If it needs more options then I like the image-orientation syntax.

Thanks Matt.

Yep, I think 0 is right. (First the script collected any image that had the IFD0:Orientation tag, and there were a number that did but had the value Horizontal (normal) which is the default.)

I guess it is possible to add a UseCounter in Blink or telemetry for Firefox to get more useful data, but it would take some more weeks to get it (plus impl+review time for adding the counter).

Doesn't CSS also need a way to opt-in for things like background images if we don't rotate by default?

The rotation of background-images in CSS is covered by the image() function in Images L4 I believe:

"If the image has an orientation specified in its metadata, such as EXIF, the UA must rotate or flip the image to correctly orient it as the metadata specifies."

http://dev.w3.org/csswg/css-images/#image-notation

Is anyone interested in implementing images rotated without opt-in and seeing what breaks? I think it could very well be compatible enough (iOS Safari already does it; the research so far only found pages that would be fixed by doing it) and it seems better on the long term, IMHO.

I think it would be worth trying.  Does iOS Safari do it for all images (img, object, background-image, list-style-image, content, toplevel document, iframe, svg:image, etc.?) or just some of them?

In iOS Simulator of Xcode6-Beta5, I see:

img, iframe, top-level document:
rotated

input, object, background-image, content, list-style-image, svg:image, video poster, embed:
not rotated

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3226

Yes, img, iframe, top-level (Image) document only. <iframe> documents satisfy the isImageDocument() test when the <iframe> source is an image URL [1] 

[1] http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderObject.cpp?rev=181654#L1771


What happens on iS Safari when the <img> is in a layer, via CSS translateZ(0) for example.

Also see https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/thread.html#msg14

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).

I've added stats to chrome to record image orientation.  The stats for win  dev-channel chrome on Dec 25th 2015 (Christmas Day): not a busy day, but an interesting distribution.

Top Left	X Billion   100.00%
Top Right	36	00.00%
Bottom Right	2,474	00.00%
Bottom Left	4	00.00%
Left Top	2	00.00%
Right Top	23,518	00.00%
Right Bottom	3	00.00%
Left Bottom	9,902	00.00%

(In reply to Simon Pieters from comment #26)
> 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).

This sounds fine to me.

Thank you for the data Noel! It seems difficult to say if rotating by default would fix or regress more, though. But good to know it would at most regress 0.00% of images. :-)

Is there still interest in changing the default, or should I implement comment 26 in the spec?

I strongly vote for default behavior.
Adding this property will make a confusion and inconsistency where it is not needed.
For example we wouldn't want to add a property called "buggy-behavior:false" now would we :)
There is no use for displaying images up-side down or mirrored.

Regarding Noel's statistics - at the moment most websites that encounter this bug added processing of uploaded images to remove the orientation before displaying them image back to the user.
This is another incentive to avoid adding 'autorotate' or 'image-orientation'.
It would be interesting to see statistics for EXIF of uploaded images vs displayed images.

My understanding is that this work is currently being pursued in the CSSWG as `image-orientation: from-image`. https://drafts.csswg.org/css-images-3/#propdef-image-orientation

https://github.com/whatwg/html/issues/4495