I have a potentially large yet rather simple
<svg> document inside my page. It contains the graphical elements of my web app.
height are currently as big as the visible portion of the app. I'm using the
viewBox property to handle scrolling, through the
min-y values. Most importantly, I'm using
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
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.