Closed smfr closed 3 years ago
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.
Mozilla shipped then unshipped: https://groups.google.com/forum/#!msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ
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
Alright, I have
image-orientation
as deprecated and RFC2119 optional.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.
Or maybe even just remove it entirely and update css-print to point to an appropriate dated copy of css-images-3.
If browsers default to img { image-orientation: from-image; } what should developers use to opt-out?
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.
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.
@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:
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...)
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!
@antoniosdi from-image
as the default was changed in https://github.com/w3c/csswg-drafts/issues/3799
The question here is if there's a use case to use a different value than from-image
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:
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).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.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.)
@zoltan-dulac
transform
is not an adequate substitute for image-orientation: <angle>
.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.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.
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?
@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.
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.
Yes, we intend to keep 'auto' and 'none' around, so no worries.
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?
It depends:
img
elements, iOS Safari already does this.)image-orientation: none
to avoid applying the orientation twice.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.
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.
If we're keeping the property and browsers are planning to ship, shouldn't we update the spec to remove the wording about the property being deprecated?
^^^ agree, and update with correct wording, since that Blink plan mentions shipping "from-image" as a property value, in addition to "none". Not sure if the CSSWG wants "from-image" shipped ...
@mrego Deprecated doesn't mean "do not implement", it means "do not use (as an author)".
@noell CSSWG definitely wants from-image
shipped: we even changed it to be the initial value. The intention is to shift browsers to using from-image
behavior by default. If there's no Web-compat or intentional use case for other values than from-image
, then we might drop the property, because there would no need for control over it. See minutes
Thanks @fantasai for your clarification, I got confused by browsers shipping a deprecated thing but I understand it's fine to do it.
Regarding the syntax it seems it was agreed to keep it for historical reasons, so maybe no more work is needed here. Should we just close the issue then?
Ditto @fantasai thanks for clarifying -- we (chrome) will ship from-image
(initial) and none
values only.
@smfr I have no compelling use-case for overriding an image's orientation at this time, so perhaps no need for the <angle>
and <flip>
variants.
/edit: also think we can close this issue.
The only use case I can think of for overriding the value in the image is when it is wrong. That tends to happen when, for example, a phone camera is used to take a top-down shot, so it is nearly horizontal and small differences in position cause the orientation to randomly go from portrait to landscape.
If there's agreement on what should happen, can we get someone to take responsibility for updating the spec? It gets confusing when dev advocates are trying to talk up the new property if the spec doesn't match the agreed shipping behavior… https://twitter.com/argyleink/status/1214623240250744832 cc @argyleink
Yes, I think it's worth removing the angle values from the spec, despite the wording about the property maybe going away in the future.
Made some clarifications to the way this property's deprecation / optionality is described. Agenda+ to confirm with the WG.
Agree that we should remove the angle values from the spec.
The CSS Working Group just discussed Should the values of image-orientation include the <angle> variants?
, and agreed to the following:
RESOLVED: accept fantasai edits
Use-case: extract a BMP format thumbnail image from a RAW camera image. The RAW image has an EXIF orientation value, but BMP format does not support orientation. The |angle| and |flip| could be used to draw the BMP in correct orientation.
I think I’ve got a use-case for image-orientation: <angle>
.
Imagine an image that shows a map with text written at different angles (see my screenshot below). A website that includes such an image may want allow its visitors to rotate the image by 90 degrees (put it on its side) to make it easier to read all of the image’s text without having to lean one’s head too much to the side.
Ideally, the browser would just provide controls for rotating images in the context menu. But since browsers don’t let users rotate images easily, the website has to provide this option.
How can the website do that? I’d like to produce the result shown in my screenshot below. I’m not sure that CSS Transforms can do it. If I set rotate: -90deg
and adjust the transform-origin
, the image becomes too wide for the viewport, and there is whitespace below the image. It may be possible, but it’s not straightforward.
In https://drafts.csswg.org/css-images/#the-image-orientation there's a Note that says that
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?