Sprites SVG : conserver ID, viewBox et couleurs

Un sprite de symboles SVG stocke des définitions d’icônes nommées dans un même fichier SVG. Chaque icône visible utilise un élément <use> pour référencer la définition nécessaire. Ce conditionnement fonctionne uniquement si l’ID de fragment, le système de coordonnées et les règles de peinture survivent au transfert depuis les fichiers individuels.

Commence avec deux icônes avant de combiner tout un dossier. Dans cet exemple, une feuille utilise un espace de coordonnées carré et une flèche vers la droite un espace large. La feuille apparaîtra en deux couleurs sans duplication de son tracé. La flèche gardera ses proportions au lieu d’être forcée dans le canevas de la feuille.

Si tes icônes sources nécessitent encore des formes, des marges ou une épaisseur optique cohérentes, termine d’abord la préparation d’un kit UI SVG. Un sprite organise le dessin ; il ne le répare pas.

Crée deux définitions de symboles nommées

Enregistre cet exemple original sous sprite.svg :

<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="pv-leaf" viewBox="0 0 24 24">
    <path fill="currentColor"
      d="M5 19C2 10 9 4 20 4C20 15 14 22 5 19Z"/>
  </symbol>
  <symbol id="pv-arrow" viewBox="0 0 32 16">
    <path fill="currentColor"
      d="M2 5H21V1L30 8L21 15V11H2Z"/>
  </symbol>
</svg>

La feuille se nomme pv-leaf et la flèche pv-arrow. Ce sont les identifiants que la page demandera. MDN décrit symbol comme une définition graphique réutilisable instanciée avec use. Un fichier contenant uniquement des symboles peut sembler vide lorsqu’il est ouvert seul, puisque les définitions ne sont pas directement rendues.

Garde le viewBox avec le dessin qu’il décrit. Ici, la feuille utilise 0 0 24 24 et la flèche 0 0 32 16. Ces nombres définissent des limites de coordonnées, et non une taille d’affichage obligatoire. Remplacer les limites de la flèche par 24 sur 24 sans adapter sa géométrie n’est pas une normalisation. Consulte la référence MDN de viewBox pour la correspondance entre coordonnées et zone d’affichage.

Pour une famille d’icônes existante, garde sa grille convenue. Les formes variées présentées ici illustrent autre chose : le conditionnement doit préserver le système de coordonnées déjà approuvé. Si une flèche doit suivre le bout d’une ligne ou d’une courbe, utilise les marqueurs SVG pour les pointes personnalisées alignées afin de définir son point d’attachement et sa direction.

Référence le sprite depuis une page

Place sprite.svg, ta page HTML et icons.css dans le même répertoire servi. Commence avec un aperçu HTTP de même origine pour qu’une restriction de fichiers locaux ou un autre hôte ne masque pas une erreur élémentaire de référence.

Ajoute ces règles à icons.css et charge cette feuille de style depuis la page :

.icon {
  display: inline-block;
  width: 1.5rem;
  height: 1.5rem;
  vertical-align: middle;
}
.icon-wide {
  width: 3rem;
}
.garden-button {
  display: inline-flex;
  align-items: center;
  gap: 0.5rem;
  color: #167d8d;
}

Ajoute ensuite ces instances au corps HTML :

<button class="garden-button" type="button">
  <svg class="icon" aria-hidden="true" focusable="false">
    <use href="./sprite.svg#pv-leaf"></use>
  </svg>
  Garden
</button>
 
<svg class="icon icon-wide" role="img" aria-label="Right direction"
  style="color: #233b63">
  <use href="./sprite.svg#pv-arrow"></use>
</svg>

La partie avant # localise le fichier ; celle après sélectionne le symbole. L’attribut moderne est href. La référence MDN de use documente les références externes et avertit que les navigateurs peuvent refuser les chargements entre origines. Ne suppose pas que déplacer un sprite fonctionnel vers un CDN soit un remplacement immédiat ; teste l’emplacement réel de livraison.

