[css-images] Should the values of image-orientation include the <angle> variants?

[smfr]

In https://drafts.csswg.org/css-images/#the-image-orientation there's a Note that says that

This property is likely going to be deprecated and its functionality moved to HTML. At minimum, it will likely lose all but its initial value and from-image.

Is that still true? Issue #3799 talks about the default value, but not what other values are available.

What are the use cases for with optional flip?

Also, why is 'image-orientation' missing from css-images-4?

[tabatkins]

Is that still true?

Dunno! Need to investigate.

What are the use cases for with optional flip?

It allows for the other 4 EXIF orientations.

Also, why is 'image-orientation' missing from css-images-4?

Images 4 is mostly a delta spec. It's kinda mixed up and messy right now, tho, so the confusion is understandable.

[smfr]

Mozilla shipped then unshipped: https://groups.google.com/forum/#!msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ

[css-meeting-bot]

The CSS Working Group just discussed Should the values of image-orientation include the <angle> variants?, and agreed to the following:

• RESOLVED: Update note saying this is not for implementation and will be dropped

The full IRC log of that discussion

<dael> Topic: Should the values of image-orientation include the <angle> variants?
<dael> github: https://github.com//issues/4164
<dael> smfr: WK is orkging on image-orientation. there's one with angles and one without. ANy other browsers interested in angle variants?
<dael> fantasai: B/c we made from-image default orientation I don't think strong use case for none. If not having web compat problems is this a necessary property? Still need definition b/c css print profile. If defaulting to exif do we nee dproperty at all?
<dbaron> I didn't think the <angle> values were useful...
<dael> TabAtkins: I don't recall affermative use cases for none
<dael> myles: easier to add css to fix a busted image then to rotate
<dael> fantasai: True. Ideally information should be in image or html. If photo is sideways it's data is wrong
<dael> [everyone tlaks]
<emilio> q+
<Rossen_> q?
<dael> fantasai: If you turn off css or in reader mode you want it to be upright. If image is wrong you should fundamentally fix and not patch with css
<emilio> https://groups.google.com/d/msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ
<dael> emilio: Gecko impl the angle values and unshipped when spec deprecated it. I don't think it's a lot of work to re-implement them
<dael> dbaron: I also don't think that useful and a weird use of angles
<dael> myles: Under spec b/c don't say which orientation rotated from
<fantasai> rotated from the orientation before applying EXIF
<dael> TabAtkins: q on myles comment. Use case was something where image pixel are correct and exif is busted? Or more broad?
<svoisen> jensimmons: It's Charlie's last week so, while it would be nice to have additional language for clarity on rendering of wavy lines, it's not something we will get to in the very near term.
<dael> myles: Yes. Comment not about nalge value, but presence of property
<fantasai> svoisen, tell Charlie to make it look good :)
<fantasai> svoisen, since that's basically what the spec is going to try to say ;)
<jensimmons> fantasai: that’s what I said…. just make it purtier
<fantasai> s/fantasai:/fantasai,/
<dael> TabAtkins: With regards to angles unspec implication was rotation from none...says 0deg corrisponds to none. Implies you rotate from that. I don't think underspec, but can be tweaked. Hopefully don't need to be impl. They're there b/c print renderers have them.
<myles> TabAtkins: where does it say that 0 means none?
<myles> i don't see it
<svoisen> fantasai: Ha, fair enough :) We will have to save that as a task for someone else.
<dael> smfr: fantasai suggested removing prop. But if Moz has been shipping with from-image removing is tricky. emilio do you have info on how long shipped?
<Rossen_> ack emilio
<dael> emilio: I don't think we have use counters. Could add. Been shipping for a long time if I recall. I'll find a link
<dael> dbaron: If we're going to try and change default I would suspect that any of the things using it are doing so to set from-image not none
<dael> fantasai: +1
<dael> fantasai: Unless using it to set a value other than from-image there's not a change if we remove property. Already resolved to change initial to from-image so might not need property
<dael> smfr: Possible to get photos with bad exif information. If you pic straight down you get an angle. I can imagine trying to fix that. It does fail with things that strip css
<dael> fantasai: My inclination is impl that support this try and switch to from-image as default. Impl that don't change to from or exif. If that works we try and remove property. If it doesn't we keep
<dbaron> What fantasai just said sounds like a good plan to me.
<dael> plinss: If building photo editing software might want to show image naturally as it is and then manually rotate
<dael> TabAtkins: Editing you're parsing photo into a canvas?
<dael> plinss: Maybe. Could parse exif data yourself, but there is utility to keeping. Agree from-image and none ar only prop with from-image as default
<dael> Rossen_: unshipping of moz behavior and resolve on that behavior
<dael> Rossen_: Which way are we leaning?
<dael> TabAtkins: Fine with dropping if impl are okay on supposition we can make switch to from-image
<dael> plinss: Compat risk when I was writing code for this you don't know if browser will rotate and can't tell. Anyone with code that cares about this is already screwed so wouldn't worry about compat.
<dael> plinss: WOuld be nice if you can tell browser rotated but don't know how to tell in css
<dael> fantasai: Query size of box if it's not square and get aspect ratio. Can tell you a bit
<dael> plinss: But then have to parse image and then you might as well parse exif data
<dael> Rossen_: Leaning toward dropping image-orientation
<dael> fantasai: Prop: update note in draft to indicate we might drop the entire property for browsers and keep a definition with the <angle> values for historical reasons and say it's optional. Then remove. Or information this is in css print by not rec for impl
<dael> Rossen_: Prop: Update note saying this is not for implementation and will be dropped
<dael> Rossen_: Objections?
<dael> RESOLVED: Update note saying this is not for implementation and will be dropped

[fantasai]

Alright, I have

• Marked the entirety of image-orientation as deprecated and RFC2119 optional.
• Updated the note about making from-image the initial value to say that if this change sticks, we'll probably remove the feature (unless there is demand for its other values).

If we end up removing the property, probably what we should do is to revert it to the form referenced from the CSS Print Profile https://www.w3.org/TR/css-print/ and put it in an informative appendix, and very clearly mark it obsolete.

[fantasai]

Or maybe even just remove it entirely and update css-print to point to an appropriate dated copy of css-images-3.

[noell]

If browsers default to img { image-orientation: from-image; } what should developers use to opt-out?

[smfr]

If you have a compelling reason to override an image's built-in orientation, please state it here! The CSS-WG is interested in these cases.

[duanemoody]

For security reasons <https://en.wikipedia.org/wiki/Exif#Privacy_and_security> many imagehosts routinely strip Exif from uploads and don't necessarily rotate the image in the process. Imgur is a popular example. If I've misunderstood the issue please accept my apologies in advance.

[zcorpan]

@smfr

Current browser behavior (except for iOS Safari) is to ignore EXIF orientation (in most cases). The change to the default behavior to respect the EXIF orientation could break web content that is currently working (except maybe in iOS Safari). The image-orientation property gives web developers an easy fix -- specify none to get the old behavior back.

So if we're removing the property, we should have something else to recommend instead. What is it?

I can think of:

1. Fix the EXIF in the image file (requires changing the image file)
2. Change the image data (requires changing the image file)
3. Parse the EXIF in JavaScript and apply it in a canvas like in https://github.com/blueimp/JavaScript-Load-Image

Am I missing some other option? If (1) and (2) are non-options for some people, I wouldn't want to recommend (3). It seems worse than image-orientation in several ways (it has worse performance, uses more memory, doesn't integrate well with native image features like srcset/picture and loading=lazy, it requires JS...)