Closed Bug 874811 Opened 9 years ago Closed 3 years ago
Width and client Height on outermost <svg> elements are always 0
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
Attachment #752639 - Attachment mime type: text/plain → text/html
Summary: clientWidth and clientHeight on svg elements are always 0 → clientWidth and clientHeight on outermost <svg> elements are always 0
(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?
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
The previous suggested workaround of using getBoundingClientRect does not work as it behaves differently when css transforms are applied. In fact I need to use both the client* properties and getBoundingClientRect to calculate which transforms are in effect.
Just saw this mentioned on reddit: https://www.reddit.com/r/dataisbeautiful/comments/9yg8w9/googles_autocomplete_visualized_like_a_graph_link/ea1c557/
Assignee: nobody → violet.bugreport
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/81021da13bce Outer svg is a replaced box with CSS layout, and CSSOM should reflect that accordingly. r=dholbert,violet
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16515 for changes under testing/web-platform/tests
Upstream PR merged
You need to log in before you can comment on or make changes to this bug.