1106751 - getBBox method doesn't take into account transform

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Adrián Seijo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36

Steps to reproduce:

Go to http://jsfiddle.net/2wpju/7/ (from http://stackoverflow.com/questions/10623809/get-bounding-box-of-element-accounting-for-its-transform)


Actual results:

It shows two shapes, the circle with the right bbox, and the square with the bbox before  transform gets applied.


Expected results:

As per spec http://www.w3.org/TR/SVG/types.html#__svg__SVGLocatable__getBBox, getBBox should "Returns the tight bounding box in current user space (i.e., after application of the ‘transform’ attribute, if any)"

Comment 1

[Robert Longson [:longsonr]]

after the application of the transform means apply the transform to generate a new co-ordinate system and then get the bounding box in that co-ordinate system. Firefox, Opera 12 and Safari all interpret the text this way.

Comment 2

[Adrián Seijo]

First of all thanks for the quick reply!

I know that all the browsers behave more or less like this and I understand what you say about the co-ordinates and the interpretation of the text but I really think that is a weird behaviour. 

Form the perspective of the end user (a frontend developer) if you query the bounding box it tends to be to get the position in the svg that you saw in the screen not something related to the internal coordinate system. I understand that at implementation level you may have a different coordinate and that it makes sense to return that one but it feels to me like that is just exposing the end user to the implementation details.

Also this led me to a related issue present in both Safari and Chrome (Opera as well I guess since they use Blink):

- https://code.google.com/p/chromium/issues/detail?id=377665&q=getBBox&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
- https://bugs.webkit.org/show_bug.cgi?id=133301

Both of them point out that Firefox is actually getting the bounding box of a a node with a rotate transform after the transform is applied. That seems the right thing to me and I guess to Chrome and Safari too since they didn't close them (yet :D), but then that conflicts in how the browsers handle the transform. I guess that the explanation is that rotate doesn't change the co-ordinate system and thats why it does it right but again that looks very inconsistent and confusing for the end user since some transformations are taken into account for bounding box and others don't...

Comment 3

[Robert Longson [:longsonr]]

I suggest you take this up with the w3c svg working group if you want a more flexible bounding box perhaps they could define an optional argument that changed how it worked if you supplied it.

Reporting webkit bugs here won't get you very far ;-)