Icons im Design-System: Warum CSS-Rendering die Kontrolle über Strichstärken kostet

Das Problem in einem Satz

Stroke-basierte Icon-Sets wie Lucide, Phosphor oder Tabler bieten im Gegensatz zu flächenbasierten Sets wie Google Material Symbols oder Heroicons Solid einen Freiheitsgrad, den Filled-Icons konstruktionsbedingt nicht haben: die Steuerung der Linienstärke über stroke-width. Diese Eigenschaft bestimmt, ob ein Icon filigran (1 px), ausgewogen (1,5 px) oder kräftig (2 px) wirkt, und ist damit einer der wirksamsten Hebel für die Feinabstimmung zwischen Icons und Typografie. Wer Icons als CSS-Klassen rendert — etwa über UnoCSS preset-icons, Tailwind-Plugins oder ähnliche Lösungen — verliert genau diesen Hebel. Der Grund ist technisch simpel, aber die Auswirkungen auf ein Design-System sind erheblich.

Wie CSS-basiertes Icon-Rendering funktioniert

Tools wie UnoCSS preset-icons oder das Iconify-Ökosystem wandeln SVG-Icons in CSS-mask-image-Definitionen um. Aus einem mehrzeiligen SVG wird eine einzige CSS-Klasse:

/* Was preset-icons aus einem Lucide-Icon macht */
.i-lucide-arrow-right {
  --un-icon: url("data:image/svg+xml,...");
  mask-image: var(--un-icon);
  -webkit-mask-image: var(--un-icon);
  mask-repeat: no-repeat;
  mask-size: 100% 100%;
  background-color: currentColor;
  width: 1em;
  height: 1em;
  display: inline-block;
}

Das SVG wird zur Maske. Die sichtbare Fläche ergibt sich aus der Silhouette des Icons, eingefärbt durch background-color: currentColor. Elegant, performant, und mit einem einzigen Utility-Klassennamen im Markup erledigt.

Aber: Eine Maske kennt nur Fläche oder keine Fläche. Es gibt kein „halb transparent”, kein „dünnerer Strich”, kein „2 px statt 1,5 px”. Der Stroke wurde beim Rendering in eine Pixelfläche aufgelöst — die SVG-Eigenschaft stroke-width existiert im CSS-Kontext nicht mehr.

Warum Strichstärke kein Detailproblem ist

Strichstärke ist keine kosmetische Kleinigkeit. In einem konsistenten Design-System erfüllt sie drei Funktionen:

Optische Gewichtung. Icons stehen neben Text. Ein Icon mit stroke-width: 2 neben einer Light-Schrift (300) wirkt überproportional schwer. Ein Icon mit stroke-width: 1.25 neben einer Medium-Schrift (500) verschwindet. Die Strichstärke muss zur typografischen Umgebung passen — und die variiert zwischen Headline, Body und Caption.

Größenanpassung. Ein 16-px-Icon braucht optisch eine andere Strichstärke als dasselbe Icon bei 24 px oder 32 px. Bei kleinen Größen muss der Stroke relativ dicker sein, damit das Icon lesbar bleibt. Bei großen Größen wirkt derselbe Stroke plump. Lucide löst das mit einer Default-stroke-width von 2 bei 24 px Basisgröße — aber sobald die Größe abweicht, stimmt das Verhältnis nicht mehr.

Markencharakter. Stripe nutzt feine 1,5-px-Strokes. Notion setzt auf kräftige 2 px. Linear arbeitet mit 1,75 px. Die Strichstärke ist Teil der visuellen Identität — ein Parameter, der sich durch jede Seite, jedes Feature, jedes Interface zieht.

Wer die Strichstärke nicht steuern kann, akzeptiert den Default des Icon-Sets als unveränderlichen Teil seiner Marke.

Die drei Rendering-Methoden im Vergleich

1. CSS mask-image (preset-icons, Iconify CSS)

<span class="i-lucide-settings text-xl text-zinc-600"></span>

Geeignet für: Projekte, die mit dem Default-Stroke des Icon-Sets leben können und DX priorisieren.

2. Inline SVG (Svelte-Komponente)

<script>
  import Settings from 'lucide-svelte/icons/settings';
</script>

