Confused about SVG behavior on devices

Hi. So, I have two pages where I have an SVG area that has its various png elements animated via GSAP, and that all is working great… except that on an iPad and iTouch, I am having issues, and I’m not really clear why.

Basically, the animation (SVG area) is not showing up. It’s taking up space, yet is visually not there.

At first, I thought ‘Apple doesn’t support SVG, I guess…’, yet one of the two pages DOES work on the iPad, and both are using the same technique.

Meanwhile, on my (old) iTouch, neither of the SVG displays are displaying (but, again, are taking up space on the screen… pushing the other content down).

So, Apple seemingly does support it (as the CanIUse website also confirms), since it DOES work on at least one of the devices (iPad) for ONE of the two pages.

So, my second theory was that the javascript that does the animation (GSAP) was starting up before all the graphics were loaded… which IS a thing.

But, I actually have coding already in place to combat that, so unless it’s not working, that can’t be it either. But, the theory is still sound, since both the devices where the failure occurs were using WIFI… and most likely slow WIFI at that. So, I’m still thinking the ‘animation script starting before all the graphics are loading’ theory is possibly valid… despite having the code in already to tell the browser to wait until the page is fully loaded before triggering the animation scripting.

I tried various other tests, but still am puzzled. It SEEMS like the SVG graphics themselves are not displaying at all, regardless of the animation that later moves them… making it seem like the SVG tag itself is not working… yet, again, one of the two (pretty much identically coded) pages DOES work on the iPad.

I know it’s all a bit vague and all, but does anyone have any theories or insights that might help me out here?

It works like a charm on my PC desktop, and apparently works well on some other devices (Mac laptop was one of them, I think). The only ones that are showing the ‘no visible SVG content’ are the iPad (although only in ONE of the two similar pages), and the iTouch (which fails on both, but it IS an old device).

Maybe the one common factor between these two devices is that both probably haven’t had an O/S update since purchase… so, that might be a factor.

Any other theories?

BTW, I was hoping to put a still image in place of the SVG animation, for those devices that fail to display it, but I’m not sure how to do that, as it would probably involve using absolute positioning, and overlaying it below the SVG element (in Z)… and that seems like a real mess. Not sure if there’s some way to code some sort of SVG support detection… Not really sure what is going on here, anyway.

how are you serving these to the other devices?

is it hosted on the web?

what’s the link?

Just done the regular way… Nothing special.

So, I had another friend test it, and on her phone, neither SVG animations showed up… which made me think it’s an ‘Apple doesn’t support SVG’ kind of thing (assuming it’s an Apple phone).

But, again, ONE of the animations does work on my parent’s iPad (whereas the other one, which is done the same way, doesn’t).

So, even though I don’t think I’ll figure out what is going on here, one thing I do need to do is somehow detect if the device supports SVG… and that’s something I’m not sure how to do. So, I’m hoping someone can help me out here.

One thought that crossed my mind was enclosing the SVG within a script tag, but I’m not sure if I can even do that, let alone if that will even help here.

Really, the issue is not so much that the SVG doesn’t appear on some (mobile?) devices, but that the space that would be occupied by it still exists (is reserved)… so there’s this large gap between my title and the rest of the site content (between which would normally sit the SVG animation).

So, I need to somehow have it not display the SVG if the device doesn’t support it…

That’s where I need help.

i’m suggesting you are trying to solve a problem that may not exist in the live website.

if you’re only hosting it from your pc there maybe other processes getting in the way that a full up internet hosted service would not have.

i’m literally thinking outside the “box” here.

just something to consider.

No, I tested it live.

It seems to be inconsistant support for SVG, so I need to code a detection system so that the SVG graphic block is excluded from the page on devices that don’t support it.

Or, at least, find a means to close that huge gap left behind where the SVG block would normally be, when on a device that doesn’t support it.

I just can’t figure out, then, why that one iPad DID display ONE of the two. If it were a 100% fail, every time, it would clearly be a support thing… but since it DID work on one, there must be support… yet, both anims are (as far as method/coding) identical.

Apple ios devices always seem troublesome to me. I’ve done stuff that works perfectly on desktop PC, Mac and Android, but chokes on ios. Maybe it’s their mobile Safari browser. IDK.

Those two statements sound like it might be improper usage of SVG viewbox, etc., related. But all of this is virtually impossible to surmise through textual only conversation without seeing things directly.

@Printninja: At this point, I managed to fix it for my old iTouch (which I thought would be the hardest to fix for, if not impossible). I have it now so that if it can’t support the SVG animation, it shows the still.

For the LONGEST time, it seemed to refuse to DISPLAY the still… which didn’t make sense, as it’s just an image, and there are other (same format) images on the page right beside it! Turns out, what appeared to be happening is not a failure to display the image (since that doesn’t make sense anyway), but that (seemingly) it ‘passed’ the SVG support test code (hence it doesn’t try to display the fallback still), yet the device still couldn’t display the SVG (or the < img > png’s within it. So, it’s more a failure of the SVG support code test (passed one aspect, but fails to test an aspect ( < img > tag support?) that is actually needed to display the animation (…or at least the png elements used by the animation).

At this point, the one thing it is confirmed not working properly on is a (I assume recent) iPhone… where it does that ‘large gap’ display issue (…again, to me indicating that the SVG support test passed, the fallback image is not displayed, and it tries to do the SVG content, but fails.

So, it seems to me, everything is actually working, except my SVG support test isn’t specific enough (or not addressing the actual things that are required to display the SVG). That would be one of two things… the SVG tag itself (which I assume my current test code covers), or the < img > tag (…which I think is the case here). But, I’m not well-versed enough in Javascript to know how to modify the SVG support test code so that it verifies support for the < img > tag. The animation itself (Javascript/GSAP) should work fine, as it has loads of build-in compatibility. I think it’s just the display of the < img > content within the SVG tags that is not supported by those few devices.

Just wacky that my ancient, unupdated iTouch now displays it fine. The animation doesn’t work (no surprise, since this was before GSAP was even created, I think)… but the fallback image now properly displays, and that’s the best I can hope for on such an old device.

@Pinegrow_User: Not looking for verified diagnoses… Just hoping for theories that I can run with. Please let me know what you think might be a common/possible misuse of the SVG viewbox.

What I got is quite simple:

  • An SVG tag with a class and ID defined… no other attributes).
  • Several < img > tags containing a PNG image file, with X and Y attributes, the href source URL, and a unique class name for each image.
  • And the closing SVG tag.

That’s it.

So, any theories or obvious errors based on that, please let me know.

Ok, then I look forward continuing to read about your progress. You can of course Google, StackOverflow etc., theorizing and perhaps even find something related to your actual setup. It’s potentially an endless endeavor for others to assist blindly otherwise, with too many potential unknown aspects without seeing the actual setup.