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

Runde Ecken hatten ihre Zeit. Eine lange Zeit. Buttons, Cards, Modals, Tabellenköpfe, Badges, Tooltips – irgendwann war alles weich gezeichnet. Das sah eine Weile zeitgemäß aus. Jetzt wirkt es vor allem: überall gleich.

Wir haben uns an diesem Stil sattgesehen. Auf webconsulting.at geben wir Rounded Corners auf und kehren zu Ecken und Kanten zurück. Nicht als Retro-Gag, sondern als Design- und Engineering-Entscheidung: weniger optische Polsterung, mehr Klarheit, weniger CSS-Theater.

Inhaltsverzeichnis  

Warum jetzt?  

Rounded Corners sind aus dem Soft-UI- und Mobile-Zeitalter in fast jedes Designsystem gewandert. Frameworks liefern sie als Default. Component Libraries runden Buttons, Inputs und Panels automatisch. Wer nichts aktiv entscheidet, bekommt Rundungen – und zwar überall.

Genau das ist das Problem: Rundung ist zum Hintergrundrauschen geworden. Sie signalisiert kaum noch „freundlich“ oder „modern“. Sie signalisiert vor allem „Standard-UI aus dem Baukasten“.

Wir wollen wieder eine Formensprache, die nach Entscheidung aussieht – nicht nach Default. Klassische, eckige Kanten lesen sich ruhiger, wenn Typografie, Kontrast und Abstände die Arbeit übernehmen. Die Fläche bleibt Fläche. Die Kante bleibt Kante.

Was runde Ecken in der Praxis kosten  

Der visuelle Effekt ist klein. Die Folgekosten sind es nicht.

1. Platzverlust an den Kanten  

Jeder Radius schneidet nutzbare Fläche weg. In engen Komponenten – Toolbar, Badge, Tabellenkopf, Icon-Button – fehlt genau dort Platz, wo Inhalte sitzen sollen. Bei eckigen Containern bleibt die volle Bounding Box nutzbar. Bei runden Containern wandert Inhalt nach innen oder kollidiert mit der Kurve.

2. Icons in der Rundung  

Sobald ein Icon, ein Statuspunkt oder ein Action-Control in die Nähe einer gerundeten Ecke rückt, entsteht ein klassisches Layout-Problem: das Element hängt optisch in der Kurve, wirkt beschnitten oder braucht Extra-Padding. Dann folgen Workarounds: mehr Innenabstand, absolute Positionierung, spezielle Corner-Slots. Bei eckigen Kanten verschwindet dieses Problem weitgehend – die Geometrie bleibt orthogonal und vorhersehbar.

3. Ungewollte Radius-Kaskaden  

CSS und Utility-Klassen verteilen Radius oft weiter als gedacht. Ein rounded-* auf einem Parent, ein Theme-Token auf --radius, ein Komponenten-Default auf th – und plötzlich erscheinen Rundungen an Stellen, an denen niemand sie bestellt hat.

Ein aktuelles Beispiel aus der Praxis: Tabellenköpfe mit Rundung links und rechts. Zwei Kurven in zwei Richtungen treffen aufeinander. Optisch entstehen Doppelbögen, die nicht zum Raster passen. Ergebnis: wieder ein Fix, wieder eine Ausnahme, wieder Pflegeaufwand.

4. Inkonsistenz über Systemgrenzen  

Sobald Design-Tokens, Tailwind-Utilities, Component Libraries und eingebettete Diagramme (zum Beispiel Mermaid) jeweils eigene Radius-Werte mitbringen, driftet das System. Eine „leichte“ Rundung hier, eine stärkere dort, rounded-full für Pills, rounded-2xl für Cards – und die Oberfläche verliert die gemeinsame Kante.

Eckig als Default beendet diese Diskussion: Radius 0 ist der gemeinsame Nenner.

Der ehrliche Nachteil  

Eckige Interfaces verzeihen weniger.

Ohne gezielte Nacharbeit in Typografie, Abständen, Kontrast und Hierarchie wirkt ein scharfkantiges UI zunächst härter, direkter und weniger poliert. Rounded Corners übernehmen oft die Rolle eines visuellen Weichzeichners: sie kaschieren enge Abstände, uneinheitliche Padding-Werte und schwache Hierarchie. Fallen die Rundungen weg, treten diese Schwächen offen zutage.

Das ist kein Argument gegen eckige Kanten – es ist die eigentliche Designarbeit, die danach folgt. Wer Rundungen abschafft, muss die Oberfläche über Inhalt, Raster und Typografie tragen, nicht über Radius-Kosmetik.

Umsetzung auf webconsulting.at  

Die Richtung ist klar: keine runden Ecken als Systemdefault.

Konkret heißt das:

1. Design-Tokens (--radius* und verwandte Variablen) stehen 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 eckig. Rundungen sind keine stille Mitgift mehr.

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

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

Das ist bewusst streng. Halbe Migrationen – hier eckig, dort noch rounded-xl – erzeugen genau den Flickenteppich, den wir vermeiden wollen.

Fazit  

Rounded Corners waren lange der bequeme Default. Wir stellen ihn ab, weil der Nutzen nicht mehr die Kosten trägt:

• optisch austauschbar statt unterscheidbar,
• Platzverlust und Overlaps in engen Komponenten,
• Icons und Actions, die in der Kurve landen,
• CSS-Kaskaden mit Rundungen, die niemand gesetzt hat.

Eckige Kanten wirken ohne Nacharbeit härter. Das ist der Punkt: Typografie, Raster und Kontrast müssen die Oberfläche tragen – nicht der nächste rounded-2xl-Default.

Zurück zu Ecken und Kanten. Weniger Weichzeichnung. Mehr Entscheidung.