- From: Kevin Babbitt via GitHub <noreply@w3.org>
- Date: Mon, 23 Jun 2025 23:15:33 +0000
- To: public-css-archive@w3.org
I think the actual specification of behavior here most likely belongs in SVG2, and it's probably worth opening an issue in https://github.com/w3c/svgwg for it. Having said that, I think it's also useful to have a discussion in the CSSWG on the intent behind some of the values where the application to SVG is unclear, to help inform what the SVG spec language should be. My thoughts on the proposals: For the [viewport-percentage lengths](https://www.w3.org/TR/css-values-4/#viewport-relative-lengths), resolving them against the closest established SVG viewport would just make them behave identically to % units. I think it might be more useful, and more consistent with how these units work in CSS, to resolve these against the [furthest ancestral SVG viewport](https://svgwg.org/svg2-draft/coords.html#TermFurthestAncestorSVGViewport) instead. For any sizing that depends on content in CSS, treating it as 100% in SVG seems reasonable to me, since it follows the precedent set by [`auto`](https://www.w3.org/TR/SVG2/geometry.html#Sizing). This would include `min-content`, `max-content`, and `fit-content()`. I wonder if css-sizing-3 should define an umbrella term for this group of sizes, so that we have a ready answer for future additions to it. For other cases, I think the expected behavior can reasonably be derived from existing spec text. I'm glad to see you have a PR open to add WPTs for various cases. cc a few others who might have thoughts: @tabatkins @fantasai @svgeesus @bfgeek -- GitHub Notification of comment by kbabbitt Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12376#issuecomment-2998252957 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 June 2025 23:15:34 UTC