Les SVG dans Chrome parfois ne rendent pas
Troisième édition: voici un cas de test de travail. Il semble que cela ait quelque chose à voir avec la mise en cache du svg spritesheet. Si je configure le contrôle du cache sur mon serveur afin qu'il n'y ait pas de mise en cache du SVG, le problème se produit. Ne hésitez pas à voir la source (tout est dans le même fichier, mais je ne veux pas tout inclure ici).
https://stuff.spherical.fish/svgtest.html
SECOND EDIT: Le correctif répertorié ci-dessous (injectant directement les éléments dans le fichier index.html au lieu d'utiliser une feuille de calcul externe) venait de cesser de fonctionner dans Chrome v49 (que mon navigateur de chaîne bêta vient de mettre à jour)). La v48 a un problème de rendu intermittent, mais la v49 ne restitue pas toujours quoi que ce soit qui est référé suit un <svg><use></use></svg> modèle; mais seulement dans une grande page compliquée angular. Un cas de test simple et ennuyeux fonctionne très bien. Ajout d’une prime pour toute personne qui peut me diriger directement vers un problème connu ou d’où il puisse provenir. Il n'est assurément pas un fichier introuvable, car il s'agit toujours d'un bogue intermittent, et la page entière s'affiche parfaitement dans Firefox et Safari.
EDIT: cela a certainement quelque chose à voir avec la référence à une ressource externe. Quand j'intègre les SVG directement dans index.html et que je les renvoie avec <use xlink:href="#id"></use> ils fonctionnent bien, mais si je me réfère à un fichier externe dans le <use> élément, ils ne chargent que parfois.
J'ai un comportement étrange dans chrome (seulement - cela ne se produit pas sur l'opéra, firefox, safari); je le vois depuis au moins le début des années 40, en termes de version.
Mon comportement est au milieu d'une structure ng-repeat angular. Tout est pareil - il y a un tas de div flexboxed ensemble. Il y a aussi un élément SVG qui ressemble à:
<svg class="icon-3">
<use xlink:href="/assets/trellis-icons.svg#icon-users"></use>
</svg>
assez simple.
Le problème est que, pour certains de ces éléments répétés, l'icône ne s'affiche pas. L'inspection de l'élément dans les outils chrome dev indique que le <use> l'élément a une hauteur et une largeur, tandis que l'élément non rendu a une hauteur et une largeur égales à zéro.
Ce n'est pas comme s'il y avait une réelle différence ici; J'ai même manuellement modifié le DOM pour faire en sorte que l'une des entrées incriminées corresponde totalement à l'une des entrées affichées, mais le svg ne s'affiche toujours pas. Voici une capture d'écran pertinente.
Vous pouvez voir ci-dessous (et ignorer mes problèmes de bourrage avec le bouton), la première ligne ne contient pas les icônes de petites têtes et de bulles de Word. C'est un problème intermittent - si je recharge la page, tout ira bien, ou peut-être qu'aucune des icônes ne se chargera.
Je me demande: existe-t-il un problème obscur associé à l'utilisation de feuilles Sprite (tous les SVG présentant ce comportement sont dans le même grand fichier SVG et sont référencés par #id) lors du chargement asynchrone ou quelque chose?
Si ce comportement est vraiment inconnu/nouveau, je travaillerai sur l'ingénierie d'un scénario de test, mais créer quelque chose qui repose probablement sur un type de bogue d'accès simultané est assez difficile. Alors j'ai pensé que je demanderais d'abord autour.
EDIT to add: Ce problème ne se produit pas si j'exporte le svg individuel en tant que fichier autonome et que je l'utilise dans un fichier <img src="icon.svg"> mode. Il échoue quand même si j'utilise svg sur l'icône dans un seul fichier autonome.
EDIT: à la demande de @ kaiido, voici le svg pertinent en 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>
Eh bien, il s’avère que c’est un bogue chrome), et à peu près ce que j’avais pensé: changer <use> éléments autour des pauses dans certaines circonstances. Ces circonstances sont essentiellement les suivantes: lorsque le fichier sprites de svg n'est pas mis en cache dans le navigateur.
https://code.google.com/p/chromium/issues/detail?id=580809
Fixé dans le canari (M50), pourrait être fusionné dans M49.
La solution consiste à définir un en-tête de contrôle du cache sur la feuille de sprite SVG supérieur à zéro. Cela aide également à expliquer pourquoi je n'ai vu ce bogue que sur mon serveur de test et non en production - j'ai des paramètres de cache différents sur ma boîte bêta.
Attribut xlink:href est obsolète depuis SVG 2 ( lien de preuve ). Les nouvelles versions de Chrome fonctionnent étrangement avec cet attribut.
Si tu utilises xlink:href (pour les anciens navigateurs) et href (pour les nouveaux navigateurs), tout fonctionnera parfaitement.
J'ai aussi eu ce bug. A été corrigé avec la solution pfooti par la mise en cache, puis par la mise à jour du webkit.
Mais plus tard c'est revenu: ce n'était pas la même chose, mais pourrait être utile pour d'autres plus tard.
J'ai ouvert mon fichier SVG avec Inkscape (mais les mêmes travaux dans Illustrator également), sélectionné mon objet et appliqué path> union et enregistré:
<path class="st0" d="M32 272l128 48 16 160 80-112 112 112L480 32 32 272zm318.7 145.4L256 320l128-176-192 153.8-82.6-31 322-172.5-80.7 323.1z"/>
est devenu
<path d="M480 32L32 272l128 48 16 160 80-112 112 112L480 32zm-48.6 62.3l-80.7 323.1L256 320l128-176-192 153.8-82.6-31 322-172.5z"/>
Et maintenant ça marche!
Je ne sais pas exactement pourquoi, mais Chrome semble avoir quelques problèmes avec la première syntaxe. J'espère que ça aide!