- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 Jul 2020 23:23:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images-3] clarify which images image-orientation applies to`, and agreed to the following: * `RESOLVED: Make from-image's none value apply to background and any other images` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-images-3] clarify which images image-orientation applies to<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5245<br> <dael> heycam: We have image orientation property that allows us turn off auto-re-orientation.<br> <dael> heycam: Some discussion about widening to all images a few months ago. Resolution from there was orientation meta data should be honored for decorative images. Makes sense.<br> <dael> heycam: Wasn't discussed if properties should be extended. As MIke noticed we have contradictory WPTs. Should image-orientation apply to decorative images?<br> <dino> q+<br> <dael> heycam: My feeling is it should b/c real purpose of property is let authors opt-out and it doesn't make sense to limit that to a subset of images<br> <Rossen_> ack dino<br> <dael> dino: Question is what would you do if want decorative to do one thing and non-decorative do another<br> <dael> heycam: You would need to introduce some other way of override orientation, maybe with image value syntax, or correct images<br> <dael> dino: Sort of leading question. In many cases will have to fix image or change content. Is it worth having this apply everywhere? I don't know<br> <dael> heycam: From experience of bug reports they were all content images. jpegs with image data rotated but tool didn't update meta data so new image-orientation made them wrong. Didn't get cases on decorative<br> <dael> fantasai: We had this discussion before and I believe resolution was only to apply to content. Idea was if we needed to apply to other we would introduce image notation syntax. This discussion was before auto xif but that was original discussion and conclusion<br> <dael> Rossen_: Is that 4165?<br> <dael> fantasai: older<br> <dael> fantasai: Let me change DoC<br> <smfr> s/change/see if it’s in the/<br> <dael> s/xif/EXIF<br> <fantasai> https://lists.w3.org/Archives/Public/www-style/2012Mar/0412.html<br> <dael> Rossen_: Where does this leave the current issue?<br> <dael> fantasai: Here's the issue. #50 in DoC. Conclusion was repalced elemtns and generated content but not background image<br> <dael> fantasai: Or any other images in CSS<br> <dael> fantasai: Images which are considered part of content are effected but no other<br> <dael> faceless2_: If purpose is undo exif makes sense to apply, but it's not weird to not. As long as it's documented.<br> <fantasai> "It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as background-image)."<br> <dael> fantasai: Spec says applies to content not decorative.<br> <fantasai> https://drafts.csswg.org/css-images-3/#the-image-orientation<br> <dael> fantasai: Anything that's a replaced element in css model it applies to that. Everything else is not effected.<br> <chrishtr> q+<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to discuss history<br> <dael> heycam: Seems like notion of this property has changed over time. Original I want to set an orientation on an image. Now proprty is forI I have a problem caused by change in browsers and this gets me the old way back so I don't have to fix images I'm serving. In that PoV makes sense to apply as broadly as possible. Let's author set one property which goes to all images<br> <fantasai> This was issue 50 in the 2012 LC Disposition of Comments https://drafts.csswg.org/css-images-3/issues-lc-2012<br> <dael> chrishtr: I agree with heycam reasoning and that's what Chrome impl. There were cases where it was useful behavior for site compat<br> <smfr> webkit agrees with cameron too<br> <dael> fantasai: If we make this change it should only affect none value and others shouldn't apply to decorative<br> <Rossen_> ack chrishtr<br> <dael> heycam: I think we have resolution to remove other values.<br> <dael> fantasai: It's deprecated but has been impl and shipped in multiple impl, jsut nto browsers. We can remove from next spec level, but there needs to be a spec with those.<br> <dael> chrishtr: Who impl?<br> <dael> fantasai: Some printer based technology sihpped with onboard layout in printer chipset.<br> <dael> chrishtr: Okay so we say rotate ones won't apply to style images<br> <dael> fantasai: And support for that is marked as optional so browsers don't need to impl. But there needs to be spec for it<br> <dael> Rossen_: Any changes to L3 images?<br> <dael> fantasai: Yes if we want to make from-image and none value apply to background and other images we need to change spec to say it's all images associated with element<br> <dael> Rossen_: Is this going to be still valid for printer or are they okay b/c L2?<br> <dael> fantasai: They don't impl from-image I believe<br> <dael> Rossen_: Sorry, confused by statement that there were impl<br> <dael> fantasai: If we make change for other values than yes. THat's why I'm saying it shouldn't apply to the other values<br> <dael> Rossen_: Would that solution work for everybody<br> <dael> heycam: sgtm<br> <dael> Rossen_: Prop: Make from-image and none value apply to background and any other images?<br> <dael> fantasai: angle only applies to content<br> <dael> Rossen_: none value on from-image<br> <dael> Rossen_: Additional comments?<br> <dael> smfr: Can we resolve on cursor behavior and linked meta that are in GH issue?<br> <dael> Rossen_: Would this be the exception on cursor?<br> <dael> smfr: Makes sense for cursor to have same. Link and meta I don't know since usually don't apply CSS to them<br> <dael> fantasai: Not sure what a link or meta element would do<br> <dael> heycam: Some cases about favicons and similar images<br> <dael> smfr: First comment in issues has list of interesting items like embed object. We need to be explicit which of these we include<br> <dael> chrishtr: Canvas is an imparative API<br> <dael> smfr: Not sure abotu canvas I think right is API to expose exif to JS or extend draw image API<br> <tantek> presumably you can put images on link or meta via background-image or ::before and content property etc.<br> <dael> fantasai: Rest it should apply, every image associated to the element is effected as far as CSS is concerned. If it's a replaced element it's applied. Decorative elements would include background iamge and cursor<br> <dael> smfr: Source graphic in SVG<br> <dael> fantasai: Replaced element, isn't it?<br> <dael> smfr: I think it's paint source or whatveer it's called<br> <dael> heycam: I think that's rendered content of some subelement on dom tree<br> <dael> fantasai: Do you do image orientation of source, using, or neither element<br> <dael> heycam: Similar to canvas-draw-image b/c can reference another image element. Have minor incompat on where to look already. I think those cases can be handled in specs that define what it's referencing<br> <dael> smfr: Agree. We can resolve on what we discussed and say SVG may need refining<br> <dael> heycam: I'm happy to make cursor effected<br> <dael> Rossen_: Should we try to resolve on this and heycam or someone can open an issue on SVG to makes sure there's no additional items to associate to this decision?<br> <dael> smfr: sgtm<br> <smfr> s/smfr/heycam/<br> <dael> Rossen_: Still previous resolution. Objections?<br> <dael> RESOLVED: Make from-image's none value apply to background and any other images<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5245#issuecomment-652692583 using your GitHub account
Received on Wednesday, 1 July 2020 23:23:15 UTC