-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add getScreenBBox() method to SVGGraphicsElement interface #76
Comments
Or alternatively, perhaps, add a new property to
If |
This would be something like the below (modulo terrible indentation) using currently speced primitives? function getScreenBBox(element) { |
@foolip: In order to determine the geometric bbox of a path in the client space you can't just transform paths' user (local) bbox to the client space, this might produce wrong results when the path or its ancestors are transformed. Instead, you have to determine the coordinates of each path node point, then transform each point to the client space and finally use that to determine the bbox. Doing this in JS is very slow, I suspect browsers could make it much faster by querying the render tree. |
Ah, yes, I missed that part of the issue. Computing the "precise" bounding box in "screen-space" will be costly even if "querying the render tree" though - unless this happen to be stored already (it isn't in Blink for example. There's a cost associated with maintaining this kind of "absolute" state - if there weren't, gBCR et al would likely already return these tight fitting bboxes.) |
Yes, we already use the simplified approach in other cases when combining transforms and BBox calculations, precisely for the issue of computational complexity. Currently, if you compute the BBox of a rotated path, or of a This CodePen by Sarah Drasner demonstrates the effect clearly. Therefore, for compatibility, if a |
From my testing That gist is demonstrating the problem I was talking about earlier - you can't just take a bounding box in the user space and transform its coordinates to some other space - this will produce a bounding box of another bounding box which is not useful and wrong if you stick to the mathematical definition. Making BTW, In Blink (and probably WebKit) |
There is a very common request on Stack Overflow to get the bounds of an element including its own transform. IOW returning
So it would be good to consider this use case in any solution. So, using my previous suggestion, for example:
|
Having |
Blake/ OSUblake has a great writeup of this issue here: https://greensock.com/forums/topic/13681-svg-gotchas/?page=2&tab=comments#comment-72060 His codepen of a workaround is excellent! |
There is no way to determine the bounding box of an SVG element in the client space.
The generic
element.getBoundingClientRect()
method, unlikeelement.getBBox()
, does not allow you to specify whether to include stroke and markers in the result. It also does not return a geometric bbox, but rather a bbox of a user bbox that has been transformed to the client space, which is not what you would expect or want in most scenarios.I would propose to add
getScreenBBox()
method to theSVGGraphicsElement
interface. The method would take the same arguments as the existinggetBBox()
method. Note that "screen" in the method name would actually mean "client", for the sake of consistency withgetCTM()
/getScreenCTM()
.The text was updated successfully, but these errors were encountered: