- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Feb 2026 17:25:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images] Behaviour of SVG degenerate aspect-ratios`, and agreed to the following: * `RESOLVED: Spec reality here` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> iank_: the resolution wasn't talking about the natural sizes, which is the important bit here<br> <SebastianZ> So with that I'm off. Bye!<br> <SebastianZ> present-<br> <TabAtkins> iank_: it was just talking about widths and heights<br> <TabAtkins> iank_: which happens later on, potentially<br> <TabAtkins> iank_: so, how this all works is we get some natural sizes, doens't matter where from. we might have 1 natural size, 2, or all 3. some of them might be zero.<br> <TabAtkins> iank_: then we normalize the natural sizes to respect the aspect ratio<br> <TabAtkins> iank_: so if ratio is 1:1 and sizes are 100 and 200, we previously resolved that we coerce the block dimension to make it 100<br> <TabAtkins> iank_: it wasn't clear to me what this resolution was doing, then, because it didn't mention the natural sizes at all<br> <TabAtkins> iank_: one interpretation is - we had a previous resolution that we always go from width to height. that can give a 0x0 natural size<br> <TabAtkins> iank_: you could interpret this resolution to say if you have a zero dimension, use the other, so it can apply the height to the width, but it wasn't clear<br> <TabAtkins> iank_: the previous resolution was to always coerce the natural block size to match the natural a-r<br> <TabAtkins> fantasai: the previous one was... If one of them is 0, you calculate from the other<br> <TabAtkins> astearns: the previous resolution has something you can do to make the natural sizes match a determined a-r<br> <TabAtkins> astearns: is there a case where we need to do something about the sizes when there's no a-r?<br> <TabAtkins> iank_: no, in that case, when there's no natural a-r, we dont' coerce the natural sizes at all<br> <TabAtkins> iank_: in the previous resolution we did talk about the zero case...<br> <TabAtkins> iank_: and we resolved to reflect the block size in that case (if the inline size was zero)<br> <TabAtkins> astearns: i'm hearing more questions than answers. should we take this back to the issue to see how much these resolutions interact?<br> <TabAtkins> iank_: i'm fine with that. my read was just that I didn't understand the second resolution, it wasn't using the correct wording.<br> <TabAtkins> iank_: and we'd already talked about the zero case in the first resolution, so I was confused about what it was trying to achieve<br> <TabAtkins> astearns: so we can take it back to the issue, or resolve to drop the second resolution and *then* bring it back to the issues<br> <TabAtkins> fantasai: I think what we were trying to do was, if you had a degen a-r and you were trying to apply it... if one of the dimensions of the a-r is zero you dont' really have an a-r<br> <oriol> present-<br> <TabAtkins> iank_: then you don't coerce the natural sizes at all in that case, no coercion of the other sizes<br> <TabAtkins> fantasai: this was prompted by some tests that expected only dropping the height even when there was a zero dimension<br> <TabAtkins> iank_: [describes a scenario] note that a zero dimension is different from a missing dimension. SVG can set any of the sizes, or not, independently<br> <TabAtkins> iank_: so this is just if you have a natural width and height *and* a non-degen a-r, the previous resolution always coerces the block dimension. it's very edge-casey, only matters if you have a zero natural width<br> <TabAtkins> astearns: sounds like this should go back to the issue, unfortunatelyu<br> <TabAtkins> astearns: should review the test cases that prompted this and see if they are testing the right thing, and if we need new tests<br> <TabAtkins> iank_: I think there are tests in interop and people are matching that...<br> <TabAtkins> fantasai: then we should probably resolve to match everyone<br> <TabAtkins> iank_: then we should resolve to drop the second resolution<br> <TabAtkins> astearns: okay. fantasai, thoughts?<br> <TabAtkins> fantasai: I think it's edge-casey enough that we should just spec compat<br> <TabAtkins> iank_: agreed<br> <fantasai> PROPOSED: Spec what we have interop on.<br> <TabAtkins> astearns: and you're sure the tests match the remaining resolutions?<br> <fantasai> :P<br> <TabAtkins> iank_: 90% sure, can quickly check<br> <TabAtkins> astearns: so proposed resolution is we drop the most recent resolution, and specify what we have interop on. objections?<br> <TabAtkins> RESOLVED: Spec reality here<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6286#issuecomment-3885858119 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 February 2026 17:25:27 UTC