06:46:18 RRSAgent has joined #svg 06:46:22 logging to https://www.w3.org/2026/03/19-svg-irc 06:46:31 present+ 06:46:53 present+ 06:47:20 viralipurbey has joined #svg 06:47:31 topic: Overflow property behavior / spec on SVG element doesn't match reality. 06:47:34 present+ 06:47:42 present+ 06:47:46 https://github.com/w3c/svgwg/issues/1072 06:48:26 karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox 06:48:52 scribe: krit 06:49:09 karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox 06:49:58 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 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 dmangal: I have a different view 06:51:44 dmangal: in the spec it says on the document level, auto can result in visible or scroll. 06:51:50 dmangal: So there can be 2 operations. 06:51:52 Meeting: SVG WG Meeting - March 19, 2026 06:52:58 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 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 nzimmermann: So bounding box of the element matters. It is not intrinsic. 06:54:09 > 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 he value auto must be treated as visible 06:54:46 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 https://w3c.github.io/svgwg/svg2-draft/render.html#:~:text=content%20is%20clipped.-,Within%20SVG%20content,-%2C%20the%20value%20auto 06:55:02 nzimmermann: ..."all elements must be visible" 06:56:17 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 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 nzimmermann: So any overflow behavior for auto other than clip would mean recomputing layout of all children. 06:58:07 06:58:07 06:58:10
06:58:10
06:58:10 06:58:17 dmangal: not sure of Blinks solution but I get the same behavior in Chrome and Firefox. 06:58:46 dmangal: For the 2nd SVG, Blink and Webkit are resolving the content to visible. 06:59:17 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 nzimmermann: not following. 2nd exampole: If we change auto to hidden, then it looks like 1st example. 06:59:55 nzimmermann: if you go to visible, you see the red border 07:00:26 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 nzimmermann: The spec seems to apply this behavior and no browser applies 07:00:55 nzimmermann: WebKit never shows scrollbars on SVGs. 07:01:06 dmangal: So we should always compute to visible? 07:01:09 nzimmermann: not sure 07:01:55 nzimmermann: The behavior in Wbekit the behavior is coming from the box model behavior of CSS. 07:02:15 nzimmermann: I imagine no browser actually supports overlow visible behavior in any browser 07:02:26 dmangal: even FF has hidden behavior 07:03:17 nzimmermann: don't get scroll for any SVG element in none browser but I did not test 07:03:34 dmangal: do we need this in SVG? There is no box model. We don't have a spec for this. 07:04:02 nzimmermann: Agree, overflow is strictly tied to box model of CSS which doesn't exist in SVG 07:04:17 nzimmermann: Suggest to test and remove any mention of scrollbar b ehavior in SVG 07:04:35 krit: so is the issue only about scrollbar or visible and hidden? 07:04:59 dmangal: hidden is not defined for inner SVG elements and I don't want to introduce it 07:06:20 krit: do we even want overlflow to apply on any SVG elements that is not the outer SVG element? 07:06:26 nzimmermann: there are tests in 1.1 07:06:48 nzimmermann: overflow hidden is implemented. Just scroll isn't. 07:07:13 dmangal: So instead of overscroll auto result in visible scroll, it should be visible or hidden? 07:07:16 nzimmermann: Yes 07:07:28 dmangal: then we need to define when to use the one or the other 07:08:07 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 nzimmermann: "for an object sepcifically support scrolling" is in the table 07:09:22 nzimmermann: needs more testing though. 07:10:21 virali has joined #svg 07:10:39 ACTION: More detailed tests needed. Karl to work on tests but needs additional input from others like nzimmermann. 07:11:53 topic: Remove SVGElementInstance (correspondingElement / correspondingUseElement 07:12:01 https://github.com/w3c/svgwg/issues/1070 07:12:29 karlcow: Initial title was not correct as it happens on SVGElementInstance elements 07:13:06 karlcow: tried many permutations of tests and couldn't find any breaking scenarios. 07:14:25 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 karlcow: internally it is used but not exposed to web 07:14:47 dmangal has joined #svg 07:14:52 nzimmermann: not anymore. Remvoed it 07:14:54 present+ 07:15:08 nzimmermann: Core difference is the core interface 07:15:40 nzimmermann has joined #svg 07:15:41 https://www.w3.org/TR/SVG11/struct.html#InterfaceSVGElementInstance 07:16:01 https://www.w3.org/TR/SVG2/struct.html#InterfaceSVGElementInstance 07:16:18 nzimmermann: In SVG 11, InterfaceSVGElementInstance was not a mixin. 07:16:21 viralipurbey has joined #svg 07:16:55 nzimmermann: there is a spec section abotu event handling. Internally it was implemented as something similar to shadow tree. 07:17:07 nzimmermann: Mouse events would be dispatched to the instance of the element 07:17:28 nzimmermann: so to figure out where the event was coming from, you needed to look at the use element 07:18:01 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 nzimmermann: this changed in sVG2 where it is not an event target anymore 07:18:41 nzimmermann: Now we also talk about shadow trees. Now it might be legacy behavior 07:19:09 nzimmermann: we need to check it with todays implementation. Is the actual element or instance getting dispatched 07:19:23 dmangal: I think the cloned object gets the event and not the instance. 07:19:28 dmangal: I need to check. 07:19:42 krit: so we can't see it from karls tests? 07:19:56 dmangal: we should have tests already. Looking for it... 07:20:20 third_party/blink/web_tests/external/wpt/svg/struct/reftests/use-event-handler-no-loss-of-events.html 07:20:20 https://bugs.webkit.org/show_bug.cgi?id=141108 07:20:30 Here's the WebKit bug which removed dispatching events to SVGElementInstance 07:21:00 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: bringing it back next week. 07:21:49 ACTION: dmangal checks for tests to events on clone elements 07:22:48 nzimmermann: IMO the behavior aligns with shadow treee now 07:23:36 nzimmermann: in the link there is a green section which summarizes the intention 07:23:52 nzimmermann: "instances are the actual SVG elements" 07:24:06 nzimmermann: it is really only for backwards compatibility 07:25:10 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 karlcow: In the test I have done it is not exposed at all 07:25:51 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 karlcow: so you would see events on corresponding elements 07:26:37 nzimmermann: I guess so. That is the part we need to test. 07:27:06 karlcow: I did test that and no browser responded. 07:27:30 nzimmermann: yes, you are right. We removed it in WebKit. Likely by mistake and it likely broke content. 07:28:06 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 karlcow: it is not WebKit only but all browsers. 07:29:29 krit: so if we don't have implementations anymore, the text seems obsolet 07:30:00 karlcow: this has been disappeared a long time ago (by accident or not) but we didn't hear complains either 07:30:27 karlcow: IMO it is save to remove from spec and there are no implementations anymore anyway (if it ever was implemented) 07:30:44 dmangal: from tests it seems save to remove. 07:31:05 dmangal: We need to see from web compat issue. Which needs more testing. 07:31:37 nzimmermann: It has been dropped 2014 and Chrome had usage counter. Back then FF didn't have any support 07:31:48 https://issues.chromium.org/issues/40339216 07:31:56 nzimmermann: so it hasn't been supported for the past decade. 07:32:20 karlcow: I was looking on SVG documents on GitHub and couln't find any public instances. 07:33:09 RESOLUTION: Remove SVGElementInstance from SVG2 07:33:22 ACTION: karlcow to update WPT 07:34:25 RRSAgent: make minutes 07:34:26 I have made the request to generate https://www.w3.org/2026/03/19-svg-minutes.html krit 07:34:48 RRSAgent, make logs public 09:02:46 botie has joined #svg 12:30:15 Zakim has left #svg 13:46:19 slightlyoff has joined #svg 13:46:19 emilio has joined #svg 13:51:29 slightlyoff has joined #svg 13:51:29 emilio has joined #svg 15:01:26 slightlyoff has joined #svg 15:01:26 emilio has joined #svg 15:02:48 ntim has joined #svg 15:02:48 slightlyoff has joined #svg 15:02:48 emilio has joined #svg 15:12:27 ntim has joined #svg 15:12:27 slightlyoff has joined #svg 15:12:27 emilio has joined #svg