À la taille de police racine par défaut du navigateur, ces règles donnent à la feuille une boîte de 24 sur 24 pixels CSS et à la flèche une boîte de 48 sur 24. Les tailles utilisent rem : une autre taille de police racine les modifie donc. Compare les icônes dans le vrai composant et dans un aperçu agrandi : une boîte correcte peut encore contenir un dessin avec trop de marges.

Le bouton ci-dessus démontre la présentation et le nommage de l’icône. Ajoute le gestionnaire d’action propre à l’application lorsque tu l’utilises dans un produit.

Choisis la règle de peinture avant de combiner les fichiers

Les deux tracés de l’exemple utilisent explicitement fill="currentColor". Cela permet à une instance utilisatrice de reprendre le color CSS environnant : le bouton fournit le bleu-vert et la flèche le bleu marine. La référence color explique que currentColor peut fournir la valeur des remplissages et contours.

Pour la seconde apparition de la feuille, utilise la même référence pv-leaf et change le color de l’instance en corail. Ne duplique pas le tracé uniquement pour créer une autre couleur de thème.

Ne remplace pas tous les remplissages d’un logo multicolore par currentColor. Cela supprime délibérément sa palette. Si le fichier change déjà de couleur avant le conditionnement en sprite, utilise le guide de diagnostic des couleurs SVG pour isoler ce problème antérieur.

Évite aussi de construire une API de sprite autour de sélecteurs de page arbitraires atteignant les tracés référencés. MDN signale les limites de style du contenu cloné dans use. Définis le comportement de peinture prévu dans le dessin source et teste le consommateur.

Évite les ID en double dans le dessin

Des noms de symboles uniques sont nécessaires, mais un SVG exporté peut contenir davantage d’ID internes : dégradés, masques, chemins de découpage ou autres définitions référencées. MDN exige que chaque id SVG soit unique dans son arbre de nœuds. Deux fichiers auparavant distincts peuvent enfreindre cette règle une fois combinés.

Supposons par exemple qu’un export de feuille et un export de badge contiennent tous deux un dégradé nommé paint0. Préfixe ensemble l’ID du dégradé de la feuille et sa référence correspondante :

