Meeting minutes
Overflow property behavior / spec on SVG element doesn't match reality.
karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox
karlcow: Emilio raised the issue 2 weeks ago. Chrome and Webkit have a different behavior from Firefox
karlcow: Depending how SVG elements are nested, the behavior of style overflow for auto on inner SVG elements, the elements get visible.
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.
dmangal: I have a different view
dmangal: in the spec it says on the document level, auto can result in visible or scroll.
dmangal: So there can be 2 operations.
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.
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.
nzimmermann: So bounding box of the element matters. It is not intrinsic.
<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
<karlcow> he value auto must be treated as visible
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.
nzimmermann: ..."all elements must be visible"
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.
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
nzimmermann: So any overflow behavior for auto other than clip would mean recomputing layout of all children.
<dmangal> <!doctype html>
<dmangal> <svg style="overflow: auto" height="90px" width="90px">
<dmangal> <!--<svg style="overflow: visible" height="90px" width="90px" x="0" y="0">-->
<dmangal> <rect id="overflows" height="100px" width="100px" fill="red" x="-5px" y="-5px" />
<dmangal> <rect height="90px" width="90px" fill="green" />
<dmangal> <!--</svg>-->
<dmangal> </svg>
<dmangal> <br>
<dmangal> <br>
<dmangal> <svg style="overflow: visible" height="90px" width="90px">
<dmangal> <!--<svg style="overflow: auto" height="90px" width="90px" x="0" y="0">-->
<dmangal> <rect id="overflows" height="100px" width="100px" fill="red" x="-5px" y="-5px" />
<dmangal> <rect height="90px" width="90px" fill="green" />
<dmangal> <!--</svg>-->
<dmangal> </svg>
dmangal: not sure of Blinks solution but I get the same behavior in Chrome and Firefox.
dmangal: For the 2nd SVG, Blink and Webkit are resolving the content to visible.
dmangal: The example above and the example in the issue should prouce the same output. Let me know if you see it differently
nzimmermann: not following. 2nd exampole: If we change auto to hidden, then it looks like 1st example.
nzimmermann: if you go to visible, you see the red border
nzimmermann: so following the spec, (auto should either be visible or scroll), wouldn't we need a scrollbar? Otherwise it would be clipped.
nzimmermann: The spec seems to apply this behavior and no browser applies
nzimmermann: WebKit never shows scrollbars on SVGs.
dmangal: So we should always compute to visible?
nzimmermann: not sure
nzimmermann: The behavior in Wbekit the behavior is coming from the box model behavior of CSS.
nzimmermann: I imagine no browser actually supports overlow visible behavior in any browser
dmangal: even FF has hidden behavior
nzimmermann: don't get scroll for any SVG element in none browser but I did not test
dmangal: do we need this in SVG? There is no box model. We don't have a spec for this.
nzimmermann: Agree, overflow is strictly tied to box model of CSS which doesn't exist in SVG
nzimmermann: Suggest to test and remove any mention of scrollbar b ehavior in SVG
krit: so is the issue only about scrollbar or visible and hidden?
dmangal: hidden is not defined for inner SVG elements and I don't want to introduce it
krit: do we even want overlflow to apply on any SVG elements that is not the outer SVG element?
nzimmermann: there are tests in 1.1
nzimmermann: overflow hidden is implemented. Just scroll isn't.
dmangal: So instead of overscroll auto result in visible scroll, it should be visible or hidden?
nzimmermann: Yes
dmangal: then we need to define when to use the one or the other
nzimmermann: Well, following the spec text and intention, auto would always mean visible for all SVG elements no being outer SVG element.
nzimmermann: "for an object sepcifically support scrolling" is in the table
nzimmermann: needs more testing though.
ACTION: More detailed tests needed. Karl to work on tests but needs additional input from others like nzimmermann.
Remove SVGElementInstance (correspondingElement / correspondingUseElement
karlcow: Initial title was not correct as it happens on SVGElementInstance elements
karlcow: tried many permutations of tests and couldn't find any breaking scenarios.
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.
karlcow: internally it is used but not exposed to web
nzimmermann: not anymore. Remvoed it
nzimmermann: Core difference is the core interface
<nzimmermann> https://
<nzimmermann> https://
nzimmermann: In SVG 11, InterfaceSVGElementInstance was not a mixin.
nzimmermann: there is a spec section abotu event handling. Internally it was implemented as something similar to shadow tree.
nzimmermann: Mouse events would be dispatched to the instance of the element
nzimmermann: so to figure out where the event was coming from, you needed to look at the use element
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)
nzimmermann: this changed in sVG2 where it is not an event target anymore
nzimmermann: Now we also talk about shadow trees. Now it might be legacy behavior
nzimmermann: we need to check it with todays implementation. Is the actual element or instance getting dispatched
dmangal: I think the cloned object gets the event and not the instance.
dmangal: I need to check.
krit: so we can't see it from karls tests?
dmangal: we should have tests already. Looking for it...
<dmangal> third_party/blink/web_tests/external/wpt/svg/struct/reftests/use-event-handler-no-loss-of-events.html
<nzimmermann> https://
<nzimmermann> Here's the WebKit bug which removed dispatching events to SVGElementInstance
krit: bringing it back next week.
ACTION: dmangal checks for tests to events on clone elements
nzimmermann: IMO the behavior aligns with shadow treee now
nzimmermann: in the link there is a green section which summarizes the intention
nzimmermann: "instances are the actual SVG elements"
nzimmermann: it is really only for backwards compatibility
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
karlcow: In the test I have done it is not exposed at all
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
karlcow: so you would see events on corresponding elements
nzimmermann: I guess so. That is the part we need to test.
karlcow: I did test that and no browser responded.
nzimmermann: yes, you are right. We removed it in WebKit. Likely by mistake and it likely broke content.
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
karlcow: it is not WebKit only but all browsers.
krit: so if we don't have implementations anymore, the text seems obsolet
karlcow: this has been disappeared a long time ago (by accident or not) but we didn't hear complains either
karlcow: IMO it is save to remove from spec and there are no implementations anymore anyway (if it ever was implemented)
dmangal: from tests it seems save to remove.
dmangal: We need to see from web compat issue. Which needs more testing.
nzimmermann: It has been dropped 2014 and Chrome had usage counter. Back then FF didn't have any support
<nzimmermann> https://
nzimmermann: so it hasn't been supported for the past decade.
karlcow: I was looking on SVG documents on GitHub and couln't find any public instances.
RESOLUTION: Remove SVGElementInstance from SVG2
ACTION: karlcow to update WPT
RRSAgent: make minutes