Minutes, May 7 2026 SVG WG telcon

Minute from today’s telcon: https://www.w3.org/2026/05/07-svg-minutes.html


IRC log of svg on 2026-05-07

Timestamps are in UTC.

05:42:17 [RRSAgent]
RRSAgent has joined #svg
05:42:21 [RRSAgent]
logging to https://www.w3.org/2026/05/07-svg-irc

05:43:45 [karlcow]
Meeting: SVG WG
05:43:45 [karlcow]
Agenda: https://github.com/w3c/svgwg/issues?q=state%3Aopen%20label%3AAgenda%2B

05:43:58 [karlcow]
present+
05:45:29 [nzimmermann]
nzimmermann has joined #svg
05:45:31 [nzimmermann]
present+
05:46:07 [krit]
present+
05:46:15 [Vinay]
Vinay has joined #svg
05:46:28 [krit]
scribe: krit
05:47:06 [ydaniv]
ydaniv has joined #svg
05:47:20 [ydaniv]
present+
05:48:25 [Vinay]
present+
05:48:26 [krit]
topic: currentTranslate on SVGSVGElement. Not covered by current WPT
05:48:31 [krit]
https://github.com/w3c/svgwg/issues/1094

05:49:16 [krit]
karlcow: currentTranslate is not covered in WPT for SVGSVGElement
05:49:51 [krit]
karlcow: I'd like someone to review the test if I get something wrong. The test reveals some differences across browsers.
05:50:20 [krit]
https://github.com/w3c/svgwg/issues/1094#:~:text=SVGSVGElement%2DcurrentTranslate.html

05:50:43 [krit]
karlcow: 9 tests
05:51:07 [krit]
nzimmermann: I checked the tests. It is good to have a test.
05:51:22 [krit]
nzimmermann: Unfortunate that the test uses SVG2 DOM
05:51:35 [krit]
nzimmermann: We removed this feature from SVG 2
05:52:16 [krit]
nzimmermann: Testing translation with 0 is difficult. There is no way to validiate in browsers as browsers trigger translation differently.
05:52:32 [krit]
nzimmermann: IMO the method has no value as there are no use cases
05:52:35 [ydaniv]
ydaniv has joined #svg
05:52:49 [krit]
karlcow: I'd be careful as we also have editors and viewers (beside browsers)
05:53:10 [krit]
karlcow: I wonder if currentTranslate would be useful for an SVG editor
05:53:24 [krit]
nzimmermann: It could have been useful in SVG 1.1 but not with the changed DOM
05:53:55 [krit]
nzimmermann: Maybe we shouldn't drop it.
05:54:11 [viralipurbey]
viralipurbey has joined #svg
05:55:33 [krit]
const ct = outer.currentTranslate;
05:55:33 [krit]
ct.x = 10;
05:55:33 [krit]
ct.y = 20;
05:55:33 [krit]
assert_equals(ct.x, 10, "x must be writable on outermost svg");
05:55:33 [krit]
assert_equals(ct.y, 20, "y must be writable on outermost svg");
05:55:34 [krit]
ct.x = 0;
05:55:34 [krit]
ct.y = 0;
05:55:50 [krit]
nzimmermann: you'd need to check that it is never writeable
05:56:11 [karlcow]
https://w3c.github.io/svgwg/svg2-draft/struct.html#__svg__SVGSVGElement__currentTranslate

