05:46:09 RRSAgent has joined #svg 05:46:14 logging to https://www.w3.org/2026/07/02-svg-irc 05:46:15 Meeting: SVG WG 05:46:19 Chair: Dirk Schulze 05:46:21 Ragvesh has joined #svg 05:46:22 Agenda: https://github.com/w3c/svgwg/issues?q=is%3Aissue%20state%3Aopen%20label%3AAgenda%2B 05:46:25 krit has joined #svg 05:46:28 present+ 05:46:33 present+ 05:46:38 Zakim has joined #svg 05:46:46 present+ 05:47:19 topic: Remove instanceRoot and animatedInstanceRoot 05:47:26 https://github.com/w3c/svgwg/issues/852 05:47:34 I don't hear anything 05:47:58 present+ 05:48:41 nzimmermann has joined #svg 05:49:29 scribe: krit 05:49:55 karlcow: I looked at it last week: it is declared in the spec... 05:50:01 karlcow: but it is not implemented 05:50:16 krit: is that new to SVG2? 05:50:52 nzimmermann: it is SVG1.1 and used to be mandatory and important and pre-dates shadow root 05:51:34 nzimmermann: when you reference an element with use, browsers needed to build an instance tree. Events were part of the instance. This was dropped with SVG 2 and ShadowDom 05:51:49 nzimmermann: so this API is now useless and agree to drop it 05:52:09 present+ 05:52:25 RESOLUTION: Remove instanceRoot and animatedInstanceRoot in favor for ShadowDOM 05:52:48 topic: Media fragment percent fallback should reference css-images-3 default object size instead of CSS 2.1 05:52:59 https://github.com/w3c/svgwg/issues/1136 05:53:26 dmangal 05:53:38 viralipurbey has joined #svg 05:53:41 dmangal: We discussed it before 05:54:15 dmangal: when media fragments are involved and there is no witdth and height on SVG root, we agreed to follow the user style sheet with 500x250 05:54:41 dmangal: but what should happen if a viewbox is present but not width/height? What if only one is missing? 05:54:52 https://www.w3.org/TR/css-images-3/#default-sizing 05:54:56 dmangal: I suggest to use the default sizing algorithm in CSS3 05:55:57 dmangal: Firefox already follows the new spec text and Chrome is about to follow the newer default sizing algorithm 05:56:14 karlcow: I don't think it is an issue 05:56:43 karlcow: It doesn't pass in Safari right now but it would be expected. So agree to the proposal 05:57:00 nzimmermann: I wasn't aware of the sizing algorithm. I like it. 05:57:36 karlcow: the algorithm siziing has been implemented in WebKit but WPT doesn't pass. 05:57:48 dmangal: maybe because media fragments are not supported in WebKit. 05:57:52 karlcow: probably. 05:58:10 RESOLUTION: Media fragment percent fallback should reference css-images-3 default object size 05:58:18 ACTION: dmangal will update the spec text 05:58:30 topic: SVGAngle.animVal.unitType during animation between different units is unspecified 05:58:38 https://github.com/w3c/svgwg/issues/1146 05:59:10 viralipurbey: this is about the angle in SVG. When animating from one angle to another, and the unit types differ, the spec doesn't say what the unit type should be. 05:59:22 viralipurbey: Chrome and WebKit return a canonical unit 05:59:54 viralipurbey: but there is a WPT test failing in Safati and Chrome but passing in Firefox. The spec is not clear which implementation is right 06:00:39 nzimmermann: I'd rather go to the baseVal unit. If the animation goes away, we would fallback to baseVal. 06:01:00 nzimmermann: this would be consistent and independent of from-to-by animation types if we stick to the base-val 06:01:18 viralipurbey: I'd like to add that CSS uses canonical units 06:02:12 nzimmermann: I wasn't aware. Maybe we should follow CSS? 06:02:21 nzimmermann: what about length and other types? 06:02:27 nzimmermann: like cm to inch? 06:02:49 nzimmermann: would the solution for SVGAngle apply to all types, not just angles? 06:02:55 viralipurbey: let me check that 06:03:22 https://wpt.fyi/results/svg/animations?label=master&label=experimental&aligned&q=unitType 06:03:29 nzimmermann: using the baseVal can be helpful for devs because they can specify it. 06:04:00 karlcow: SVGLength seems to be passing for everyone 06:04:36 karlcow: it is only testing pixel to cm 06:05:19 ACTION: karlcow viralipurbey to test behavior across all types and units to find a common ground 06:07:19 https://github.com/w3c/csswg-drafts/issues/14028 06:09:19 https://github.com/w3c/csswg-drafts/issues/14028 06:10:17 Topic: [circle][ellipse] SVG 2 silent on negative values for cx/cy 06:10:25 https://github.com/w3c/svgwg/issues/1145 06:10:29 https://github.com/w3c/svgwg/issues/1145 06:12:02 karlcow: The SVG2 spec does not say negative values are forbidden for geometry attributes (specifically rx and ry) only makes sense for x and y? 06:12:36 krit: what happens if r, rx, ry are negative in implementations today 06:12:46 karlcow: In Chrome+Firefox it goes to zero 06:13:49 viralipurbey: It is fair to have a value greater zero 06:14:06 https://github.com/WebKit/WebKit/pull/68442 06:14:06 dmangal: we might print something if rx is valid but ry isn't 06:14:30 https://bug-318324-attachments.webkit.org/attachment.cgi?id=480272 06:15:13 krit: so you suggest ignore negative values. 06:15:27 karlcow: yes, Firefox is consistent. Blink and Webkit have a different behavior 06:15:41 karlcow: the fallback value is 0 06:16:00 karlcow: ... in Firefox it is 0 06:16:09 nzimmermann: that is the default, no? 06:16:16 krit: default is auto. 06:16:27 karlcow: suggest to go to 0 06:17:03 karlcow: baseVal stays negative for FF and Blink. But specified value is 0. 06:17:21 karlcow: for rectangle the getComputedStyle would be auto and FF is 0. 06:17:40 s/specified value/getComputedStyle/ 06:19:01 dmangal: The spec already mentioned that computed style is auto and resolves to 0 06:19:21 karlcow: the spec says it for r and rx and ry but not for dimension values 06:19:35 nzimmermann: so lets make it consistent for all values 06:19:38 karlcow: yes 06:19:54 viralipurbey: then we need to define it for all objects 06:20:05 viralipurbey: there should be a fallback 06:20:54 karlcow: suggesting to follow FF: computed style would be auto and resolved values to 0 06:21:16 dmangal: width and height it may resolve to 100% or 0 06:22:09 dmangal: lets say an SVG outer SVG element with negative width and height should be 100% and not 0 06:22:39 https://w3c.github.io/svgwg/svg2-draft/geometry.html#Sizing 06:22:42 krit: So you suggest for shape elements it would resolve to 0, but for outer SVG it could be 100%? 06:22:58 Svg element -> auto -> 100% 06:23:11 All other elements -> auto -> 0 06:23:41 RESOLUTION: negative length values on presentation attributes that do not allow negative values compute to auto and resolve to 0. Need to define the behavior on non geometry elements later. 06:23:51 Image -> auto -> 300x150 06:26:16 RRSAgent: make minutes 06:26:17 I have made the request to generate https://www.w3.org/2026/07/02-svg-minutes.html krit 06:26:27 RRSAgent: make logs public 07:58:24 Zakim has left #svg