Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
smfr opened this issue Jul 31, 2019 · 22 comments

Comments

@smfr
Copy link
Contributor

@smfr smfr commented Jul 31, 2019

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

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@smfr smfr commented Aug 14, 2019

@css-meeting-bot

This comment has been minimized.

Copy link
Member

@css-meeting-bot css-meeting-bot commented Aug 14, 2019

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

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Aug 16, 2019

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

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Aug 16, 2019

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

@noell

This comment has been minimized.

Copy link

@noell noell commented Aug 19, 2019

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

@smfr

This comment has been minimized.

Copy link
Contributor Author

@smfr smfr commented Aug 19, 2019

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

This comment has been minimized.

Copy link

@duanemoody duanemoody commented Aug 19, 2019

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Aug 20, 2019

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

@antoniosdi

This comment has been minimized.

Copy link

@antoniosdi antoniosdi commented Aug 20, 2019

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.

One case I can submit is the following:
this website where product pictures are uploaded internally by different users.
https://www.fabsurplus.com/sdi_catalog/salesItemDetails.do?id=87930
the pictures are uploaded to the system but currently there is no current possibility for development to rotate images internally, therefore the use of the image-orientation -> from-image in CSS allows with a single css rule - or even by default in the browser if the default value for image-orientation will be from-image - to display all images in the correct aspect.
Currently if you see that web page from Firefox - which currently honors handling the image-orientation -> from image - all the machine pictures will be shown with the correct orientation, while in other browsers that don't honor it , the pictures will be shown with a wrong orientation.
Of course there are thousands of products with thousand of images with this issue.
Please consider using image-orientation -> from-image as a default - or finally determine the image-orientation feature so it can be picked up by all browsers!

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Aug 20, 2019

@antoniosdi from-image as the default was changed in #3799

The question here is if there's a use case to use a different value than from-image

@zoltan-dulac

This comment has been minimized.

Copy link

@zoltan-dulac zoltan-dulac commented Aug 23, 2019

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.

