Abschied von Rounded Corners: Zurück zu Ecken und Kanten

Runde Ecken sind heute fast überall Standard: bei Buttons, Cards, Modals, Tabellenköpfen, Badges und Tooltips. Gerade weil sie so verbreitet sind, sehen viele Interfaces inzwischen sehr ähnlich aus.

Wir stellen webconsulting.at auf eckige Kanten um. Die Gründe sind gestalterisch wie technisch: mehr nutzbare Fläche in kompakten Komponenten, eine einheitliche Geometrie und weniger CSS-Sonderregeln. Diese Entscheidung gilt für unsere eigene Website und unsere Tools. Sie ist keine allgemeine Empfehlung gegen Rundungen.

Inhaltsverzeichnis  

Warum jetzt?  

Mit mobilen Benutzeroberflächen und Soft UI haben sich runde Ecken in vielen Designsystemen etabliert. Frameworks und Komponentenbibliotheken liefern sie als Voreinstellung für Buttons, Eingabefelder und Panels mit. Wer nichts anderes festlegt, bekommt Rundungen in praktisch allen Komponenten.

Damit ist die Rundung als gestalterisches Signal weniger aussagekräftig als früher. Ein Interface mit Standardrundungen zeigt vor allem, welche Voreinstellungen ein Projekt übernommen hat.

Für webconsulting.at wollen wir die Formensprache bewusst festlegen. Eckige Kanten unterstützen ein klares Raster; die visuelle Hierarchie entsteht über Typografie, Kontrast und Abstände.

Was Rundungen in der Praxis bedeuten  

Runde Ecken betreffen nicht nur die Optik. Sie machen sich auch in der technischen Pflege von Komponenten bemerkbar. Vier Punkte haben bei unserer Entscheidung den Ausschlag gegeben.

1. Platzverlust an den Kanten  

Jeder Radius nimmt an den Ecken nutzbare Fläche weg. In kompakten Komponenten wie Toolbars, Badges, Tabellenköpfen oder Icon-Buttons müssen Inhalte deshalb weiter nach innen rücken. Ein eckiger Container bietet dagegen die volle rechteckige Fläche.

2. Icons in der Rundung  

Sitzt ein Icon, ein Statuspunkt oder ein Bedienelement nahe an einer runden Ecke, wirkt es schnell angeschnitten. Dann braucht es zusätzlichen Innenabstand, absolute Positionierung oder eigene Positionierungsbereiche. Bei eckigen Kanten fällt dieser Aufwand weitgehend weg, weil die Geometrie orthogonal und vorhersehbar bleibt.

3. Ungewollte Radius-Kaskaden  

CSS und Utility-Klassen geben Radien gern über mehrere Ebenen weiter. Schon ein rounded-* auf einem übergeordneten Element, ein Theme-Token auf --radius oder eine Komponenten-Voreinstellung auf th erzeugt Rundungen an Stellen, an denen sie gar nicht vorgesehen waren.

Ein typisches Beispiel sind Tabellenköpfe, die auf beiden Seiten gerundet sind. Wo benachbarte Kurven aufeinandertreffen, entstehen Doppelbögen, die nicht ins Raster passen. Solche Stellen muss man einzeln nachkorrigieren, und das macht die Wartung aufwendiger.

4. Inkonsistenz über Systemgrenzen  

Design-Tokens, Tailwind-Utilities, Komponentenbibliotheken und eingebettete Diagramme bringen oft jeweils eigene Radius-Werte mit. Dann stehen unterschiedlich starke Rundungen nebeneinander, und die Oberfläche verliert ihre einheitliche Formensprache.

Ein einheitlicher Wert löst dieses Problem unabhängig davon, wie er lautet. Wir haben uns für 0 entschieden, weil Radius 0 allen Systemen dieselbe eindeutige Ausgangsbasis gibt und keine Abstufungen kennt.

Gestalterische Anforderungen  

Ein eckiges Interface verzeiht weniger. Typografie, Abstände, Kontrast und Hierarchie müssen präzise sitzen.

Runde Ecken können kleine Unstimmigkeiten bei Abständen oder in der visuellen Hierarchie optisch abmildern. Fällt die Rundung weg, sieht man enge Abstände, uneinheitliche Innenabstände und eine unklare Hierarchie deutlich schneller. Das ist ein echter Vorteil von Rundungen, den man bei der Entscheidung einrechnen muss.

Deshalb überarbeiten wir im Zuge der Umstellung auch diese Grundlagen. Die visuelle Qualität der Oberfläche muss aus Inhalt, Raster und Typografie kommen.

