Minutes, May 21 2026 SVG WG telcon

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


IRC log of svg on 2026-05-21

Timestamps are in UTC.

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

05:42:35 [krit]
krit has joined #svg
05:42:58 [Tav]
Tav has joined #svg
05:42:58 [dmangal]
dmangal has joined #svg
05:43:18 [Zakim]
Zakim has joined #svg
05:43:23 [karlcow]
Meeting: SVG WG
05:43:23 [karlcow]
Chair: Dirk Schulze
05:43:38 [karlcow]
Agenda: https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20label%3AAgenda%2B

05:43:45 [karlcow]
present+
05:44:08 [Vinay]
Vinay has joined #svg
05:44:27 [dmangal]
present+
05:45:10 [krit]
present+\
05:45:12 [krit]
present+
05:45:17 [krit]
scribe: krit
05:46:12 [krit]
topic: chained filter support, aka href on the filter element
05:46:13 [caribou]
present+
05:46:20 [krit]
https://github.com/w3c/svgwg/issues/1111

05:46:38 [krit]
karlcow: Filter was removed from SVG 2 into its own spec as part of the CSS charter.
05:46:52 [krit]
karlcow: There is a mechanism of chaining filters.
05:47:23 [krit]
karlcow: This allowed multiple filter elements where href referencing the first filter element
05:47:42 [krit]
karlcow: This is working in Firefox but not in Chrome or Safari
05:48:01 [Tav]
present+
05:48:14 [krit]
karlcow: In the Filter Effects spec there is a reference to SVG URI as a mixing for DOM. But it is not defined at all in the prose.
05:48:53 [krit]
karlcow: Robert, from FF, would like to not remove the feature. So putting it on the agenda what we should do with it.
05:49:24 [krit]
karlcow: Do we keep it? If we keep it, what is the interest of Chrome and Safari?
05:49:47 [krit]
karlcow: Spec text needs to be added.
05:50:11 [krit]
karlcow: The CSS spec has no reference at all of the DOM SVG URI mixing.
05:50:55 [krit]
krit: This was a joined spec between SVG and CSS WG and requires approval from both groups.
05:51:04 [krit]
karlcow: The CSS WG specifically asks for input.
05:53:14 [krit]
nzimmermann: What is the definition of filter units in the case of chaining filter elements. IMO it is very unfortunate. You can do the same by shuffeling the elements in the document for browsers it is hard to do to keep the invalidation paths for multiple filter effects at the same time.
05:54:46 [krit]
nzimmermann: I would be in favor of removing due to the complexity
05:55:24 [krit]
dmangal: Robert mentions chaining gradients and patterns?
05:55:26 [viralipurbey]
viralipurbey has joined #svg
05:55:54 [krit]
krit: there is for gradients but not for patterns AFAIK
05:56:00 [karlcow]
https://w3c.github.io/svgwg/svg2-draft/pservers.html#LinearGradientElementHrefAttribute

05:56:15 [krit]
dmangal: I am leaning to agree with Niko that this is more work to do.
05:56:20 [karlcow]
> A URL reference to a template gradient element; to be valid, the reference must be to a different ‘linearGradient’ or a ‘radialGradient’ element.
05:56:54 [krit]
nzimmermann: There is another aspect to gradients and patterns: it is purely resolved on the DOM side for Chrome and Safari. For filters it is different.
05:57:32 [karlcow]
https://w3c.github.io/svgwg/svg2-draft/pservers.html#PatternElementAttributes

