The default bug view has changed. See this FAQ.

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

UNCONFIRMED
Unassigned

Status

()

Core
SVG
UNCONFIRMED
4 years ago
a year ago

People

(Reporter: herrernst, Unassigned)

Tracking

21 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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 [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
(Reporter)

Updated

4 years ago
Attachment #752639 - Attachment mime type: text/plain → text/html

Updated

4 years ago
Component: General → SVG
Product: Firefox → Core
(Reporter)

Comment 1

4 years ago
Same with scrollWidth and scrollHeight as in bug 804201

Comment 2

4 years ago
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.

Comment 3

4 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

4 years ago
> 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).

Comment 5

4 years ago
So you're just asking for it to be non-zero on the outermost <svg> element when embedded in html.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Updated

4 years ago
Summary: clientWidth and clientHeight on svg elements are always 0 → clientWidth and clientHeight on outermost <svg> elements are always 0
(Reporter)

Comment 6

4 years ago
(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).

Updated

3 years ago
Duplicate of this bug: 958273

Comment 8

3 years ago
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.

Comment 9

3 years ago
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?

Comment 10

2 years ago
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.

Comment 11

2 years ago
Why can't you use getBoundingClientRect?

Comment 12

2 years ago
Aha! I can. I didn't think to check. I figured the dimensions were just broken. Silly me.

Thanks for you help.

Comment 13

a year ago
Why the status is UNCONFIRMED since it's definitly a bug ?

Comment 14

a year ago
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
You need to log in before you can comment on or make changes to this bug.