SVG WG Call

<krit> https://github.com/w3c/svgwg/pulls?q=is%3Apr+is%3Aopen+label%3AAgenda%2B

We are discussing two items on the agenda and one PR

<https: //github.com/w3c/svgwg/pull/999, Adding resolution of content dependent units used in sizing properties for inner SVG element>

<krit> w3c/svgwg#999

Adding resolution of content dependent units used in sizing properties for inner SVG element

Ragvesh introduces the PR, what the issue is about, what it solves

"The CSS Working Group just discussed [css-sizing-3][css-values-4] Define `width` and `height` CSS values for SVG Elements in a mapping, and agreed to the following: RESOLVED: content dependent units used in width and height for inner SVG elements resolve to SVG's definition of auto"

There is an ambiguity for SVG elements: min-content, max-content, fit-content and calc-size depend on CSS box models

proposal: resolve the into 'auto'

<karlcow> https://svgwg.org/svg2-draft/geometry.html#Sizing

RESOLUTION: SVG WG agrees to resolve context-dependent units to "auto"

only the root SVG element creates a box, not any inner element, so that definition makes most sense within SVG

Dirk explains usually we don't include those resolutions into SVG spec, but usually the information goes into the CSS values & units spec -- if we put it into the SVG spec it cannot be a note, just a comment

<caribou> CSS Values and Units Module Level 4

<caribou> https://www.w3.org/TR/css-values-4/

We need to update the SVG spec to refer to the latest CSS Values and Units Module Level 4

Proposal from Dirk: if an element does not have an associated CSS box model object, all the "context-dependent" units should resolve to "auto".

<karlcow> https://www.w3.org/TR/css-sizing-3/#valdef-width-auto

that could go directly go into the CSS Values and Units Module Level 4 spec

<caribou> the elements min-content, max-content, fit-content and calc-size are not mentioned in Values at all. Only in the box sizing module

question from Carine: where there other proposals rather than auto? no, it was the only one

<krit> w3c/svgwg#1015

Testing

Nico: I opened the issue after last week's discussion
… some WPT tests associated to other specs
… there are many interesting things that are not tested yet
… to my knowledge there are tests in browsers
… is there interest to look at those CSS, SVG and HTML tests

Karl: we lack a lot of the tests, some are not in WPT
… definitely YES, we should list what's missing and add them little by little

Dirk: we should collect existing tests from browsers
… add 3D transform tests too.

Nico: It makes sense to have some tests in CSS transforms
… no matter where, we need coverage

Nico: most noticeably, any kind of CSS positioning of objects, untested and maybe unspecified
… e.g. an absolute-position CSS in a foreign object is heavilly broken in webkit
… we can improve by adding the tests in WPT

<karlcow> https://bugs.webkit.org/show_bug.cgi?id=291732

DIrk: agree
… a few tests would be a step in the right direction and other tests will be contributed

<karlcow> WebKIt Tests not under WPT https://github.com/WebKit/WebKit/tree/main/LayoutTests/svg

Nico: static tests for non-browser implementations

Tav: there are already such tests in WPT
… probably not sufficient

back

discussing if we should publish another SVG2 draft

Carine mentions we need an specification references

Dirk mentions we haven't had edits in a few years, but it still makes sense to have a "heartbeat" release, to show that we are still working on it

Carine mentions the latest publication was a CR, if we publish something now it should be a working draft

Dirk mentions this is a "step back" -- asking why we should go back to WD

Carine thinks the SVG spec is not in a CR state at the moment (outdated spec links etc)

Dirk says, we should update all the external spec links, bring them up2date etc

Eventually it makes sense to make SVG a live spec, to avoid those states CR/WD... Carine explains that the current SVG charter allows to choose between REC with amendments and live CR with CR snapshots (for IPR) in between, but updating specs in that state is not easy (amendments are not easy to deal with)

request to have a hybrid call at the TPAC

Dirk created a "breakout session" proposal at w3c GitHub - it requires voting from the members

<caribou> w3c/tpac2025-breakouts#18

next part is voting for the session, if it gets accepted, we can have a call and breakout session at TPAC