I have a few concerns:

  1. On this Twitter thread (https://twitter.com/AmeliasBrain/status/1164911081266958336), it was suggested that CSS transforms can be used to re-orient images that have been rotated incorrectly without the use of image-orientation. I would argue that this isn't the same thing, since the amount of space the image takes place in the layout would be that of the "untransformed" image (due to how CSS transforms work).
  2. Regarding setting "image-orientation as deprecated and RFC2119 optional" (as per @fantasai's comment above): this is going to cause a bunch of incompatibility issues among browsers if left as is. Furthermore, you are asking people who upload images to content management systems to understand the difference between EXIF and "default" orientations when, in my experience, a lot of image editors/viewers don't agree on how to handle this. I think this can be rather confusing and there should be something that CSS should control.
  3. As mentioned above by @duanemoody , some imagehosts, image caching services and content management systems strip EXIF data for security reasons as well as remove excess data to optimize the image.
  4. I see that the top of this thread says that the "(image-orientation) property is likely going to be deprecated and its functionality moved to HTML". Could I ask what the rationale for that is? I would think that something that affects the visual style of the page should be controlled by CSS, not HTML. I feel like this would set a bad precedent that some visual effects can be controlled by HTML (maybe I am misunderstanding something here?)
@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Aug 23, 2019

Re (4): I think the "moved to HTML" was the idea to introduce an attribute to <img> to opt-in to honoring EXIF. But the CSS WG has now decided to honor EXIF by default for all images, so HTML doesn't need any opt-in. (But CSS may still need an opt-out.)

@fantasai

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Aug 26, 2019

@zoltan-dulac

  1. You are correct that transform is not an adequate substitute for image-orientation: <angle>.
  2. Browsers are planning to align on honoring EXIF orientation, so they will interoperate with photo-editing software and album software that honors EXIF. The goal is for everyone to honor EXIF, including browsers.
  3. I don't see how image-orientation would help services that strip EXIF. If EXIF is stripped, then the image will not be auto-oriented, so the author/service/user needs to rotate the image to be upright. That is true today, it will be true in the future.
  4. Orienting images upright is not a stylistic issue, it's a content issue. If CSS is stripped from the document, the images should be correctly-oriented. Therefore any wrongness in the image orientation should be fixed at a lower layer than CSS.

Assuming honoring EXIF by default is Web-compatible, it is the right way to go. At that point image-orientation is no longer needed to correctly orient images, and it can be dropped. The only reason to keep it would be if the <angle> values were needed for stylistic purposes--correcting misoriented images should be done by fixing the image data, not by using CSS.

@noell

This comment has been minimized.

Copy link

@noell noell commented Aug 27, 2019

Why was image-orientation: <angle> spec-ed that way in the first place? There was a use-case for it, I assume, but I don't know what it was. By dropping the property, we throw that use-case out, no?

@fantasai

This comment has been minimized.

Copy link
Collaborator

@fantasai fantasai commented Oct 1, 2019

@noell It was specced for printers originally, I think. https://www.w3.org/TR/2006/WD-css3-page-20061010/#orienting One of the use cases was to create templates in CSS for printing images from a cell phone.

@edemaine

This comment has been minimized.

Copy link

@edemaine edemaine commented Oct 29, 2019

I'd like to request image-orientation: none which remains quite useful. (The original post asks about the angle variants, but at least one comment suggest removing image-orientation altogether.)

My web platform jumps through hoops to transform images to correctly orient them (with still-correct scale and bounding box) according to their EXIF data, so that I don't need to modify the files themselves.

If a browser were to suddenly respect EXIF data, this would break how things are currently rendered (double rotation). I can remove my workaround code eventually, but not until all browsers respect EXIF data. I'd need image-orientation: none to handle the interim case where some browsers want to respect EXIF data and some don't (to make them act the same: not respecting), or at the very least, some kind of reflection mechanism so that I can tell what type of browser I'm on (EXIF respecting or not).

Regarding angle variants: Services that strip EXIF data from the JPEG might still store that metadata in their database, which would make the angle variant useful for their own rendering. (Though I could also see them leaving just the Orientation EXIF data.) I could also see a human user enjoying the option to manually rotate a deep-embedded EXIF-stripped JPEG via CSS, even if they have to figure out the rotation manually.

@tabatkins

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Oct 29, 2019

Yes, we intend to keep 'auto' and 'none' around, so no worries.

@DemiImp

This comment has been minimized.

Copy link

@DemiImp DemiImp commented Oct 30, 2019

Given that mobile apps are static and that the underlying web renderer can change, it is necessary for us app developers to have an option to ensure that our app will work continue working regardless of what mobile app version the user is using and regardless of what webview version the user has installed. If the default behavior of image rendering is going to change, then we need to account for this asap. Do we need to add an image-orientnation: none to all of the images the user loads into the app today to ensure best compatibility when this change finally arrives?

@zcorpan

This comment has been minimized.

Copy link
Member

@zcorpan zcorpan commented Oct 30, 2019

It depends:

  • Do none of the images have EXIF orientation? The new behavior doesn't affect you.
  • Do some of the images have EXIF orientation and you just show the images as-is? If so, some of those images are probably currently shown with the "wrong" orientation, and the new behavior will fix it. (For img elements, iOS Safari already does this.)
  • Do some of the images have EXIF orientation and you do something to "fix" the orientation on the client side (e.g. CSS transform)? Use image-orientation: none to avoid applying the orientation twice.
@DemiImp

This comment has been minimized.

Copy link

@DemiImp DemiImp commented Oct 31, 2019

We use javascript to read the EXIF orientation and apply it to our images because if we didn't then our app would appear "broken" as everything else actually properly displays their photos.

So is image-orientation officially staying in the spec? Earlier in the thread it was said to leave reasons as to why it should stay.

@tabatkins

This comment has been minimized.

Copy link
Member

@tabatkins tabatkins commented Oct 31, 2019

We use javascript to read the EXIF orientation and apply it to our images because if we didn't then our app would appear "broken" as everything else actually properly displays their photos.

Then yes, start applying image-orientation: none to your images now, to ensure they don't change behavior as browsers update.

So is image-orientation officially staying in the spec? Earlier in the thread it was said to leave reasons as to why it should stay.

Yes, we're keeping it in precisely so people can use the none value, for cases like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.