Le fragment doit toujours pointer vers la définition prévue. Les exemples MDN de fill montrent cette relation entre ID du dégradé et url(#...). Donne au badge son propre préfixe plutôt que de faire pointer les deux références vers le dégradé de la feuille.

Notre exemple à deux tracés n’a pas de définitions imbriquées, ce qui en fait un premier contrôle utile. Pour un véritable export, inventorie tous les ID et références locales avant de combiner les fichiers. Après l’exécution d’un optimiseur ou générateur, répète cet inventaire sur le sprite livré. Renommer uniquement le symbole extérieur ne résout pas les ID internes en double.

Nomme chaque instance visible selon son contexte

La feuille à côté du mot visible « Garden » répète l’information déjà fournie par le bouton. Son SVG utilise aria-hidden="true" et laisse au texte du bouton le rôle de fournir son nom. Garde cet attribut sur le SVG décoratif, pas sur le bouton interactif. Les conseils MDN sur aria-hidden couvrent le contenu décoratif et avertissent de ne pas masquer les éléments pouvant recevoir le focus.

La flèche autonome a un autre rôle : elle communique une direction sans texte voisin. Son SVG extérieur utilise role="img" et aria-label="Right direction", selon les conseils MDN pour nommer une image SVG intégrée.

Détermine l’étiquette au point d’utilisation. Une feuille réutilisable peut signifier « Jardin », « D’origine végétale » ou n’être qu’une décoration selon l’interface. Teste le nom accessible du composant final avec les outils d’inspection d’accessibilité du navigateur et ta technologie d’assistance cible ; un symbole réutilisable seul n’établit pas ce contexte.

Vérifie le sprite livré, pas seulement les sources

Nous avons vérifié cet exemple original dans une page de test de même origine dans le navigateur. La feuille s’affichait en bleu-vert et corail, la flèche large gardait sa forme et un fragment volontairement absent produisait une boîte d’icône vide. L’arbre d’accessibilité du navigateur exposait le bouton Garden et la flèche nommée. C’est un contrôle de cet exemple, et non une certification entre navigateurs ou lecteurs d’écran.

Utilise le même petit ensemble de contrôles après conditionnement :

1. Fichier : confirme que la page charge le sprite prévu depuis l’URL finale.
2. Fragment : compare chaque fragment href à l’ID du symbole livré, y compris la casse.
3. Limites : compare le petit composant et le dessin agrandi pour détecter découpage, marges et rapport de proportions.
4. Peinture : affiche une icône monochrome dans deux couleurs de thème et inspecte séparément les dessins à couleurs fixes.
5. Références internes : vérifie que les références préfixées de peinture, masque et découpage se résolvent encore après optimisation.
6. Sens : inspecte le nom de chaque composant interactif et l’étiquette de chaque image autonome significative.

Si le fichier charge mais qu’une seule instance est vide, vérifie le fragment avant de modifier la géométrie. Si le même dessin est vide également comme SVG ordinaire, suis les contrôles généraux des SVG vides. S’il semble pixellisé à l’agrandissement, cherche une image matricielle intégrée avant de supposer que le sprite cause le problème.

Lorsque la seule source est une icône PNG

Si une icône simple existe seulement en PNG, convertis ce PNG en SVG avec PerfectVector avant de le conditionner. Inspecte la silhouette, les trous et les régions colorées obtenues par rapport à la source, puis approuve ses limites de coordonnées et sa règle de peinture. Donne enfin des ID stables au dessin approuvé et ajoute-le au sprite. La conversion fournit le dessin vectoriel ; elle ne choisit ni tes noms de symboles, ni la sémantique des composants, ni l’architecture de livraison.

Si un SVG original propre existe, utilise-le. Le retracer ajoute une autre étape de reconstruction des formes sans résoudre une référence de fragment cassée. Consulte les guides de modification et préparation SVG lorsque le problème restant concerne le dessin plutôt que son conditionnement.

FAQ

Pourquoi mon sprite SVG est-il vide lorsque je l’ouvre directement ? Un sprite contenant seulement des définitions de symboles ne les affiche pas directement. Teste-le via une instance SVG use avec le bon chemin de fichier et le bon ID de fragment avant de considérer le document vide comme un dessin endommagé.

Chaque symbole nécessite-t-il le même viewBox ? Non. Préserve chaque système de coordonnées approuvé lors du conditionnement. Des icônes partageant une grille de système de design peuvent avoir les mêmes limites, mais un symbole large ne devient pas une icône carrée simplement en modifiant les nombres du viewBox.

Pourquoi changer la couleur de la page ne recolore-t-il pas mon icône ? Vérifie la règle de peinture de la source. Un remplissage fixe diffère d’un tracé conçu avec currentColor. Préserve les dessins multicolores volontaires et choisis explicitement quels remplissages ou contours doivent hériter de la couleur de l’instance.

Puis-je placer le sprite sur un autre domaine ? Ne suppose pas qu’une référence use externe fonctionne entre origines. Commence avec un exemple de même origine, puis teste l’hôte réel et les navigateurs cibles avant de changer la livraison. Un exemple local réussi ne démontre pas la prise en charge entre origines.

Sources

1. MDN — symbol — Définitions réutilisables et rendu indirect.
2. MDN — use — Fragments externes, limites de style et restrictions d’origine.
3. MDN — viewBox — Relation entre limites de coordonnées et zone d’affichage.
4. MDN — color — currentColor comme entrée de peinture SVG.
5. MDN — id — Unicité des identifiants dans l’arbre du document.
6. MDN — fill — Références de serveurs de peinture comme les URL de dégradés.
7. MDN — aria-hidden — Contenu décoratif et précautions pour les éléments pouvant recevoir le focus.
8. MDN — Rôle img — SVG extérieur nommé pour une image significative.

Commence avec deux icônes approuvées et teste leurs noms, limites et couleurs dans le composant réel. Si une source existe seulement sous forme matricielle adaptée, reconstruis ses tracés SVG, inspecte le dessin, puis ajoute le résultat accepté à ton sprite.