Created attachment 752639 [details] test case comparing img and svg elements For inline SVG elements in HTML5, the DOM properties clientWidth and clientHeight are always zero. This breaks some librarys and makes getting the size of an svg element difficult. As per the CSSOM View Module, the client* properties are extension to the Element interface , so they should be also supported for SVG elements (in contrast to the offset* properties, which are extensions to the HTMLElement interface, also see discussion for bug 649285). Every other major browser I have tested supports the client* properties (IE9, IE10, Chrome (26), Opera (12.14), Safari (6.0.4)). It would be great if Firefox would also support them.  http://www.w3.org/TR/cssom-view/#extensions-to-the-element-interface
Same with scrollWidth and scrollHeight as in bug 804201
scrollWidth and scrollHeight return 0 per the cssom specification for the reasons given in that bug. Let's try to stick to one topic per bug please.
SVG elements don't have a CSS layout box (except for the outer <svg> element when it is embedded inline in html). Then per http://www.w3.org/TR/cssom-view/#extensions-to-the-element-interface The clientTop, clientLeft, clientWidth, and clientHeight attributes must return zero if the element does not have any associated CSS layout box So we're doing the right thing per the specification here. Get the specification changed and we'll likely implement it, providing it say something sensible.
> SVG elements don't have a CSS layout box (except for the outer <svg> element > when it is embedded inline in html). But that's exactly the case here (the outermost SVG element embedded in HTML).
So you're just asking for it to be non-zero on the outermost <svg> element when embedded in html.
(In reply to Robert Longson from comment #5) > So you're just asking for it to be non-zero on the outermost <svg> element > when embedded in html. Yes, exactly (sorry about the confusion, when I wrote "svg element", I meant the <svg> element).
I am observing another client size weirdness (tested on http://drifted.in/other/wheel.svg - drag and rotate that green wheel, the client size is displayed on mouse release): 1. The client size of standalone SVGs returns dimensions of the page (not SVG) content. 2. When the same SVG file is viewed from a local drive, the client size is 0 x 0px. ad 1) same in Chrome. IE returns the exact SVG size which is IMHO the only sensible approach. ad 2) both Chrome and IE return the same dimension as when viewed from the web.
Finally I am about to release my new SVG based web app and this incorrect returning of client coords is quite serious issue for me. With deep sorrow I have to mark FF as unsupported browser :-( Are client coords considered as non-standard ones and hence handled with lower priority?
I am also working on an app using SVG, and I cannot believe this bug exists. Some bugs I can understand, but a basic function of the DOM just not working *at all* for an important element like SVG? An Mozilla appears to have no interest in fixing it? When an SVG is being used as a drawing surface in a context where its size can change, such as on a responsive site, or within a flex container, it is vital to be able to determine its size in order to lay out its contents properly.
Why can't you use getBoundingClientRect?
Aha! I can. I didn't think to check. I figured the dimensions were just broken. Silly me. Thanks for you help.
Why the status is UNCONFIRMED since it's definitly a bug ?
This also applies to SVG embedded via EMBED, OBJECT and IFRAME. All dimensions, clientWidth/Height and scrollWidth/Height are always 0. Demo: http://rustyx.org/temp/test-svg-object.html http://rustyx.org/temp/test-svg-iframe.html