05:57:33 [karlcow]
> A URL reference to a template element, which must be a different ‘pattern’ element to be valid.
05:57:33 [karlcow]
> Refer to the process for using paint servers as templates, and to the common handling defined for URL reference attributes and deprecated XLink attributes.
05:57:37 [krit]
nzimmermann: Webkit is not prepared for such reference chains. While for SVG we have to do these loops of masks, gradients, resources in general.
05:57:56 [krit]
nzimmermann: I am still believe we should remove it.
05:58:14 [krit]
nzimmermann: I don't see a use case for the chaining either.
05:58:58 [krit]
Tav: We don't implement it. It might not be as useful but I don't think it would be to hard to implement for InkScape.
05:59:31 [krit]
Tav: I'd rather like implementations to focus on other implementation aspects :)
05:59:36 [nzimmermann]
nzimmermann has joined #svg
05:59:40 [nzimmermann]
present+
06:00:10 [krit]
dmangal: We have no users asking for it.
06:00:16 [krit]
Tav: No opinion
06:00:21 [krit]
nzimmermann: Remove it.
06:00:51 [krit]
Vinay: We can remove it. We can not force FF to do it of course.
06:02:24 [krit]
RESOLUTION: Suggestion to CSS WG: Remove possibility for filters to reference other filters. Remove the SVG URI DOM interface as well.
06:02:37 [karlcow]
https://drafts.csswg.org/filter-effects-1/#InterfaceSVGFilterElement

06:04:02 [krit]
nzimmermann: Filter is in the same category as masking and clipping which does not allow chaining.
06:04:21 [krit]
krit: For clippath we do have chaining?
06:04:41 [krit]
nzimmermann: I was specifically referencing to href
06:05:16 [krit]
topic: Clarify SMIL animation behavior when path 'd' value is an empty string
06:05:21 [krit]
https://github.com/w3c/svgwg/issues/1102

06:05:42 [krit]
viralipurbey: About the behavior of SMIL animation on empty path string animations.
06:06:00 [krit]
viralipurbey: It is not clear how to apply the animation from from to to.
06:06:32 [krit]
viralipurbey: For from animations have discrete animations and by animations will not animate.
06:07:10 [krit]
viralipurbey: For empty path it is not clear though. Firefox already implements it as discrete animations for from and for by they do not animate and use the base value.
06:07:59 [krit]
viralipurbey: I believe that the FF behavior is the right way to go.
06:08:45 [krit]
viralipurbey: In Chrome we just implemented empty string and did start from 0. I don't think that is correct and we reverted it.
06:10:42 [krit]
RESOLUTION: For SMIL animation on empty path strings we use discrete animations for from animations and no interpolation and animation for by animation making it consistent with incompatible commands.
06:12:05 [krit]
viralipurbey: Path length extending was discussed in CSS. This is about changing it from number to length. We agreed to first concentrate on presentation attributes. The CSS WG has a resolution to change the type from number to length.
06:12:55 [krit]
nzimmermann: progression for authors.
06:13:31 [krit]
RESOLUTION: Follow the suggestion of the cSS WG and let pathLength take a length value rather than a number value.
06:13:43 [krit]
topic: Status of animVal deprecation
06:13:50 [krit]
https://github.com/w3c/svgwg/issues/1100

06:14:19 [krit]
nzimmermann: No update yet. Asked Robert but waiting for a response.
06:14:37 [krit]
nzimmermann: We need to move in one or the other way.
06:15:47 [krit]
krit: lets try contacting him again and wait for another 2 weeks before we get to a final decision.
06:16:19 [krit]
nzimmermann: I'd like to get more understanding from the Chrome team as well: Are there use counters? What would we need to get to a resolution.
06:16:58 [krit]
dmangal: We can add usage counter and that would be the better way before removing it.
06:19:46 [dmangal]
https://github.com/w3c/svgwg/pull/1092

06:19:55 [krit]
nzimmermann: We need to be careful as many might use animVal because it would give the same result on baseVal in case of no animation
06:20:12 [krit]
topic: Fix #1091 - Clarify the prose of Rendering order section
06:20:16 [krit]
https://github.com/w3c/svgwg/pull/1092

06:20:50 [krit]
karlcow: Just suggesting to make the section easier to read... no change of normative behavior. I have a PR for it. Please review.
06:20:55 [krit]
viralipurbey: I'll review it later.
06:22:09 [krit]
RRSAgent: make minutes
06:22:11 [RRSAgent]
I have made the request to generate https://www.w3.org/2026/05/21-svg-minutes.html krit
06:22:39 [krit]
RRSAgent, make logs public