[resize-observer] Fragment-aware behavior for SVG?

[Loirooriol]

https://drafts.csswg.org/resize-observer-1/#calculate-box-size defines the size of SVG elements to be the bounding box, as defined in https://www.w3.org/TR/SVG2/coords.html#BoundingBoxes

The bounding box (or "bbox") of an element is the tightest fitting rectangle aligned with the axes of that element's user coordinate system that entirely encloses it and its descendants.

What if the SVG is fragmented? I have not been able to fragment a monolithic element using multicol, but I guess it happens in printing.

In that case it's just some graphical slicing, and I don't think the SVG coordinate system is aware of that, so I guess the ResizeObserver should notify of a single size (the size before slicing)?

But does it make sense for <img> and <svg> to behave different in this regard?

Alternatively, if the bounding box is calculated after the slicing, does it make sense to include page margins or whatever that separates the fragments? And do the pages appear one next to the other vertically or horizontally?

[Loirooriol]

OK, I had the impression that an outer <svg> generated a SVG box, but it's actually a CSS box, as explained in #4032.

So we have consistency between <img> and <svg>.

And then for inner SVG elements I guess we should use the size before slicing?

[css-meeting-bot]

The CSS Working Group just discussed [resize-observer] Fragment-aware behavior for SVG?, and agreed to the following:

• RESOLVED: if internal parts of an svg are sliced we will return size before slicing

The full IRC log of that discussion

<bramus> oriol: thi s about internal svg elems. the do not generate …-boxes, the generate svgboxes
<bramus> oriol: spec handles them specially and says their size should be the bounding box
<bramus> oriol: q is: what happpens if svg is fragmented? then we have different sizes in different places. some of the internal elems are sliced. should we report size before slicing or sth different?
<bramus> oriol: leaning to size before slicing
<bramus> oriol: the svg does not know it is fragmented
<emilio> +1
<bramus> oriol: maybe someone with more expertise has more info/details?
<bramus> astearns: so we say we handle svg and img in the same way when things get sliced?
<bramus> oriol: yes [missed] they don not follow css rules but do svg behaviors
<bramus> oriol: maybe we should just use the concept in svg and report a single fragment/size
<bramus> astearns: opinions?
<bramus> astearns: proposed resolution: if an svg or its internal parts are sliced we will return the size before slicing
<bramus> oriol: just for the internal parts
<astearns> ack dbaron
<fantasai> s/parts/parts; the outer SVG box should be treated same as img/
<bramus> dbaron: wondering if there should be a difference between an svg doc vs an outer svg elem tha tgets sliced
<bramus> dbaron: if its a doc it should behave as if it is not sliced
<bramus> astearns: reason for different behavior?
<fantasai> s/same as img/same as img and return its slices/
<bramus> dbaron: not specifically.
<bramus> dbaron: [missed]
<bramus> astearns: updated proposed resoltuion: if internal parts of an svg are sliced we will return size before slicing
<dbaron> s/[missed]/just that if we were to expose the slicing, I think it wouldn't make sense to do so for something that's its own document but is sliced by a containing document/
<bramus> astearns: objections
<bramus> RESOLVED: if internal parts of an svg are sliced we will return size before slicing
<bramus> s/objections/objections?/

[Loirooriol]

I didn't think about this beforehand, but nice, the resolution is consistent with getClientRects():

If the element has an associated SVG layout box return a DOMRectList object containing a single DOMRect object that describes the bounding box of the element as defined by the SVG specification