Closed Bug 874811 Opened 9 years ago Closed 3 years ago

clientWidth and clientHeight on outermost <svg> elements are always 0

Categories

(Core :: SVG, defect)

21 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: herr.ernst, Assigned: emilio)

References

Details

Attachments

(2 files, 1 obsolete file)

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 [1], 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.

[1] http://www.w3.org/TR/cssom-view/#extensions-to-the-element-interface
Attachment #752639 - Attachment mime type: text/plain → text/html
Component: General → SVG
Product: Firefox → Core
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).
Duplicate of this bug: 958273
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.
Assignee: nobody → violet.bugreport
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9059710 - Attachment is obsolete: true
Assignee: violet.bugreport → emilio
Pushed by ealvarez@mozilla.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
Status: ASSIGNED → RESOLVED
Closed: 9 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16515 for changes under testing/web-platform/tests
You need to log in before you can comment on or make changes to this bug.