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

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[herrernst]

Attachment: 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

Comment 1

[herrernst]

Same with scrollWidth and scrollHeight as in bug 804201

Comment 2

[Robert Longson [:longsonr]]

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

[Robert Longson [:longsonr]]

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.

Comment 4

[herrernst]

> 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

[Robert Longson [:longsonr]]

So you're just asking for it to be non-zero on the outermost <svg> element when embedded in html.

Comment 6

[herrernst]

(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).

Comment 8

[Jan Tošovský]

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

[Jan Tošovský]

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

[Jon Rimmer]

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

[Robert Longson [:longsonr]]

Why can't you use getBoundingClientRect?

Comment 12

[Jon Rimmer]

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

Thanks for you help.

Comment 13

[u554698]

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

Comment 14

[RustyX]

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

Comment 15

[pie.or.paj]

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.

Comment 16

[Tom S [:evilpie]]

Just saw this mentioned on reddit: https://www.reddit.com/r/dataisbeautiful/comments/9yg8w9/googles_autocomplete_visualized_like_a_graph_link/ea1c557/

Comment 17

[ulima.ums]

This bug is still not fixed. It doesnt even has the status "CONFIRMED". Just put

<svg width="200" height="400"></svg>

in a html document and call clientHeight on it. Its zero. That sucks.
Can please someone look into this?

Comment 18

[violet.bugreport]

Attachment: Bug 874811 - Should support clientWidth for outer SVG

Outer <svg> uses CSS layout, we should support clientWidth,
clientTop, etc. for it.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 874811 - Outer svg is a replaced box with CSS layout, and CSSOM should reflect that accordingly. r=dholbert!,violet!

Co-authored-by: violet <[e-mail]>

Comment 20

[Pulsebot]

Pushed by [e-mail]:
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

Comment 21

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/81021da13bce

Comment 22

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16515 for changes under testing/web-platform/tests

Comment 23

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged