THIRD EDIT: here's a working test case. It looks like it has something to do with caching the svg spritesheet. If I configure cache control on my server so that there's no caching of the SVG, the behavior occurs. Feel free to view source (it's all in the one file, but I don't want to include it all here).
https://stuff.spherical.fish/svgtest.html
SECOND EDIT: The fix listed below (directly injecting the elements in the index.html instead of using an external spritesheet) just stopped working in Chrome v49 (which my beta channel browser just updated to). v48 has the intermittent rendering issue, but v49 pretty consistently doesn't render anything that's referred follows a <svg><use></use></svg>
pattern; but only in a big, complicated angular page. A boring simple test case works fine. Added a bounty for anyone who can directly point me at a known issue or wherever this might be coming from. It is most assuredly not file-not-found, as it's still an intermittent bug, and the whole page renders just fine in firefox and safari.
EDIT: this definitely has something to do with referring to an external resource. When I embed the SVGs directly in index.html and refer to them in with <use xlink:href="#id"></use>
they work fine, but if I refer to an external file in the <use>
element, they only load sometimes.
I have some weird behavior in chrome (only - this doesn't happen on opera, firefox, safari); I've been seeing it since at least the early 40s, version-wise.
My behavior is in the middle of an ng-repeated angular structure. Everything is the same - there's a bunch of divs flexboxed together. There's also an SVG element that looks like:
<svg class="icon-3"> <use xlink:href="/assets/trellis-icons.svg#icon-users"></use> </svg>
pretty straightforward.
The thing is, for some of these repeated elements, the icon doesn't render. Inspecting the element in the chrome dev tools indicates that the rendered SVG's <use>
element has a height and width, whereas the non-rendered one has a zero height and width.
It's not like there's any real difference here; I've even manually edited the DOM to make one of the offending entries match one of the rendered ones completely, but the svg still doesn't render. Here's a relevant screenshot.
You can see below (and ignore my padding issues with the button) the first row doesn't have the little heads and word bubble icons. This is an intermittent problem - if I reload the page, it may be fine, or maybe none of the icons will load.
I'm wondering: is there some kind of obscure issue associated with using sprite sheets (all the SVGs that exhibit this behavior are in the same big SVG file and are referenced by #id) loading asynchronously or something?
If this is really unknown / new behavior, I'll work on engineering a test case, but building something that probably relies on some kind of concurrency bug is kind of hard. So I figured I'd ask around first.
EDIT to add: This behavior does not happen if I export the individual svg out as a standalone and use it in an <img src="icon.svg">
fashion. It does still fail if I do an svg use on the icon in a single standalone file.
EDIT: per @kaiido's request, here is the relevant svg in question.
<svg xmlns="http://www.w3.org/2000/svg"> <!-- thirty other symbols snipped --> <symbol id="icon-users" viewBox="0 0 512 512"> <path d="m352 397c-15-16-78-32-109-48c-21-11-32-33-32-53c0-10 7-19 13-26c5-6 9-14 13-24c8-4 18-12 18-31c0-12-2-19-5-24c1-11 2-22 3-34c4-45-42-90-89-90c-47 0-92 45-88 90c1 12 2 23 3 34c-4 5-5 12-5 24c0 19 9 27 18 31c4 10 8 18 13 24c6 7 13 16 13 26c0 20-11 42-32 53c-18 9-48 19-72 28l0 68l354 0c0 0 0-32-16-48z m146-7c-21-8-46-16-62-24c-17-8-25-27-25-43c0-8 5-15 10-21c4-5 8-12 11-20c7-3 15-10 15-25c0-10-2-16-5-20c1-9 2-18 3-27c3-37-34-76-73-76c-38 0-75 39-72 76c1 9 2 18 3 27c-3 4-5 10-5 20c0 16 8 22 15 25c3 8 7 15 11 20c4 6 10 13 10 21c0 10-4 22-11 31c30 11 43 22 53 33c19 19 19 58 19 58l103 0z"/> </symbol> </svg>
If you are trying to use SVG like <img src="image. svg"> or as a CSS background-image , and the file is linked to correctly and everything seems right, but the browser isn't displaying it, it might be because your server is serving it with an incorrect content-type.
Browser SupportFirefox, Chrome, Safari, Opera and the Android browser have been able to show SVG natively for a while, at the time of writing. That is also true for Safari for iOS, Opera's mini and mobile browsers, and Chrome for Android.
SVG (Scalable Vector Graphics) is officially supported by all main web browsers, including Internet Explorer. The support spans into a wide variety of image editor software, particularly Inkscape, which uses SVG as its native format (If you want a refresher on SVG, click here).
Well, it turns out this is a chrome bug after all, and pretty much what I had thought it was: changing <use>
elements around breaks under certain circumstances. Those circumstances are basically: when the svg spritesheet isn't cached in the browser.
https://code.google.com/p/chromium/issues/detail?id=580809
Fixed in canary (M50), might get merged in to M49.
The workaround is to set a cache-control header on the SVG spritesheet that is more than zero. That also helps explain why I only saw this bug in my testing server and not in production - I have different cache settings on my beta box.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With