- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Mar 2022 00:36:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images-4] Proposal to allow replaced elements to paint outside of their bounds`, and agreed to the following: * `RESOLVED: We add to Images 5 these 2 properties, object-viewbox and object-overflow. 1 is bool about hidden and visible and the other is eq. of SVG viewbox. We would try and create a mapping between svg and new property. New property would take inset and xywh so there's 2 ways to spec size` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-images-4] Proposal to allow replaced elements to paint outside of their bounds<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/7058<br> <fantasai> s/current behavior/current syntax<br> <dael> TabAtkins: While discussing the shared element transitions proposal a couple weeks ago there was some obvious need to control how the image snashot sized better<br> <dael> TabAtkins: The image snapshot can be size to elements but larger to capture outlines or shadows. Awk interaction with normal image sizing. When looking at Jake prop I realized this would be useful in general and addresses a gap in Paint API<br> <dael> TabAtkins: General is add 2 prop to object family; object-viewbox and object-overflow. Apply a iewbox to replaced content and allow it to overflow context box<br> <dael> TabAtkins: Viewbox is same grammer as svg and has same effect. Let's you say x/y boundary is the image boundary.<br> <dael> TabAtkins: [gives example]<br> <dael> TabAtkins: The natural size of image adjusts to spec width and height. For sizing it assumes the elemnt transition snapshot is the size of element border box. If part outside is displayed somehow due to something like object-overflow you can see the rest like the shadows<br> <dael> TabAtkins: Generalizing the use case, one of the use cases we wanted to handle in Houdini is doing custom shadows. Groups like google material design did optics based shadowing. b/c couldn't paint outside hte bounds you had to do weird tricks to do it<br> <dael> TabAtkins: This would allow you to do that exact thing as well when paired with object-overflow. 2 properties, hidden and visible. hidden is like today<br> <dael> TabAtkins: With these 2 properties would help a lot with shared element transitions but useful general property<br> <dael> TabAtkins: fantasai provided feedback might be good to have it just be viewport and we upgrade the svg to a property and do that.<br> <Rossen_> q?<br> <smfr> q+<br> <dael> TabAtkins: I'm fine with that if people believe it's a good way to go<br> <dael> TabAtkins: Last I checked no other feedback. Any quesitons or concerns I'd love to hear it.<br> <dael> TabAtkins: Else could add to images<br> <Rossen_> ack smfr<br> <dael> smfr: Sounds reasonable. Not a huge fan of new ways to do ink overflow, but I see the use case<br> <dael> smfr: If you do object overflow and then object-fit:cover you'll have bits outside that don't respond to hit testing. Might enocourage people to make weird content for hit testing<br> <plinss> q+<br> <dael> TabAtkins: That is true. I don't know how to address it, though. It's part of core functionality since shadows shouldn't hit, but you could also do cover. Not sure if we can slve that or put a note saying don't do<br> <dael> smfr: Note is prob fine<br> <dael> smfr: Other thought is how it interacts with a-r<br> <Rossen_> q?<br> <dael> TabAtkins: Should be straightfoward. Changes element natural size to spec width and height and that implies a-r. I'm not sure if we allow width and height w/o a-r. Should have same effect. 2:1 and set square viewbox it's 1:1 for all other purposes<br> <dael> smfr: Alright<br> <Rossen_> ack plinss<br> <dael> plinss: I thought I heard there would be viewbox property that takes same as svg viewbox?<br> <dholbert> q+<br> <dael> plinss: Little concerned b/c svg will look a bit like standard rect and it's not. Might be confusing. Maybe have it be a shape function?<br> <dael> TabAtkins: Would that imply we want to allow other shape or is this just special for the property?<br> <dael> plinss: Restrict to small set of shapes. rect and inset might make sense.<br> <dael> plinss: Just confusing about a bare property that takes 4 values but it's not the same<br> <fantasai> +1 to plinss's suggestion of both rect() and inset()<br> <dael> TabAtkins: I get you. And having rect and inset would be pretty worthwhile. If you use viewbox you have to get width and height but inset lets you set 20px. I think that sounds pretty good<br> <dael> plinss: I'm not opposed to having another one to take svg syntax for people who know it but we should call out<br> <dael> TabAtkins: Doesn't rest take svg?<br> <dael> plinss: I think it's trbl<br> <dholbert> s/rest/rect/<br> <dael> s/rest/rect<br> <dael> plinss: I don't want to rat hole, but calling out<br> <dael> TabAtkins: We don't have rect, we have inset. So add a rec or some other name that takes xy stuff<br> <fantasai> xywh<br> <vmpstr> q+<br> <dael> plinss: There is rect on clip unfortunately<br> <fantasai> xywh()<br> <dael> TabAtkins: Okay<br> <Rossen_> ack dholbert<br> <dael> dholbert: One other concern with svg viewbox is it's a list of 4 numbers and doesn't allow units or %. Might make it we'd have to extend a fair bit. Might be worth abandoning it for that purpose<br> <dael> TabAtkins: I would have presumed we upgrade to css units. But point taken<br> <Rossen_> ack vmpstr<br> <dael> vmpstr: I wanted to confirm how scaling works. If we scale images such that we squish. Squish the viewbox and overflow squishes<br> <dael> TabAtkins: Right. If you scale image of svg element using viewbox the whole thing squishes including the outside<br> <dael> fantasai: For rect function media uses xywh. Makes it clear what each argument would be.<br> <dael> fantasai: For svg correspondence we've tried to create mappings. We should look more b/c if we can make them map it solves viewbox which has not had a mapping<br> <dael> TabAtkins: I don't think there is a big problem...speaking from ignorance but suspect not a big problem with making this property override viewbox of inline svg. Probably okay.<br> <dael> TabAtkins: Should put in as an issue without effecting rest of design<br> <dael> fantasai: If you put it in from an embedded svg it should have same effect<br> <dael> TabAtkins: not sure about that. That would mean that applying the style to an image element could have distinct effects based ono source type<br> <dael> fantasai: True for width and height. If you apply sizing to root svg for embedded vs inline get different<br> <dael> TabAtkins: Talking embedded svg vs png<br> <dael> fantasai: No, if you have it inside the svg file<br> <Rossen_> q?<br> <Rossen_> ack fantasai<br> <dael> TabAtkins: Yes, yes. If it applies to svg and html it would apply to raw svg as well<br> <TabAtkins> s/svg and html/svg-in-html/<br> <dael> fantasai: Sounds like prop is we have these 2 properties, object-viewbox and object-overflow. 1 is bool about hidden and visible and the other is eq. of SVG viewbox. We would try and create a mapping between svg and new property. New property would take inset and xywh so there's 2 ways to spec size<br> <dael> fantasai: And that's in images 5<br> <dael> TabAtkins: Correct<br> <dael> Rossen_: Other opinions?<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: We add to Images 5 these 2 properties, object-viewbox and object-overflow. 1 is bool about hidden and visible and the other is eq. of SVG viewbox. We would try and create a mapping between svg and new property. New property would take inset and xywh so there's 2 ways to spec size<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7058#issuecomment-1057543300 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 March 2022 00:36:27 UTC