<Settings size={20} strokeWidth={1.5} class="text-zinc-600" />

Geeignet für: Design-Systeme, die volle Kontrolle über die visuelle Darstellung brauchen.

3. SVG Sprite mit <use>

<svg width="20" height="20" stroke-width="1.5">
  <use href="/icons.svg#settings" />
</svg>

Geeignet für: Große Projekte mit vielen Icon-Instanzen, wo HTTP-Requests minimiert werden sollen.

Was das für Design-System-Architektur bedeutet

Die Entscheidung „Wie rendern wir Icons?” ist eine Infrastrukturentscheidung. Sie fällt früh, ist teuer zu revidieren, und beeinflusst jede Komponente, die ein Icon enthält — also nahezu alle.

Für ein Design-System, das Konsistenz über verschiedene Kontexte garantieren soll, gibt es einen klaren Entscheidungsbaum:

Frage 1: Variiert die Strichstärke nach Kontext? Wenn Icons in Navigationen (klein, kräftig), in Hero-Bereichen (groß, fein) und in Buttons (mittel) unterschiedlich gewichtet werden sollen — dann ist Inline SVG die einzige Option, die das ohne Workarounds ermöglicht.

Frage 2: Ist ein einheitlicher Stroke über alle Größen akzeptabel? Wenn ja, funktioniert CSS mask-image hervorragend. Viele Icon-Sets sind so gezeichnet, dass ihr Default-Stroke bei 20–24 px gut funktioniert. Wer sich auf diesen Bereich beschränkt, merkt die Einschränkung kaum.

Frage 3: Wie viele Icons nutzt das Projekt? Bei 20–40 Icons ist der Bundle-Unterschied zwischen CSS-Klassen und Inline SVG vernachlässigbar. Bei 200+ Icons in einer Anwendung wird die DX von preset-icons zum echten Produktivitätsgewinn.

Der Hybrid-Ansatz: CSS für Standard, SVG für Kontrolle

In der Praxis ist die Antwort selten binär. Ein pragmatischer Ansatz für SvelteKit-Projekte:

<!-- Standard-Kontext: CSS-Icon reicht -->
<span class="i-lucide-chevron-right" aria-hidden="true"></span>

<!-- Kontext mit spezifischer Gewichtung: Inline SVG -->
<script>
  import ArrowRight from 'lucide-svelte/icons/arrow-right';
</script>
<ArrowRight size={32} strokeWidth={1.25} />

Die Bedingung dafür: Das Design-System dokumentiert explizit, welche Rendering-Methode in welchem Kontext gilt. Sonst entsteht über Monate eine Mischung, deren Inkonsistenz erst auffällt, wenn jemand alle Icons nebeneinander legt.

Design-Token für Icon-Gewichtung können die Intention festhalten, auch wenn die Umsetzung je nach Rendering-Methode variiert:

:root {
  /* Icon-Stroke-Weight-Intention (für Inline SVG) */
  --icon-stroke-sm: 1.75;   /* In Navigation, kompakte UI */
  --icon-stroke-md: 1.5;    /* Standard, Buttons, Listen */
  --icon-stroke-lg: 1.25;   /* Hero-Bereiche, große Icons */
}

Diese Tokens greifen nur bei Inline SVG. Aber sie dokumentieren die Designentscheidung — und das ist der erste Schritt zu einem System, das diese Entscheidung auch durchsetzt.

Fazit

Die Frage „Können wir die Strichstärke steuern?” klingt nach einem Fünf-Minuten-Problem. Die Antwort berührt die Architektur des gesamten Icon-Systems. CSS-basiertes Rendering ist nicht falsch — es ist ein bewusster Trade-off: maximale DX gegen eingeschränkte Designkontrolle.

Problematisch wird es, wenn der Trade-off unbewusst getroffen wird. Wer preset-icons einführt, weil die Einbindung elegant ist, und erst sechs Monate später feststellt, dass die Icons bei 32 px zu grob und bei 14 px zu dünn wirken, hat ein Migrationsproblem.

Die Empfehlung: Die Rendering-Methode als bewusste Designentscheidung im Design-System dokumentieren — mit Begründung, mit Kontext-Regeln, und mit dem Wissen, dass mask-image keine SVG-Eigenschaften kennt.