Minutes, March 19 2026 SVG WG telcon

Minutes from today's telcon are below.

<https://www.w3.org/2026/03/19-svg-minutes.html>
SVG WG Meeting - March 19, 2026 – 19 March 2026<https://www.w3.org/2026/03/19-svg-minutes.html>
w3.org<https://www.w3.org/2026/03/19-svg-minutes.html>
[favicon.ico]<https://www.w3.org/2026/03/19-svg-minutes.html>

IRC log of svg on 2026-03-19

Timestamps are in UTC.

06:46:18 [RRSAgent]
RRSAgent has joined #svg
06:46:22 [RRSAgent]
logging to https://www.w3.org/2026/03/19-svg-irc

06:46:31 [krit]
present+
06:46:53 [dmangal]
present+
06:47:20 [viralipurbey]
viralipurbey has joined #svg
06:47:31 [krit]
topic: Overflow property behavior / spec on SVG element doesn't match reality.
06:47:34 [caribou]
present+
06:47:42 [karlcow]
present+
06:47:46 [krit]
https://github.com/w3c/svgwg/issues/1072

06:48:26 [krit]
karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox
06:48:52 [krit]
scribe: krit
06:49:09 [krit]
karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox
06:49:58 [krit]
karlcow: Depending how SVG elements are nested, the behavior of style overflow for auto on inner SVG elements, the elements get visible.
06:50:48 [krit]
viralipurbey: This seems to be a bug in WebKit and Blink: When overflow is specified, the content should get clipped. It isn't in the 2 engines. So spec is clear and this is a bug.
06:51:15 [krit]
dmangal: I have a different view
06:51:44 [krit]
dmangal: in the spec it says on the document level, auto can result in visible or scroll.
06:51:50 [krit]
dmangal: So there can be 2 operations.
06:51:52 [karlcow]
Meeting: SVG WG Meeting - March 19, 2026
06:52:58 [krit]
nzimmermann: it defines clipping. If you have a srcoll, then content should not be clipped but scrollbars should get visible. But it is not clearly written.
06:53:50 [krit]
dmangal: In overflow clip section linked, there are bullet points (4th point). Within SVG content, auto implies content needs to be visible by either showing scroll bars or making the content visible.
06:54:06 [krit]
nzimmermann: So bounding box of the element matters. It is not intrinsic.
06:54:09 [karlcow]
> Within SVG content, the value auto implies that all rendered content for child elements must be visible, either through a scrolling mechanism, or by rendering with no clip. For elements where the value of scroll results in a scrolling mechanism being used by the user agent, then a value of auto may be treated as scroll. If the user agent has no scrolling mechanism, the content would not be clipped, or the value 'scroll' is treated as hidden, then t
06:54:09 [karlcow]
he value auto must be treated as visible
06:54:46 [krit]
nzimmermann: If you have a rect 600x600 in an SVG with 300x300, w/ auto you would have a scrollbar. Otherwise you'd clip the rect.
06:54:59 [karlcow]
https://w3c.github.io/svgwg/svg2-draft/render.html#:~:text=content%20is%20clipped.-,Within%20SVG%20content,-%2C%20the%20value%20auto

