Closed Bug 552113 Opened 12 years ago Closed 12 years ago

offsetLeft / offsetTop on SVG elements

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: locki, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

the offsetLeft and offsetTop properties of SVG elements always returns 'undefined'. I've checked the same code in Opera and Chrome which both return values as expected.

Reproducible: Always
These don't seem to be valid properties of SVG elements. They are not mentioned in: http://www.w3.org/TR/SVG/attindex.html or http://www.w3.org/TR/SVG/propidx.html

I think this is invalid.
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Opera and Chrome returning something here is a unilateral extension of standard DOM behavior.  We have these properties on HTMLElement instances, but have no plans to implement them for SVG last I checked.  You should use getBoundingClientRect, which doesn't have the numerous issues offset* do and is well on its way to being standardized, instead.
Thanks. I'd just found getScreenCTM() in the SVG spec, but that doesn't seem to work on Opera. getBoundingClientRect() does what I require across the board however.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
getBoundingClientRect is sloooow though.
If you have a testcase where getBoundingClientRect is slower than something that you think gives you equivalent information, please file a bug with that testcase attached and cc me.
That page shows getBoundingClientRect being faster than "fullOffset" in every single UA that's been tried on the page, no?  Keep in mind that jsperf measures number of operations per second, so bigger bar means faster.
oh, this one had different results: http://jsperf.com/offset-vs-getboundingclientrect/8

but also both don’t use SVGs. and I think it’s difficult to say that a JS function being faster means that it needs improved performance.

i just discovered while profiling my React.js application that *this* is the bottleneck of a huge recalculation of many DOM elements…
> oh, this one had different results: http://jsperf.com/offset-vs-getboundingclientrect/8

That's because it's throwing a bunch of expensive stuff like pageYOffset and scrollTop into the mix only in the getBoundingclientRect case.

> i just discovered while profiling my React.js application

Please see comment 5.  New bug, attach the testcase.
You need to log in before you can comment on or make changes to this bug.