1350755 - getBoundingClientRect/getClientRects involving inner-<svg> inconsistent with Chrome and with the specs

Status: NEW

(Core :: SVG, enhancement, P3)

Description

[Jonathan Watt [:jwatt]]

Attachment: testcase - in the devtools Console run: document.querySelectorAll('svg')[1].getBoundingClientRect()

Our implementation of getBoundingClientRect/getClientRects on SVG elements, specifically inner-<svg> or elements containing an inner-<svg>, is inconsistent with Chrome and with the specs. Bug 530985 was supposed to have made us consistent with both but it looks like it either didn't, or else that's no longer the case.

The relevant spec sections are:

  https://www.w3.org/TR/cssom-view-1/#ref-for-svg-layout-box-3

which says that for SVG elements the bounds is the bounds as defined by SVG, and the relevant section of the SVG spec is:

  https://svgwg.org/svg2-draft/coords.html#ContainerElementBoudingBoxComputation

which essentially says that the x/y/width/height of inner-<svg> plays no part in the bounds calculation, the bounds being the bounds of the element's descendants only.

Currently what we do is we include the x/y/width/height of the inner-<svg> and then, if the inner-<svg> does not clip its contents, we union in the bounds of the descendants.

Chrome seems to conform to the behavior defined by the current specs when getBoundingClientRect/getClientRects are called on inner-<svg> in an SVG document. There seems to be a bug when the exact same SVG is placed inline in HTML though, which causes the width/height of the result to be zero.

It would be good to test other implementations.

Given the lack of interoperability here, we should also consider whether we can clip the results from inner-<svg> to the bounds of the viewport it establishes if it visually clips. (Could we do that for getBBox too?) That would seem to be desirable from an authors perspective, but requires a spec update.

Comment 1

[Robert Longson [:longsonr]]

We used to do it that way. Chrome didn't. We changed to match chrome after getting many bug reports. Now Chrome has changed and potentially the spec too and we should change back again?

See bug 530985 and https://bugs.chromium.org/p/chromium/issues/detail?id=914324 (now it's Chrome getting the bug reports).

Comment 2

[Robert Longson [:longsonr]]

I think we should wontfix this and get the spec changed back.