Wer kennt das nicht? Ein neues Icon bei einem Onlinedienst hochladen, Kacheln anklicken, die Schrift oder Sprite runterladen und einbinden. Oder den Designer anbetteln, doch mal die Iconfont zu aktualisieren. Und sobald ein weiteres Icon dazukommt, geht das Spiel von vorne los. Irgendwann war ich zu faul dafür und habe mir den Workflow automatisiert. Gestartet habe ich mit Gulp und Iconfonts und bin später zu SVG-Sprites gewechselt.
Warum eine SVG-Sprite?
Ein SVG-Sprite enthält alle Icons als unsichtbare Symbole. Jede Verwendung referenziert nur ein in dem Sprite definiertes Symbol. Das bringt ein paar handfeste Vorteile mit sich.
Zum einen lädt eine Sprite alle Icons in einem einzigen Request statt in vielen Einzeldateien – gerade beim ersten Aufruf merkt man das. Zum anderen bleiben SVGs als Vektorgrafik bei jeder Größe scharf, da ist nichts mit Pixel-Geraster. Farben und Stil regelt man per CSS: Über currentColor nimmt ein Icon die aktuelle Textfarbe an. Und weil Icons meist nur dekorativ genutzt werden, können sie mithilfe der Attribute aria-hidden="true" und focusable="false" auch barrierefrei eingebunden werden.
Warum ich Iconfonts nicht mehr empfehle
Der Build kann auch eine Iconfont erzeugen. In neuen Projekten würde ich sie jedoch nicht mehr einbinden und stattdessen auf SVG-Sprites setzen. Um mal ehrlich zu sein, spricht einiges gegen die Iconfont. Der klassische Lade-Effekt: Die Font muss erst nachgeladen werden, und bis dahin fehlen die Icons oder hüpfen beim Laden nach. Außerdem ist eine Font im Kern einfarbig – Mehrfarbigkeit oder Farbverläufe pro Icon sind praktisch ausgeschlossen, und je nach Ursprung verhalten sich Strich- und Flächen-Icons unterschiedlich gut. Die Vorteile der SVG-Sprite haben wir oben schon gesehen: gestochen scharfe Kanten, beliebig viele Farben, bessere Barrierefreiheit und keine Lade-Effekte. Fürs Web ist die Sprite deshalb die schlankere Lösung.
Der Workflow für den Sprite-Bau
Für meinen Workflow habe ich ein kleines Tool gebaut, das die Automatisierung übernimmt: iconforge. Es liest alle SVG-Dateien, die in einem Ordner abgelegt werden, ein, konvertiert Strich-Icons in gefüllte Pfade und erzeugt daraus Iconfont, CSS und die SVG-Sprite. Das Tool nutzt dabei: svgtofont für die Generierung und oslllo-svg-fixer für die Konvertierung der Strich- in Flächenpfade. Für mich und meinen Workflow ist das aktuell völlig ausreichend.
Die Installation und Bedienung ist minimal. Da das Package nicht auf npm veröffentlicht ist, wird es direkt aus dem Git-Repository installiert:
npm install -D git+https://gitlab.com/madlenka/iconforge.git
npx iconforge buildStandardmäßig liest es die SVGs aus svg/ und schreibt das Ergebnis nach dist/. Eine Anpassung ist via Konfigurationsdatei oder Build-Parameter möglich (Dokumentation im Repo).
Der Build erzeugt dann drei Dateien: icons.symbol.svg (die SVG-Sprite), icons.woff2/icons.woff (die Iconfont) und icons.css mit den passenden Klassen für deren Nutzung. Die Iconfont braucht man nicht zwingend – wer nur die Sprite will, nutzt einfach nur die icons.symbol.svg.
Die Sprites einbinden
Den Inhalt der Sprite-Datei binde ich meist direkt unsichtbar in den Body der Website ein.
<div class="icon-sprite" style="display: none;">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="0" height="0" style="display:none;">
<symbol viewBox="0 0 24 24" id="icons-bell">...</symbol>
</svg>
</div>Jede spätere Verwendung referenziert ein einzelnes Icon per <use>:
<svg class="icon icon-bell">
<use xlink:href="#icons-bell"></use>
</svg>Alternativ kann die Einbindung auch via URL erfolgen – das funktioniert problemlos, solange die Sprite-Datei auf derselben Domain liegt wie die Seite:
<svg class="icon icon-bell">
<use xlink:href="https://mywebsite.com/assets/icons/icons.symbol.svg#icons-bell"></use>
</svg>Die benötigten Basis-Styles für die Icons können selbst definiert werden. Ein Beispiel dazu gibt es hier: preview-app/css/icons.css
Wie die Nutzung in einer Webanwendung aussehen kann, zeigt die Preview-App bzw. der Quellcode dazu.
Fazit
Der eigentliche Gewinn ist die Automatisierung im Build: Neue Icons legt man nur als SVG in svg/, und die Pipeline baut das passende SVG bzw. Iconfont draus.
Manuelles Sprite-Basteln oder das Durchklicken eines Onlinedienstes entfällt komplett.
Das löst auch das eigentliche Problem: Icons sind kein Content-Detail mehr, das man pflegt, sondern ein generiertes Artefakt.
Weiterführende Links:
Hinweis zu diesem Artikel: Textentwurf und Recherche entstanden zum Teil mit KI-Unterstützung, Redaktion und Fachinhalte von mir; das Beitragsbild ist KI-generiert.
