0

I have a potentially large yet rather simple <svg> document inside my page. It contains the graphical elements of my web app.

Its width and height are currently as big as the visible portion of the app. I'm using the viewBox property to handle scrolling, through the min-x and min-y values. Most importantly, I'm using viewBox's width and height values to elegantly scale up its graphic elements in one go. There is a demo as well as a complete guide about the topic.

The problem is that this causes floating point math problems that I'm not very capable of dealing with.

SVG isn’t (just) an image. SVG is a document – Amelia Bellamy-Royds

It seems as though <svg> is like <iframe> or the very html document: they can be huge, but the browser takes care of automatically rendering just their visible portions.

Furthermore, if you inspect its elements, it shows the bounding client rectangle 'overflowing' the <svg> document.

SVG <code><path></code> element overflowing its parent <code><svg></code>

I'm not sure what this implies. However, it seems like the browser makes no difference, in terms of performance, between to equally complex <svg>, one being huge and one being small with a viewBox property that blows up its contents. Am I correct in my assumption?

In that case, despite loving the elegance of scaling everything up with one attribute, I would be willing to give that up in order to avoid dealing with the floating point math problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.