Re: [svgwg] getBBox algorithm doesn't factor in child transforms (#673)

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: getBBox algorithm doesn't factor in child transforms<br>
&lt;krit> GitHub: https://github.com/w3c/svgwg/issues/673<br>
&lt;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.<br>
&lt;krit> AmeliaBR: we got consensus and consistency. But then RobertL brought up elements with inner and outer coordinate system<br>
&lt;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?)<br>
&lt;krit> AmeliaBR: we do not have consistency between browsers all the time. But looked at the current state for all browsers in all cases.<br>
&lt;krit> Tav: what is most useful?<br>
&lt;krit> AmeliaBR: giving users the choice.<br>
&lt;krit> AmeliaBR: There are situations where you want the box of its cumulated child boxes.<br>
&lt;krit> AmeliaBR: But shape within a parents context might give you inconsistent numbers.<br>
&lt;krit> AmeliaBR: did you see some level of consistency?<br>
&lt;krit> s/AmeliaBR/krit/<br>
&lt;krit> AmeliaBR: Every UA is consistent how child transforms affect parents bounding box.<br>
&lt;krit> AmeliaBR: Need to test how things work with nested SVGs or even the root SVG.<br>
&lt;krit> krit: Can we split the issue?<br>
&lt;krit> AmeliaBR: maybe we should open a separate issue.<br>
&lt;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.<br>
&lt;krit> Tav: would be surprised otherwise.<br>
&lt;krit> AmeliaBR: We have the detailed algorithm for SVG2 but we forgot the point described above.<br>
&lt;krit> AmeliaBR: I can take responsibility for the edits if we agree.<br>
&lt;krit> AmeliaBR: If someone has time to look at nested SVGs that would be great.<br>
&lt;krit> krit: To be clear: nested SVGs means inner SVG?<br>
&lt;krit> AmeliaBR: all elements that have an inner and outer coordinate system like all elements with a viewBox.<br>
&lt;krit> krit: makes sense to spec transforms on children<br>
&lt;krit> AmeliaBR: algo doesn't mention that coordinate systems change when going from inner to outer at all currently.<br>
&lt;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?<br>
&lt;chris> I can help on that but not this week undortunately<br>
&lt;krit> AmeliaBR: there is the part to figure out what should be spiced and the part about writing conformance tests.<br>
&lt;krit> krit: Can not commit to it but try to look at nesting as well.<br>
&lt;krit> AmeliaBR: Simon also brought up affect of 3D transforms on bounding box<br>
&lt;krit> AmeliaBR: we should figure the 2D part out first.<br>
&lt;krit> proposed RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.<br>
&lt;krit> RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.<br>
&lt;chris> sgtm<br>
&lt;krit> s/bounding box./bounding box. Additional resolutions for rotation may follow./<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/673#issuecomment-494138470 using your GitHub account

Received on Monday, 20 May 2019 20:27:56 UTC