- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2024 16:28:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images] Should CSS decorative images respect EXIF-orientation by default`. <details><summary>The full IRC log of that discussion</summary> <noamr> ChrisL: it wasn't clear what we've resolved on<br> <noamr> ChrisL: what this means that if you have EXIF that comes before the image data we must respect it<br> <noamr> ChrisL: for consistency we should probably ignore it when it comes after<br> <schenney> q+<br> <noamr> smfr: you mean in the order in which the image is encoded?<br> <noamr> ChrisL: yes, which is not always possible<br> <noamr> q+<br> <astearns> ack schenney<br> <noamr> schenney: I agree with ignoring after the image, but the q was whether the orientation should look at the image-orientation property on the element<br> <noamr> schenney: chrome does this but safari does not<br> <noamr> ChrisL: there wasn't a discussion on this, can we discuss now?<br> <noamr> schenney: one, I implemented this a while ago, the usage data for image-orientation and it's rising, but not in a huge amount<br> <noamr> schenney: people use it to avoid applying the image metadata<br> <smfr> q+<br> <noamr> schenney: from that point of view the current chrome behavior is preferrable for web devs. but the long term is perhaps to not have that property<br> <noamr> schenney: we'll get pushback if we do that<br> <noamr> ... if we don't honor image-orientation<br> <ChrisL> q+ how to say "ignore rotation" in that case?<br> <TabAtkins> scribe+<br> <bramus> scribe+<br> <astearns> ack noamr<br> <TabAtkins> noamr: even now, image-orietnation is broken in the sense that it doesn't work on cross-origin images<br> <schenney> q+<br> <TabAtkins> noamr: which is a real big breakage for people<br> <TabAtkins> noamr: I find it a broken CSS property because of that<br> <ChrisL> +1 to URL modifier<br> <TabAtkins> noamr: having it apply to CSS images, it's a bit weird you have something for the whole lement and apply it to all images. i'd expect it to be a url modifier or something, a keyword that says you read the exif<br> <TabAtkins> noamr: we have url() modifiers now for other things, we can put it there. i think that's the right place<br> <astearns> ack smfr<br> <noamr> scribe+<br> <TabAtkins> (+1 to that, it was clumsy to have it apply that way)<br> <noamr> smfr: it should be per-image, maybe on the image function<br> <noamr> smfr: background: webkit started supporting orientation by default on regular images, we just didn't get to CSS images<br> <noamr> smfr: I think we can change it to match the chromium behavior<br> <astearns> ack how<br> <Zakim> how, you wanted to say "ignore rotation" in that case?<br> <PaulG> q+<br> <noamr> CLilley: URL modifier is perhaps a good way to go<br> <astearns> ack schenney<br> <noamr> schenney: URL modifier would address the original reason why image orientation is ignored on cross-origin<br> <fantasai> I url modifiers should be for generic modifiers. We should use image() for image-specific modifiers.<br> <fantasai> And we should have more of them.<br> <astearns> ack dbaron<br> <noamr> dbaron: I'm more hesitant about modifiers. they make sense for features we want permanently. my impression is that this feature is more fore compatibility during transition<br> <noamr> dbaron: if we want to end up always honoring the metadata, we should only add as many features as we need for that, rather than add more granularity<br> <noamr> astearns: if we resolve on ignoring EXIF at the end, does that help with the transition?<br> <noamr> dbaron: it wasn't clear to me which cases the resolution applies to<br> <astearns> ack PaulG<br> <noamr> PaulG: for a11y I'd be concerned that if people relied on this feature for WCAG orientation, I wouldn't want to get rid of it<br> <noamr> PaulG: I suspect we'd want to keep that<br> <astearns> ack fantasai<br> <noamr> fantasai: modifiers should be in image() and not in url()<br> <noamr> q+<br> <astearns> ack noamr<br> <TabAtkins> Yeah since this is explicitly an image *file*, I'm fine with it living on url()<br> <ChrisL> q+<br> <noamr> astearns: we can probably resolve on ignoring metadata that's after the metadata<br> <noamr> schenney: I thought it was resolved a while ago<br> <astearns> ack ChrisL<br> <noamr> ChrisL: it was unclear enough that it's hard to say what a PASS is<br> <smfr> q+<br> <noamr> q+<br> <astearns> ack smfr<br> <noamr> smfr: we might not be able to do this in the implementation<br> <astearns> ack noamr<br> <astearns> ack fantasai<br> <noamr> fantasai: HTML should add that, but in CSS we should say how we handle images with EXIF, regardless of the host language<br> <smfr> q+<br> <noamr> it should at least be in both<br> <fantasai> s/should add that/could add special rules/<br> <astearns> ack smfr<br> <noamr> smfr: odd that CSS would define things around the encoding of an image<br> <noamr> q+<br> <fantasai> It doesn't need to be in both. It's a rendering question, it needs to be in CSS. HTML can optionally say stuff, but it doesn't need to -- we do.<br> <dbaron> s/HTML should add that/HTML could add that/<br> <TabAtkins> noamr: We talked before in WHATWG about separqting some of those image details to as eaprate spec<br> <TabAtkins> noamr: it never happened because nobody had time, but I think right now, relying on parts of HTML that defines how images are decoded, relying on that inside of CSs, is the best we'<br> <ChrisL> relevant PNG WG issue is https://github.com/w3c/png/issues/310<br> <TabAtkins> noamr: We should behave the same way for HTML and CSS<br> <noamr> astearns: it is claimed that all browsers ignore post-image-data orientation<br> <noamr> astearns: smfr would you validate?<br> <noamr> smfr: will validate<br> <noamr> astearns: will take it back to the issue about encoding order<br> <noamr> ... to validate that all browsers do this today<br> <noamr> ChrisL: please check with JPEG with PNG, I saw that Safari does something different<br> <noamr> smfr: that's why we need more time<br> <noamr> (In PNG this is encoded in XMP IIRC)<br> <noamr> astearns: for how we override the metadata<br> <ChrisL> No, it can be but there is also an exif chunk<br> <noamr> smfr: this is *this* issue, but we discussed a different one<br> <TabAtkins> noamr: also there's a proposal for a url() modifier. not clear yet. But at least not taking the info from image-orientation<br> <TabAtkins> schenney: so proposal is phase out a per-image way of specifying it, and phase-out image-orientation property<br> <TabAtkins> phase in an image-specific way to do *CSS images*.<br> <TabAtkins> dbaron: replaced elements, form HTML, would still obey image-orientation<br> <TabAtkins> astearns: so let's continue that part of the discussion in this issue<br> <noamr> astearns: action item for smfr to validate the tests<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4165#issuecomment-2447730599 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 October 2024 16:28:14 UTC