05:56:18 [krit]
karlcow: Spec says it must be read-only
05:56:24 [karlcow]
> On getting currentTranslate, the SVGSVGElement object's current translate point object is returned. This object represents the current translation for the ‘svg’ element. A current translate point object must be read only when its ‘svg’ element is not the outermost svg element, and writable otherwise.
05:56:31 [krit]
karlcow: sorry, it says it can be writeable
05:56:45 [krit]
karlcow: read-only for outermost SVG elements
05:58:01 [krit]
krit: So the 8th item in the test is wrong?
05:58:13 [krit]
karlcow: yes, but it is passing in WebKit. So need to check why?
05:59:16 [krit]
karlcow: Ah I got confused by the spec text with the double negation.
05:59:37 [krit]
nzimmermann: Right, so the test is correct and the spec text, its intention, is right as well.
05:59:59 [krit]
karlcow: I can make the text more clear
06:00:36 [krit]
karlcow: plan to push the test to WPT
06:00:55 [krit]
nzimmermann: I am confused about DOMPoint and DOMPointReadOnly
06:01:30 [krit]
nzimmermann: for me it sounds that DOMPointReadOnly should be unmutable. But the properties may change.
06:01:44 [krit]
s/may change/may change internally/
06:01:59 [krit]
nzimmermann: technically this is what we do and therefore is correct.
06:02:23 [krit]
karlcow: Shouldn't it be SVGPoint?
06:02:34 [krit]
krit: Isn't SVGPoint just an alias to DOMPoint now?
06:03:49 [ydaniv]
ydaniv has joined #svg
06:05:49 [nzimmermann]
`currentTranslate attribute is readonly (not replaceable):
06:05:49 [nzimmermann]
assert_equals: assigning to currentTranslate must not replace the object expected object "[object SVGPoint]" but got object "[object SVGPoint]"`
06:06:05 [krit]
nzimmermann: To the confusion to Robert: I think he is referring to --^
06:06:34 [krit]
nzimmermann: Chrome still expose SVGPoints but that should not be possible
06:06:49 [krit]
nzimmermann: ...it Firefox it throws
06:09:21 [krit]
krit: So the confusion: currentTranslate can not be set to a new DOMPoint but you can mutate the properties?
06:09:26 [krit]
nzimmermann: seems so
06:09:38 [karlcow]
https://drafts.csswg.org/geometry/#DOMPoint

06:10:30 [krit]
topic: Status of animVal deprecation
06:10:35 [krit]
https://github.com/w3c/svgwg/issues/1100

06:11:02 [krit]
nzimmermann: I attached a test case
06:12:25 [krit]
nzimmermann: circle with SMIL animation and a requestAnimationFrame which checks baseVal and animVal on every frame. All browsers show a change in animVal which is correct according to SVG 1.1. But SVG2 says animVal is an alias for baseVal. Why do implementations still have the complex implementation?
06:12:39 [krit]
nzimmermann: I still believe we should drop animVal
06:13:17 [krit]
nzimmermann: Animations should use HW accelearation and animVal may block the optimization.
06:14:01 [krit]
nzimmermann: Robert states that we should rather look at browser differences and not look at features that are reliably working in browsers today
06:14:32 [krit]
nzimmermann: this means: Should we re-add animVal to reflect todays browser behavior or shall we drop it and force browsers to change?
06:15:35 [krit]
nzimmermann: Making the change should be easy as you can simply map animVal to baseVal and keep the animation update code for now.
06:15:43 [ydaniv]
ydaniv has joined #svg
06:15:50 [krit]
nzimmermann: there is no test-coverage at all in WPT either
06:16:01 [krit]
nzimmermann: you'd be able to control the timeline programmatically
06:16:25 [krit]
krit: Doesn't WebAnimation support this?
06:16:45 [krit]
nzimmermann: Then it might be able to do it but not sure.
06:17:53 [krit]
krit: ultimately a question to browser vendors. But it is an opportunity to optimize implementation later if we keep dropping animVal.
06:18:15 [krit]
ydaniv: As an author, I don't expect anything new from SVG SMIL
06:18:27 [krit]
ydaniv: ..especially with interop in mind.
06:18:40 [krit]
krit: we have interop
06:19:47 [krit]
ydaniv: Since it is there, it is a good fallback
06:20:00 [krit]
ydaniv: ultimately we want to move forward to CSS
06:20:16 [krit]
nzimmermann: but it also doesn't mean to drop SMIL. This is only about animVal in SVG DOM
06:21:48 [krit]
krit: As a middle ground, we could say: animVal SHOULD alias baseVal and keep it unspecified what happens if the implementation does not.
06:22:17 [krit]
nzimmermann: It would not hurt. We could keep the implementation but new implementations can choose not to implement it
06:22:39 [viralipurbey]
viralipurbey has joined #svg
06:26:35 [ydaniv]
ydaniv has joined #svg
06:26:46 [krit]
nzimmermann: Maybe we can setup a meeting to see what the point of browser vendors and see if we can make a cut all together.
06:26:57 [krit]
topic: Clarify SMIL animation behavior when path 'd' value is an empty string
06:27:11 [krit]
https://github.com/w3c/svgwg/issues/1102

06:27:21 [ydaniv]
ydaniv has joined #svg
06:29:00 [krit]
RRSAgent, make minutes
06:29:02 [RRSAgent]
I have made the request to generate https://www.w3.org/2026/05/07-svg-minutes.html krit
06:29:54 [krit]
RRSAgent, make logs public