05:42:26 RRSAgent has joined #svg 05:42:30 logging to https://www.w3.org/2026/05/21-svg-irc 05:42:35 krit has joined #svg 05:42:58 Tav has joined #svg 05:42:58 dmangal has joined #svg 05:43:18 Zakim has joined #svg 05:43:23 Meeting: SVG WG 05:43:23 Chair: Dirk Schulze 05:43:38 Agenda: https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20label%3AAgenda%2B 05:43:45 present+ 05:44:08 Vinay has joined #svg 05:44:27 present+ 05:45:10 present+\ 05:45:12 present+ 05:45:17 scribe: krit 05:46:12 topic: chained filter support, aka href on the filter element 05:46:13 present+ 05:46:20 https://github.com/w3c/svgwg/issues/1111 05:46:38 karlcow: Filter was removed from SVG 2 into its own spec as part of the CSS charter. 05:46:52 karlcow: There is a mechanism of chaining filters. 05:47:23 karlcow: This allowed multiple filter elements where href referencing the first filter element 05:47:42 karlcow: This is working in Firefox but not in Chrome or Safari 05:48:01 present+ 05:48:14 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 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 karlcow: Do we keep it? If we keep it, what is the interest of Chrome and Safari? 05:49:47 karlcow: Spec text needs to be added. 05:50:11 karlcow: The CSS spec has no reference at all of the DOM SVG URI mixing. 05:50:55 krit: This was a joined spec between SVG and CSS WG and requires approval from both groups. 05:51:04 karlcow: The CSS WG specifically asks for input. 05:53:14 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 nzimmermann: I would be in favor of removing due to the complexity 05:55:24 dmangal: Robert mentions chaining gradients and patterns? 05:55:26 viralipurbey has joined #svg 05:55:54 krit: there is for gradients but not for patterns AFAIK 05:56:00 https://w3c.github.io/svgwg/svg2-draft/pservers.html#LinearGradientElementHrefAttribute 05:56:15 dmangal: I am leaning to agree with Niko that this is more work to do. 05:56:20 > 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 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 https://w3c.github.io/svgwg/svg2-draft/pservers.html#PatternElementAttributes 05:57:33 > A URL reference to a template element, which must be a different ‘pattern’ element to be valid. 05:57:33 > 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 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 nzimmermann: I am still believe we should remove it. 05:58:14 nzimmermann: I don't see a use case for the chaining either. 05:58:58 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 Tav: I'd rather like implementations to focus on other implementation aspects :) 05:59:36 nzimmermann has joined #svg 05:59:40 present+ 06:00:10 dmangal: We have no users asking for it. 06:00:16 Tav: No opinion 06:00:21 nzimmermann: Remove it. 06:00:51 Vinay: We can remove it. We can not force FF to do it of course. 06:02:24 RESOLUTION: Suggestion to CSS WG: Remove possibility for filters to reference other filters. Remove the SVG URI DOM interface as well. 06:02:37 https://drafts.csswg.org/filter-effects-1/#InterfaceSVGFilterElement 06:04:02 nzimmermann: Filter is in the same category as masking and clipping which does not allow chaining. 06:04:21 krit: For clippath we do have chaining? 06:04:41 nzimmermann: I was specifically referencing to href 06:05:16 topic: Clarify SMIL animation behavior when path 'd' value is an empty string 06:05:21 https://github.com/w3c/svgwg/issues/1102 06:05:42 viralipurbey: About the behavior of SMIL animation on empty path string animations. 06:06:00 viralipurbey: It is not clear how to apply the animation from from to to. 06:06:32 viralipurbey: For from animations have discrete animations and by animations will not animate. 06:07:10 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 viralipurbey: I believe that the FF behavior is the right way to go. 06:08:45 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 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 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 nzimmermann: progression for authors. 06:13:31 RESOLUTION: Follow the suggestion of the cSS WG and let pathLength take a length value rather than a number value. 06:13:43 topic: Status of animVal deprecation 06:13:50 https://github.com/w3c/svgwg/issues/1100 06:14:19 nzimmermann: No update yet. Asked Robert but waiting for a response. 06:14:37 nzimmermann: We need to move in one or the other way. 06:15:47 krit: lets try contacting him again and wait for another 2 weeks before we get to a final decision. 06:16:19 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 dmangal: We can add usage counter and that would be the better way before removing it. 06:19:46 https://github.com/w3c/svgwg/pull/1092 06:19:55 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 topic: Fix #1091 - Clarify the prose of Rendering order section 06:20:16 https://github.com/w3c/svgwg/pull/1092 06:20:50 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 viralipurbey: I'll review it later. 06:22:09 RRSAgent: make minutes 06:22:11 I have made the request to generate https://www.w3.org/2026/05/21-svg-minutes.html krit 06:22:39 RRSAgent, make logs public 12:30:32 Zakim has left #svg 12:44:12 caribou, https://github.com/w3c/fxtf-drafts is confusing, because issues for these specs are opened in the two places. https://github.com/w3c/csswg-drafts/ 12:44:12 I wonder if the first one should have all its issues transferred to the CSS WG and be archived. 12:49:47 it's up to the editors, I suppose 12:55:49 there's a high number of issues, on quite a number of specs 13:44:16 Is it possible to block the opening of new issues? 13:45:07 archiving would do it, but I guess it also blocks the transfering since it makes the repo read-only 13:45:27 Ah! :) 13:46:05 there are interactions limits (like moderation), that might work... 13:47:32 I've enabled "Limit to repository collaborators" for 6 months (that's the max duration) 13:50:49 the entire css WG will still have access, as well as former SVG group, chair, me, you 13:51:31 and a couple of other people 14:50:44 <3 16:46:01 github-bot has joined #svg