06:55:02 [krit]
nzimmermann: ..."all elements must be visible"
06:56:17 [krit]
nzimmermann: this is a heavy operation: on a complex documents, you need to re-layout the outermost element on any change. This will trigger a relayout and potentially gets into a relayout loop. This is certainly not implemented in WebKit and would be a performance issue.
06:57:05 [krit]
nzimmermann: I'd always base the behavior on the intrinsic size of the SVG.... Wait, that might not make sense. You might still need to compute the dimensions of hte children
06:57:29 [krit]
nzimmermann: So any overflow behavior for auto other than clip would mean recomputing layout of all children.
06:58:07 [dmangal]
<!doctype html>
06:58:07 [dmangal]
<svg style="overflow: auto" height="90px" width="90px">
06:58:07 [dmangal]
<!--<svg style="overflow: visible" height="90px" width="90px" x="0" y="0">-->
06:58:07 [dmangal]
<rect id="overflows" height="100px" width="100px" fill="red" x="-5px" y="-5px" />
06:58:09 [dmangal]
<rect height="90px" width="90px" fill="green" />
06:58:09 [dmangal]
<!--</svg>-->
06:58:09 [dmangal]
</svg>
06:58:10 [dmangal]
<br>
06:58:10 [dmangal]
<br>
06:58:10 [dmangal]
<svg style="overflow: visible" height="90px" width="90px">
06:58:11 [dmangal]
<!--<svg style="overflow: auto" height="90px" width="90px" x="0" y="0">-->
06:58:11 [dmangal]
<rect id="overflows" height="100px" width="100px" fill="red" x="-5px" y="-5px" />
06:58:11 [dmangal]
<rect height="90px" width="90px" fill="green" />
06:58:12 [dmangal]
<!--</svg>-->
06:58:12 [dmangal]
</svg>
06:58:17 [krit]
dmangal: not sure of Blinks solution but I get the same behavior in Chrome and Firefox.
06:58:46 [krit]
dmangal: For the 2nd SVG, Blink and Webkit are resolving the content to visible.
06:59:17 [krit]
dmangal: The example above and the example in the issue should prouce the same output. Let me know if you see it differently
06:59:45 [krit]
nzimmermann: not following. 2nd exampole: If we change auto to hidden, then it looks like 1st example.
06:59:55 [krit]
nzimmermann: if you go to visible, you see the red border
07:00:26 [krit]
nzimmermann: so following the spec, (auto should either be visible or scroll), wouldn't we need a scrollbar? Otherwise it would be clipped.
07:00:44 [krit]
nzimmermann: The spec seems to apply this behavior and no browser applies
07:00:55 [krit]
nzimmermann: WebKit never shows scrollbars on SVGs.
07:01:06 [krit]
dmangal: So we should always compute to visible?
07:01:09 [krit]
nzimmermann: not sure
07:01:55 [krit]
nzimmermann: The behavior in Wbekit the behavior is coming from the box model behavior of CSS.
07:02:15 [krit]
nzimmermann: I imagine no browser actually supports overlow visible behavior in any browser
07:02:26 [krit]
dmangal: even FF has hidden behavior
07:03:17 [krit]
nzimmermann: don't get scroll for any SVG element in none browser but I did not test
07:03:34 [krit]
dmangal: do we need this in SVG? There is no box model. We don't have a spec for this.
07:04:02 [krit]
nzimmermann: Agree, overflow is strictly tied to box model of CSS which doesn't exist in SVG
07:04:17 [krit]
nzimmermann: Suggest to test and remove any mention of scrollbar b ehavior in SVG
07:04:35 [krit]
krit: so is the issue only about scrollbar or visible and hidden?
07:04:59 [krit]
dmangal: hidden is not defined for inner SVG elements and I don't want to introduce it
07:06:20 [krit]
krit: do we even want overlflow to apply on any SVG elements that is not the outer SVG element?
07:06:26 [krit]
nzimmermann: there are tests in 1.1
07:06:48 [krit]
nzimmermann: overflow hidden is implemented. Just scroll isn't.
07:07:13 [krit]
dmangal: So instead of overscroll auto result in visible scroll, it should be visible or hidden?
07:07:16 [krit]
nzimmermann: Yes
07:07:28 [krit]
dmangal: then we need to define when to use the one or the other
07:08:07 [krit]
nzimmermann: Well, following the spec text and intention, auto would always mean visible for all SVG elements no being outer SVG element.
07:08:26 [krit]
nzimmermann: "for an object sepcifically support scrolling" is in the table
07:09:22 [krit]
nzimmermann: needs more testing though.
07:10:21 [virali]
virali has joined #svg
07:10:39 [krit]
ACTION: More detailed tests needed. Karl to work on tests but needs additional input from others like nzimmermann.
07:11:53 [krit]
topic: Remove SVGElementInstance (correspondingElement / correspondingUseElement
07:12:01 [krit]
https://github.com/w3c/svgwg/issues/1070

07:12:29 [krit]
karlcow: Initial title was not correct as it happens on SVGElementInstance elements
07:13:06 [krit]
karlcow: tried many permutations of tests and couldn't find any breaking scenarios.
07:14:25 [krit]
karlcow: ...at the beginning it looked like to affect correspondingElement / correspondingUseElement only. But then I tested more and then realized it was the attributes on mixings on use elements. I tested and didn't find any implementation in browsers.
07:14:38 [krit]
karlcow: internally it is used but not exposed to web
07:14:47 [dmangal]
dmangal has joined #svg
07:14:52 [krit]
nzimmermann: not anymore. Remvoed it
07:14:54 [dmangal]
present+
07:15:08 [krit]
nzimmermann: Core difference is the core interface
07:15:40 [nzimmermann]
nzimmermann has joined #svg
07:15:41 [nzimmermann]
https://www.w3.org/TR/SVG11/struct.html#InterfaceSVGElementInstance

07:16:01 [nzimmermann]
https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGElementInstance

07:16:18 [krit]
nzimmermann: In SVG 11, InterfaceSVGElementInstance was not a mixin.
07:16:21 [viralipurbey]
viralipurbey has joined #svg
07:16:55 [krit]
nzimmermann: there is a spec section abotu event handling. Internally it was implemented as something similar to shadow tree.
07:17:07 [krit]
nzimmermann: Mouse events would be dispatched to the instance of the element
07:17:28 [krit]
nzimmermann: so to figure out where the event was coming from, you needed to look at the use element
07:18:01 [krit]
nzimmermann: So you needed to ask to which element the event was dispatched to. This was due to the DOM elements being the only interface (no shadow tree)
07:18:15 [krit]
nzimmermann: this changed in sVG2 where it is not an event target anymore
07:18:41 [krit]
nzimmermann: Now we also talk about shadow trees. Now it might be legacy behavior
07:19:09 [krit]
nzimmermann: we need to check it with todays implementation. Is the actual element or instance getting dispatched
07:19:23 [krit]
dmangal: I think the cloned object gets the event and not the instance.
07:19:28 [krit]
dmangal: I need to check.
07:19:42 [krit]
krit: so we can't see it from karls tests?
07:19:56 [krit]
dmangal: we should have tests already. Looking for it...
07:20:20 [dmangal]
third_party/blink/web_tests/external/wpt/svg/struct/reftests/use-event-handler-no-loss-of-events.html
07:20:20 [nzimmermann]
https://bugs.webkit.org/show_bug.cgi?id=141108

07:20:30 [nzimmermann]
Here's the WebKit bug which removed dispatching events to SVGElementInstance
07:21:00 [dmangal]
https://wpt.fyi/results/svg/struct/reftests/use-event-handler-no-loss-of-events.html?label=master&label=experimental&aligned&q=use-event-handler-no-loss-of-events.html

07:21:34 [krit]
krit: bringing it back next week.
07:21:49 [krit]
ACTION: dmangal checks for tests to events on clone elements
07:22:48 [krit]
nzimmermann: IMO the behavior aligns with shadow treee now
07:23:36 [krit]
nzimmermann: in the link there is a green section which summarizes the intention
07:23:52 [krit]
nzimmermann: "instances are the actual SVG elements"
07:24:06 [krit]
nzimmermann: it is really only for backwards compatibility
07:25:10 [krit]
nzimmermann: so specification text doesn't add any value with shadow tree but is only there for backwards compatibility with exsiting scrips based on an implementation that doesn't support shadow tree
07:25:25 [krit]
karlcow: In the test I have done it is not exposed at all
07:25:51 [krit]
nzimmermann: it is a mixin. So you can't see it as a type. This is due to the fact of using mixins but should still be available
07:26:25 [krit]
karlcow: so you would see events on corresponding elements
07:26:37 [krit]
nzimmermann: I guess so. That is the part we need to test.
07:27:06 [krit]
karlcow: I did test that and no browser responded.
07:27:30 [krit]
nzimmermann: yes, you are right. We removed it in WebKit. Likely by mistake and it likely broke content.
07:28:06 [krit]
nzimmermann: maybe we don't care about old scripts but then we should remove this entirely and drop the entire section. WebKit apparently has done that already
07:29:07 [krit]
karlcow: it is not WebKit only but all browsers.
07:29:29 [krit]
krit: so if we don't have implementations anymore, the text seems obsolet
07:30:00 [krit]
karlcow: this has been disappeared a long time ago (by accident or not) but we didn't hear complains either
07:30:27 [krit]
karlcow: IMO it is save to remove from spec and there are no implementations anymore anyway (if it ever was implemented)
07:30:44 [krit]
dmangal: from tests it seems save to remove.
07:31:05 [krit]
dmangal: We need to see from web compat issue. Which needs more testing.
07:31:37 [krit]
nzimmermann: It has been dropped 2014 and Chrome had usage counter. Back then FF didn't have any support
07:31:48 [nzimmermann]
https://issues.chromium.org/issues/40339216

07:31:56 [krit]
nzimmermann: so it hasn't been supported for the past decade.
07:32:20 [krit]
karlcow: I was looking on SVG documents on GitHub and couln't find any public instances.
07:33:09 [krit]
RESOLUTION: Remove SVGElementInstance from SVG2
07:33:22 [krit]
ACTION: karlcow to update WPT
07:34:25 [krit]
RRSAgent: make minutes
07:34:26 [RRSAgent]
I have made the request to generate https://www.w3.org/2026/03/19-svg-minutes.html krit
07:34:48 [krit]
RRSAgent, make logs public

Attachments

Received on Thursday, 19 March 2026 07:52:21 UTC