Umsetzung auf webconsulting.at  

Unser Standard für diese Website ist eindeutig: Radius 0 im gesamten Designsystem.

Konkret heißt das:

1. Wir setzen die Design-Tokens (--radius* und verwandte Variablen) auf 0.
2. Eine nachgelagerte CSS-Schicht erzwingt scharfe Kanten auch dort, wo Utilities oder Komponenten noch rounded-* mitbringen.
3. Diagramm- und Chart-Chrome (unter anderem Mermaid-Knoten) folgen derselben Regel.
4. Neue Komponenten starten standardmäßig mit Radius 0. Abweichungen definieren wir ausdrücklich.

:root {
--radius: 0;
--radius-sm: 0;
--radius-md: 0;
--radius-lg: 0;
/* … weitere Radius-Tokens auf 0 … */
}

*,
*::before,
*::after {
border-radius: 0;
}

Wichtig ist, die Regel systemweit anzuwenden. Bleiben einzelne Bereiche bei anderen Radius-Werten, entsteht wieder ein uneinheitliches Bild.

Desiderio: Der Radius bleibt einstellbar  

Radius 0 ist eine Entscheidung für unsere eigene Website. Unser kommendes TYPO3-Template-System Desiderio trifft diese Entscheidung bewusst nicht für seine Nutzer: Dort bleibt der Radius eine ganz normale Theme-Einstellung.

Das Vorbild dafür ist shadcn/ui, die Komponentenbibliothek von shadcn. In deren Theme-Editor auf ui.shadcn.com/create ist der Radius ein Wert wie jeder andere, mit den Optionen Default, None, Small, Medium und Large. Wer ein Theme zusammenstellt, entscheidet selbst, wie stark die Rundung ausfällt. In der Frontend-Community gibt es dazu den halb ernst gemeinten Satz „shadcn is always right“. An dieser Stelle stimmen wir zu: Ein Template-System, das viele verschiedene Sites bedienen soll, darf eine gestalterische Grundsatzfrage nicht für alle Projekte gleich beantworten. Deshalb haben wir die Option in Desiderio belassen.

Desiderio übernimmt das Modell des shadcn-Theme-Editors als Site-Einstellung: None, Small, Medium, Large und zusätzlich Full. Ohne eigene Festlegung gilt der Radius des gewählten shadcn-Presets. Technisch schreibt Desiderio die Einstellung als data-radius-Attribut auf das body-Element; eine CSS-Variable verteilt den Wert an alle Komponenten. Ein Wechsel wirkt sofort auf die ganze Site, ohne Build-Schritt und ohne Deployment.

body[data-radius="none"] { --radius: 0rem; }
body[data-radius="sm"]   { --radius: 0.375rem; }
body[data-radius="md"]   { --radius: 0.625rem; }
body[data-radius="lg"]   { --radius: 0.75rem; }
body[data-radius="full"] { --radius: 1rem; }

Die folgenden Screenshots zeigen dasselbe Desiderio-Element mit drei verschiedenen Radius-Werten. Cards, Badges und Buttons folgen jeweils demselben Token:

Damit sind beide Wege abgedeckt: webconsulting.at nutzt konsequent Radius 0, und Desiderio-Projekte wählen den Wert, der zu ihrer Marke passt. Mehr zum Template-System steht im Artikel über Desiderio.

Fazit  

Runde Ecken sind weiterhin ein brauchbarer Standard. Die meisten Komponentenbibliotheken unterstützen sie gut, und viele Nutzer erwarten sie. Für webconsulting.at haben wir uns trotzdem für Radius 0 entschieden:

• Viele Websites sehen durch dieselben Standardrundungen ähnlich aus.
• In kleinen UI-Elementen bleibt weniger Platz für Inhalte.
• Icons und Bedienelemente brauchen oft zusätzliche Abstände oder Sonderpositionierungen.
• CSS-Regeln können Radien ungewollt an untergeordnete Elemente weitergeben.

Eckige Kanten allein machen ein Interface noch nicht gut. Klare Typografie, saubere Raster, einheitliche Abstände und ausreichender Kontrast werden dadurch sogar wichtiger. Auf diese Grundlagen konzentrieren wir uns bei der Weiterentwicklung unseres Designsystems.

Auf webconsulting.at ist Radius 0 damit der verbindliche Standard, und Ausnahmen brauchen einen Grund. In Desiderio-Projekten bleibt die Wahl dagegen offen: Der Radius ist dort eine Einstellung, kein Dogma.