getBBox algorithm doesn't factor in child transforms

[AmeliaBR]

spec

See discussion in w3c/csswg-drafts#907

There's still some confusion about how to handle 3D transforms on the child elements. But everyone is consistent (and SVG 1 prose seems to require) that transforms on the child element are converted to the parent coordinate system when calculating the parent's bounding box.

[longsonr]

What about this? https://bug1064151.bmoattachments.org/attachment.cgi?id=8487528 Firefox and Chrome disagree. Firefox treats <svg> and <rect> elements the same, Chrome does not.

[AmeliaBR]

Is that the test you intended to link? It's about getTransformToElement and getScreenCTM, rather than getBBox.

Either way it's an inconsistency that needs to be sorted out. And there are probably similar issues when finding the BBox of an <svg>: do you use the coordinate system it creates, or the parent coordinates?

[longsonr]

getBBox, getTransformToElement and getScreenCTM all kind of link in that they all need to answer the question, what's the co-ordinate system of the element? We use the co-ordinate system it creates, though we say that viewBox is a transform that applies to your children and not to you.

[css-meeting-bot]

The SVG Working Group just discussed getBBox algorithm doesn't factor in child transforms, and agreed to the following:

• RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.

The full IRC log of that discussion

<krit> topic: getBBox algorithm doesn't factor in child transforms
<krit> GitHub: https://github.com//issues/673
<krit> AmeliaBR: SVG2 has a detailed algorithm for bounding box which wasn't in SVG 1.1. BBox on groups with children will end up in parents coordinate space.
<krit> AmeliaBR: we got consensus and consistency. But then RobertL brought up elements with inner and outer coordinate system
<krit> AmeliaBR: So you define coords in the parent coordinate systems and the elements own viewbox. This is not clearly specified. That also affects transforms and cumulation of transformation systems (inner or outer coord system affected?)
<krit> AmeliaBR: we do not have consistency between browsers all the time. But looked at the current state for all browsers in all cases.
<krit> Tav: what is most useful?
<krit> AmeliaBR: giving users the choice.
<krit> AmeliaBR: There are situations where you want the box of its cumulated child boxes.
<krit> AmeliaBR: But shape within a parents context might give you inconsistent numbers.
<krit> AmeliaBR: did you see some level of consistency?
<krit> s/AmeliaBR/krit/
<krit> AmeliaBR: Every UA is consistent how child transforms affect parents bounding box.
<krit> AmeliaBR: Need to test how things work with nested SVGs or even the root SVG.
<krit> krit: Can we split the issue?
<krit> AmeliaBR: maybe we should open a separate issue.
<krit> AmeliaBR: Example: you got a group and the child (e.g. rect) element has a transform then this transform affects the group bounding box.
<krit> Tav: would be surprised otherwise.
<krit> AmeliaBR: We have the detailed algorithm for SVG2 but we forgot the point described above.
<krit> AmeliaBR: I can take responsibility for the edits if we agree.
<krit> AmeliaBR: If someone has time to look at nested SVGs that would be great.
<krit> krit: To be clear: nested SVGs means inner SVG?
<krit> AmeliaBR: all elements that have an inner and outer coordinate system like all elements with a viewBox.
<krit> krit: makes sense to spec transforms on children
<krit> AmeliaBR: algo doesn't mention that coordinate systems change when going from inner to outer at all currently.
<krit> krit: lets split the issue then and agree on the first part of the issue. Someone could work on tests for the 2nd issues?
<chris> I can help on that but not this week undortunately
<krit> AmeliaBR: there is the part to figure out what should be spiced and the part about writing conformance tests.
<krit> krit: Can not commit to it but try to look at nesting as well.
<krit> AmeliaBR: Simon also brought up affect of 3D transforms on bounding box
<krit> AmeliaBR: we should figure the 2D part out first.
<krit> proposed RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.
<krit> RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.
<chris> sgtm
<krit> s/bounding box./bounding box. Additional resolutions for rotation may follow./