$svg.width() and $svg.height() return zero

[JohannesRudolph]

Sometimes the $svg.width() and $svg.width() calls return 0, even though we explicitly set width and height of the element before creating it. I cannot figure out whether this is a bug in jquery or mobile safari (iOS 7.1). In any case, I cannot reproduce it outside of my current project. The fix is simple and probably safe though, so I thought I'd upstream it:

diff --git a/RowingInMotion.Analytics/app/lib/peity/jquery.peity.js b/RowingInMotion.Analytics/app/lib/peity/jquery.peity.js
--- a/RowingInMotion.Analytics/app/lib/peity/jquery.peity.js
+++ b/RowingInMotion.Analytics/app/lib/peity/jquery.peity.js
@@ -135,16 +135,13 @@
               values = [0, 1]
           }

-          var diameter = opts.radius * 2
+          var diameter = opts.radius * 2,
+              width = opts.width || diameter,
+              height = opts.height || diameter

-          var $svg = this.prepare(
-            opts.width || diameter,
-            opts.height || diameter
-          )
+          var $svg = this.prepare(width, height)

-          var width = $svg.width()
-            , height = $svg.height()
-            , cx = width / 2
+          var cx = width / 2
             , cy = height / 2

           var radius = Math.min(cx, cy)

[benpickles]

Interesting, the reason I read back the dimensions after manually setting them is to cater for percentage dimensions - so you can specify { width: '100%' } and it'll return the SVG element's dimensions in pixels - and it looks like that patch would break that functionality.

I did previously discover that jQuery doesn't return the dimensions of an SVG element when they're defined as a percentage (I can't quite remember the detail as it was a while ago), could this be the cause?

[JohannesRudolph]

Hm... my definitions use pixels. I wasn't aware that peity also supported %
dimensions. Getting the width/height of an svg element accurately seems to
be non-straightforward. Can you think of an easy way to reconcile this?
(E.g. we could check if the width and height returned was zero and then use
the user defined option if it's in pixels). This is a PITA.

On Mon, May 18, 2015 at 12:34 PM, Ben Pickles [email protected]
wrote:

Interesting, the reason I read back the dimensions after manually setting
them is to cater for percentage dimensions - so you can specify { width:
'100%' } and it'll return the SVG element's dimensions in pixels - and it
looks like that patch would break that functionality.

I did previously discover that jQuery doesn't return the dimensions of an
SVG element when they're defined as a percentage (I can't quite remember
the detail as it was a while ago), could this be the cause?

—
Reply to this email directly or view it on GitHub
#68 (comment).

[benpickles]

That sounds like a good solution (zero being falsy). It'd be nice to have a working test case though.

[Thaars]

I've got the same error while generating bar charts in an Ionic2 (Angular4) app. The thing is, in our web version of that project (Angular4), it works - with exactly the same versions of peity and jQuery. I've fixed it by using:

$svg.width() || opts.width
$svg.height() || opts.height

It works for now, but I don't exactly know, if there are any side effects under any circumstances. Could you verify and apply this fix to a next version please?

[benpickles]

Hmmm, I wonder if it's because the element hasn't yet been attached to the DOM? (Just thinking out loud...)

[Thaars]

I really don't know. Is it important to get the dimensions from the svg element? Could we simply get it from the options? Or is it needed for dynamic appending data?

[benpickles]

It was originally required in an old version that used <canvas>, the more I think about it the more I think there's probably a better way to do things in S(scalable!)VG.

[gypapp]

Hmmm, I wonder if it's because the element hasn't yet been attached to the DOM? (Just thinking out loud...)

At least in my case (#105) this must be the reason. I was trying to use peity within a DataTables table and their docs says:

This callback allows you to 'post process' each row after it have been generated for each table draw, but before it is rendered into the document. This means that the contents of the row might not have dimensions ($().width() for example) if it is not already in the document.