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

[benpickles]

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

[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]

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.

[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.