#10405 closed bug (wontfix)
offset() of SVG elements on mobile Safari not correct
Reported by: | asgeo1 | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | misc | Version: | 1.6.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I have found that in mobile safari, offset() always seems to return {left:0, top:0} on SVG elements, IF the svg document was loaded into the DOM via adoptNode.
Other browsers seem fine. I.e. Firefox, Chrome, desktop Safari, offset() returns the expected value.
I suspect that this is probably a bug in mobile Safari.
NOTE: the reason to load the SVG into the DOM via adoptNode, is because mobile Safari does not have great support for inline SVG. This is the same approach the jQuery SVG plugin uses.
I have attached a test case that demonstrates the issue.
Change History (5)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
FWIW, in the HTML5 mobile applications I'm writing, having this working is actually a big deal. Part of what I'm trying to do is overlay HTML elements (jQuery UI elements, or other HTML elements) on top of an inline SVG image.
Having offset() to calculate the correct screen location of the SVG elements is just so handy. I'm not sure how else to do this - you can't just take the CY or CX position of the circle (for example) as the SVG may have transformations (pan / zoom) applied.
comment:3 Changed 11 years ago by
Component: | unfiled → misc |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
Unfortunately, SVG issues are out of jQuery's scope, as we've noted in this public document: http://docs.jquery.com/Won't_Fix
comment:4 Changed 11 years ago by
Additionally, in the same StackOverflow post that you've already added to, I believe the answer was given here: http://stackoverflow.com/questions/4504942/mobile-safari-svg-problem/4628297#4628297
comment:5 Changed 11 years ago by
I did see that post on SO. I tried an XHTML doctype, but I still had the problem.
But I've just downloaded iOS 5 beta, and it seems to be working OK. So this should be fixed in the next release of mobile Safari, which is good enough for me.
Test Case: