Icons und Vektorgrafik
SVG-Dateien eignen sich besonders gut für Benutzeroberflächen, weil sie auflösungsunabhängig sind. Ein Icon bleibt bei unterschiedlichen Bildschirmgrößen und Pixeldichten scharf, da es nicht aus festen Pixeln, sondern aus mathematisch beschriebenen Pfaden besteht. Diese Eigenschaft allein garantiert jedoch noch keine gute Webdatei. Unübersichtliche Ebenen, unnötige Metadaten, ungeeignete Farbangaben oder missverständliche Dateinamen können die Pflege und Nutzung erschweren.
Bei der Vorbereitung geht es deshalb um mehrere Ziele gleichzeitig: Die Grafik soll korrekt dargestellt werden, möglichst wenig Ballast enthalten, in einer verständlichen Ordnerstruktur liegen und sich zuverlässig in HTML, CSS oder einem Icon-System einsetzen lassen. Zusätzlich muss geklärt werden, ob das Icon rein dekorativ ist oder eine Information beziehungsweise eine Aktion vermittelt. Diese Unterscheidung beeinflusst die Barrierefreiheit.
Eine gute Arbeitsweise beginnt nicht beim Export, sondern bei der Planung. Vor dem Speichern sollte feststehen, welche Bedeutung das Icon hat, welche Größe im Interface vorgesehen ist, ob es eine Füllung oder Kontur benötigt und ob die Farbe später per CSS angepasst werden soll.
SVG steht für Scalable Vector Graphics. Das Format beschreibt Formen mit Elementen wie path, circle, rect oder line. Im Gegensatz zu einem Rasterbild wird die Darstellung beim Skalieren neu berechnet. Für kleine Symbole ist das nützlich, weil ein 16-Pixel-Icon und eine größere Variante aus derselben Geometrie erzeugt werden können.
Besonders wichtig ist die viewBox. Sie definiert das interne Koordinatensystem der Datei, zum Beispiel von 0 bis 24 auf der horizontalen und vertikalen Achse. Die tatsächliche Anzeigebreite und -höhe kann im HTML oder CSS davon abweichen. Fehlt die viewBox oder passt sie nicht zu den gezeichneten Formen, entstehen abgeschnittene Ränder, unerwartete Abstände oder ein falsches Seitenverhältnis.
Die Attribute width und height legen dagegen eine bevorzugte Darstellungsgröße fest. Für flexible Webkomponenten ist eine viewBox häufig entscheidender als feste Pixelwerte. Vor dem Export sollte geprüft werden, ob alle Pfade innerhalb der viewBox liegen und ob die Außenkanten genügend Abstand zu den Grenzen besitzen.
Auch die Zeichenrichtung und die Formüberlagerung können relevant sein. Bei komplexeren Icons führen sich überschneidende Pfade je nach Füllregel zu unerwarteten Löchern oder geschlossenen Flächen. Eine Vorschau im Browser gehört deshalb zur Qualitätskontrolle und ersetzt nicht die Kontrolle in der Grafiksoftware.
Ein Icon sollte vor dem Export auf seine tatsächliche Funktion reduziert werden. Nicht benötigte Hilfslinien, verborgene Ebenen, Schnittmasken, Kommentare und Entwurfsvarianten gehören nicht in die finale Datei. Sie können die Struktur aufblähen oder bei der Umwandlung in SVG unerwartete Elemente erzeugen.
Die bearbeitbare Quelldatei sollte nicht durch eine optimierte Webdatei ersetzt werden. Sinnvoll ist eine Trennung zwischen Original, exportierter SVG und gegebenenfalls weiterverarbeiteter Version. So bleibt eine spätere Korrektur möglich, ohne eine bereits reduzierte Datei mühsam rekonstruieren zu müssen.
Die Farbdefinition entscheidet darüber, wie flexibel ein Icon im Web eingesetzt werden kann. Fest eingetragene Werte wie fill="#333333" sind für eine unveränderliche Darstellung geeignet, begrenzen aber die Anpassung an dunkle und helle Oberflächen. Für Icons, deren Farbe vom umgebenden Text abhängen soll, wird häufig currentColor verwendet. Damit übernimmt das SVG die berechnete Textfarbe des jeweiligen Elements.
Bei mehrfarbigen Icons sollten die Farben bewusst und nachvollziehbar festgelegt werden. Zufällig verteilte Farbattribute erschweren spätere Änderungen. Eine kontrollierte Farbstruktur kann durch CSS-Klassen oder klar benannte Gruppen entstehen, sofern die Einbindungsmethode diese Struktur beibehält.
Konturen benötigen besondere Aufmerksamkeit. Die Attribute stroke-width, stroke-linecap und stroke-linejoin beeinflussen Enden und Ecken. Abweichungen fallen bei kleinen Größen stärker auf als bei großen Illustrationen. Runde Enden können bei technischen Symbolen passend sein, während spitze Verbindungen bei bestimmten Formen zu dunklen Verdichtungen führen.
Transparenz und Verläufe sollten nur eingesetzt werden, wenn sie einen nachvollziehbaren gestalterischen Zweck erfüllen. Ein Icon mit vielen Transparenzstufen ist schwerer über verschiedene Hintergründe zu beurteilen. Für Status- oder Bedienicons sind klare Kontraste meist robuster. Die Anforderungen an ausreichenden Kontrast hängen vom Kontext und vom verwendeten Inhalt ab; bei interaktiven Elementen muss nicht nur das Symbol, sondern die gesamte Bedieneinheit betrachtet werden.
Der Export aus einer Zeichen- oder Layoutanwendung erzeugt oft eine funktionierende, aber nicht besonders aufgeräumte Datei. Metadaten zur verwendeten Software, leere Gruppen, redundante Attribute und unnötig genaue Koordinaten können entfernt werden. Dafür werden in der Praxis SVG-Optimierer eingesetzt. Eine Optimierung darf jedoch nicht blind erfolgen, weil manche Werkzeuge IDs umbenennen, Gruppen zusammenfassen oder Attribute entfernen, die für eine bestimmte Einbindung benötigt werden.
Vor und nach der Optimierung sollte die Datei in einer Vergleichsumgebung geprüft werden. Wichtig sind dabei:
Eine Reduzierung der Dezimalstellen bei Koordinaten kann die Dateigröße verringern. Wird zu stark gerundet, verändert sich die Form jedoch sichtbar. Besonders bei kleinen Icons können geringe Abweichungen an Spitzen, Kreisen oder dünnen Linien auffallen. Die kleinste Datei ist daher nicht automatisch die beste Datei. Entscheidend ist ein vertretbares Verhältnis aus Größe, visueller Genauigkeit und Wartbarkeit.
SVG ist XML-basiert und kann mehr enthalten als reine Pfadgeometrie. Je nach Verarbeitungskette können beispielsweise Skripte, externe Referenzen, eingebettete Inhalte oder unerwünschte Metadaten eine Rolle spielen. Für statische Benutzeroberflächen-Icons sollte die Datei auf die benötigte Darstellung beschränkt werden. Nicht benötigte Skript- und Interaktionsbestandteile gehören nicht in eine solche Ressource.
Besondere Vorsicht ist bei SVG-Dateien aus unbekannten Quellen angebracht. Vor der Verwendung sollten sie in einem isolierten Arbeitsablauf geprüft und durch einen vertrauenswürdigen Optimierungs- oder Bereinigungsprozess geführt werden. Ein Texteditor kann Hinweise auf unerwartete Elemente liefern, ersetzt aber keine vollständige Sicherheitsprüfung.
Auch die Einbindungsmethode beeinflusst die Kontrolle. Ein SVG als externe Bilddatei wird anders behandelt als ein direkt in HTML eingebettetes SVG. Beim Inline-SVG können interne Elemente mit CSS angesprochen werden, gleichzeitig gelangt mehr Markup in das Dokument. Werden Inhalte dynamisch aus Benutzereingaben zusammengesetzt, müssen sie vor der Ausgabe zuverlässig validiert und bereinigt werden.
Für dekorative Icons ist eine statische, minimal aufgebaute Datei meist die übersichtlichste Wahl. Originaldateien mit umfangreicher Bearbeitungshistorie sollten nicht ungeprüft im öffentlichen Webverzeichnis liegen.
Ein guter Dateiname beschreibt die Funktion oder das Motiv des Icons und bleibt auch außerhalb der Grafiksoftware verständlich. Namen wie icon-final-neu-2.svg sagen wenig über den Inhalt aus und führen bei mehreren Varianten schnell zu Verwechslungen. Besser ist ein stabiles Schema, das Bedeutung, Zustand und gegebenenfalls Stil unterscheidet.
Für Webprojekte bewähren sich kleingeschriebene Namen mit Bindestrichen als Worttrenner. Umlaute, Akzente, Leerzeichen und Sonderzeichen sollten vermieden werden, weil sie in Shell-Befehlen, URLs, Build-Prozessen oder verschiedenen Betriebssystemen zu unnötigen Problemen führen können. Eine mögliche Struktur lautet:
bereich-motiv-variante-zustand.svg
Beispiele sind navigation-menu.svg, navigation-menu-open.svg, status-warning-filled.svg oder action-download-outline.svg. Der Name sollte nicht die konkrete Pixelgröße enthalten, wenn dieselbe SVG flexibel skaliert werden kann. Eine Größenangabe ist dagegen sinnvoll, wenn eine Datei bewusst nur für eine bestimmte Verwendung erzeugt wurde oder wenn mehrere technische Varianten existieren.
Begriffe sollten innerhalb eines Projekts konsistent verwendet werden. Wenn ein Zustand einmal active und an anderer Stelle selected heißt, muss das Team die Bedeutungsunterscheidung dokumentieren. Gleiches gilt für outline, stroke, filled und solid. Ein kurzes Namensschema in der Projektdokumentation verhindert spätere Mischformen.
Die Dateibenennung allein löst keine Organisationsprobleme. Eine klare Ordnerstruktur trennt Rohmaterial, Webexporte und zusammengesetzte Ressourcen. Ein mögliches Modell ist:
Ob die Struktur nach Themen, Komponenten oder Stilen gegliedert wird, hängt vom Projekt ab. Bei einer kleinen Sammlung kann ein gemeinsamer Ordner ausreichen. Mit wachsender Zahl von Icons wird eine Trennung nach Funktionsbereichen hilfreicher als eine lange alphabetische Liste.
Versionen sollten nicht durch unklare Zusätze wie neu, final oder final-final gekennzeichnet werden. Änderungen gehören in die Versionsverwaltung oder in eine nachvollziehbare Änderungsnotiz. Falls mehrere Varianten parallel benötigt werden, sollten sie nach ihrer tatsächlichen Funktion unterschieden werden, etwa search-outline.svg und search-filled.svg.
Ein kleines Inhaltsverzeichnis oder eine automatisch erzeugte Vorschauseite hilft bei der visuellen Kontrolle. Dabei sollten die Namen unter den Icons angezeigt werden. So fallen Schreibfehler, uneinheitliche Zustände und doppelte Bedeutungen früh auf.
Ein Icon kann dekorativ sein oder eine Information beziehungsweise Aktion vermitteln. Diese Rolle muss in der Einbindung kenntlich werden. Ein rein dekoratives Bild benötigt in der Regel keinen zusätzlichen Alternativtext. Bei einem img-Element wird dafür ein leerer Alt-Text verwendet, damit assistive Technologien das Bild nicht als bedeutungslosen Dateinamen vorlesen. Ein informatives Icon braucht dagegen eine verständliche textliche Alternative.
Bei einem Icon in einer Schaltfläche darf nicht vorausgesetzt werden, dass die Form allein die Funktion erklärt. Eine Schaltfläche zum Schließen kann einen sichtbaren oder für assistive Technologien zugänglichen Namen wie „Dialog schließen“ benötigen. Wird das SVG inline eingebettet, können Attribute wie role, aria-hidden oder ein zugänglicher Name je nach Kontext relevant sein. Ihre Verwendung muss zur konkreten HTML-Struktur passen.
Eine wichtige Regel lautet: Der Dateiname ist kein Ersatz für eine zugängliche Beschriftung. settings.svg hilft einer entwickelnden Person, ist aber keine vollständige Benutzerinformation. Bei interaktiven Elementen sollte der zugängliche Name die Aktion beschreiben, nicht nur das Aussehen des Symbols.
Die konkrete Einbindung kann unterschiedlich aussehen:
Eine wiederholbare Prüfung verhindert, dass sich kleine Fehler in eine ganze Icon-Sammlung ausbreiten. Sie kann manuell beginnen und später durch automatisierte Prüfungen ergänzt werden.
Für größere Sammlungen kann ein automatisierter Prozess Dateinamen, verbotene Elemente, fehlende viewBox-Angaben und doppelte IDs prüfen. Visuelle Regressionstests sind ebenfalls hilfreich, weil ein syntaktisch gültiges SVG trotzdem anders aussehen kann als die vorherige Version.
Abgeschnittene Formen: Ursache ist häufig eine zu enge viewBox oder eine Kontur, die über die Begrenzung hinausragt. Die Lösung besteht in einer Prüfung der tatsächlichen Außenkanten einschließlich der halben Konturstärke.
Unscharfe Darstellung: Dünne Linien können bei kleinen Größen ungünstig auf dem Pixelraster liegen. Das Icon sollte in Zielgrößen betrachtet und gegebenenfalls mit angepasster Geometrie als eigene Variante gestaltet werden.
Falsche Farben: Harte Füllfarben verhindern eine Anpassung an Themes. Vor dem Export sollte feststehen, ob die Farbe Bestandteil des Motivs ist oder vom Interface gesteuert werden soll.
Unbrauchbare Dateinamen: Zeitangaben, Entwurfsbegriffe und Versionsreste machen die Funktion nicht erkennbar. Benannt wird nach Bedeutung, Variante und Zustand.
Versehentlich entfernte IDs: Optimierer können IDs ändern oder löschen. Wenn ein Sprite, CSS-Selektor oder eine Animation darauf angewiesen ist, muss die Optimierung entsprechend konfiguriert und danach getestet werden.
Fehlende Textalternative: Ein aussagekräftiges Symbol in einer Schaltfläche darf nicht nur durch seine visuelle Form verständlich sein. Die Bedienfunktion benötigt eine zugängliche Beschriftung.
Ungeprüfte Fremddateien: SVG-Dateien werden nicht wie harmlose Screenshots behandelt. Vor der Veröffentlichung sollten Inhalte, Einbettungen und Herkunft kontrolliert werden.
| Einsatz | Geeignete Vorbereitung | Worauf besonders achten? |
|---|---|---|
| Dekoratives UI-Icon | Minimiertes SVG, klare viewBox, CSS-Farbe nach Bedarf | Leere oder passende Textalternative und ausreichender Kontrast |
| Icon in einer Schaltfläche | SVG als Bild oder Inline-Element mit definierter Funktion | Zugänglicher Name der Aktion, nicht nur der Dateiname |
| Mehrfarbige Illustration | Festgelegte Farbgruppen und kontrollierte Pfade | Darstellung auf verschiedenen Hintergründen |
| SVG-Sprite | Konsistente IDs, gemeinsame viewBox-Regeln und dokumentierte Symbole | Keine ID-Konflikte sowie Tests der Referenzen |
| Icon-Sammlung für mehrere Themes | currentColor oder definierte CSS-Variablen, sofern passend | Kontrast, Zustände und Verhalten bei deaktivierten Elementen |
Die viewBox beschreibt das interne Koordinatensystem und ermöglicht eine flexible Skalierung. Ohne passende viewBox können Seitenverhältnis, Abstände und sichtbare Flächen bei der Darstellung fehlerhaft sein.
Bei einer flexibel skalierbaren SVG ist eine Größenangabe meist unnötig. Sie kann jedoch sinnvoll sein, wenn mehrere bewusst unterschiedlich gestaltete Größenvarianten existieren oder eine Datei nur für einen bestimmten Einsatz vorgesehen ist.
Nein. Der Dateiname dient der technischen Organisation. Ein Alternativtext oder zugänglicher Name muss die Bildinformation oder die Funktion im jeweiligen Nutzungskontext vermitteln.
Nein. Eine Optimierung kann IDs, Gruppen oder Attribute verändern, die für Sprites, CSS oder Animationen benötigt werden. Nach jeder Optimierung sollten Darstellung und Einbindung geprüft werden.
currentColor eignet sich, wenn ein Icon die Farbe des umgebenden Textes oder einer CSS-Regel übernehmen soll. Bei fest definierten mehrfarbigen Motiven ist eine kontrollierte Farbangabe meist passender.
Eine konsistente SVG-Pipeline muss nicht aus vielen komplizierten Werkzeugen bestehen. Entscheidend ist eine feste Reihenfolge: Zuerst wird das Motiv auf seine Webfunktion reduziert, danach werden Geometrie und viewBox kontrolliert. Anschließend folgen Farben, Konturen und die Umwandlung problematischer Objekte in stabile Pfade. Die exportierte Datei wird bereinigt, aber nicht ohne Vergleich mit der Originaldarstellung.
Danach erhält das Icon einen eindeutigen Namen und wird in den passenden Ordner eingeordnet. Eine kurze Dokumentation hält Begriffe für Zustände und Varianten fest. Vor der Veröffentlichung werden Markup, Sicherheit, Darstellung in mehreren Größen und Barrierefreiheit geprüft. Bei größeren Projekten lassen sich viele dieser Regeln automatisieren, die visuelle Kontrolle bleibt dennoch wichtig.
So entsteht keine Sammlung zufällig exportierter Einzeldateien, sondern ein wartbares System. Saubere SVGs helfen bei der technischen Pflege, verständliche Namen beschleunigen die Zusammenarbeit und eine kontextgerechte Auszeichnung sorgt dafür, dass Icons nicht nur scharf aussehen, sondern auch zuverlässig nutzbar bleiben.
