Ich habe hier schon einmal über mein Problem mit CSS-Borders geschrieben. Ausgangspunkt war ein Fancy Button: 160 × 48 Pixel, 16 Pixel Radius, 1 Pixel Gradient-Border, ein kleiner Inner Shadow. In Figma schnell gebaut. Im Browser ein paar Layer mehr als erwartet.
Ein Teil davon wird jetzt einfacher. Figma hat die Auto-Layout-Berechnung näher an CSS gebracht. Chromium unterstützt background-clip: border-area. Zwei Änderungen an unterschiedlichen Stellen, die beim selben Button zusammenkommen.
Figma rechnet mehr wie CSS
Inside-Strokes werden in der neuen Auto-Layout-Version standardmäßig ins Layout eingerechnet. Die Border bekommt ihren Platz außerhalb des Paddings. CSS-Padding und Figma-Padding meinen damit beim Included-Frame denselben Abstand.
20 px Textzeile, oben und unten 13 px Padding, dazu jeweils 1 px Border. Ergibt 48 px. Kein nachträgliches Abziehen der Border vom Padding.
.button {
box-sizing: border-box;
min-width: 160px;
border-radius: 16px;
line-height: 20px;
padding: 13px 16px;
border: 1px solid currentColor;
}
Bei Hug wächst die Komponente mit dem Inhalt. Bei fixer Höhe nimmt die Border Platz innerhalb dieser Höhe ein. So, wie man es im Browser erwartet.
Included ist jetzt der Standard
Neu sind der Default und weitere Details der Berechnung. Center- und Outside-Strokes zählen nicht ins Layout. Die Stroke-Einstellung eines Frames beeinflusst nicht mehr seine Kinder. Padding wird als Mindestplatz berücksichtigt. Die einzelnen Änderungen beschreibt Figma in der Übersicht zum neuen Auto Layout.
Alte Frames wechseln nicht automatisch. Also am Frame prüfen, welche Layout-Version und welcher Border-Modus aktiv sind. Excluded bleibt sinnvoll, wenn ein Rand absichtlich über dem Inhalt liegen soll. Eine Card mit überlappenden Borders muss man nicht umbauen, nur weil der Default jetzt anders ist.
Und dann ist da noch der Gradient
Ein gerundeter Gradient-Rand lässt sich mit zwei Background-Layern oder einer Maske bauen. Der eine Weg verdeckt die Mitte, der andere schneidet sie aus.
Mit background-clip: border-area lässt sich der Background direkt auf die Border-Fläche begrenzen. Der Gradient bleibt am Rand. Die Mitte bleibt frei. Der Radius funktioniert auch.
.button {
border: 1px solid #6b4eff;
border-radius: 16px;
}
@supports (background-clip: border-area) {
.button {
border-color: transparent;
background: linear-gradient(135deg, #d94f30, #6b4eff);
background-origin: border-box;
background-clip: border-area;
}
}
Kein Pseudo-Element, keine Mask-Composite-Operation, keine weiße Fläche über dem Gradient. Gerade über Bildern oder anderen wechselnden Hintergründen ist das angenehm.
border-color akzeptiert trotzdem keine Gradients. Der Verlauf bleibt ein Background, dessen Zeichenfläche auf den Rand begrenzt wird. Die Border selbst ist transparent, damit man ihn sieht.
Der Browser-Support
Chrome unterstützt border-area ab Version 150. Safari ist seit 18.2 dabei. Das Feature ist also nicht komplett neu. Mit Chromium wird es für mehr Nutzer verfügbar.
Firefox fehlt noch. Deshalb steht im Beispiel zuerst eine einfarbige Border. Erst innerhalb von @supports wird sie transparent und bekommt den Gradient. Gleiche Maße, anderer Paint.
Soll der Verlauf überall gleich aussehen, bleibt die Maskenlösung als Fallback. Soll die Mitte eine eigene Füllung bekommen, braucht es dafür eine weitere Background-Ebene.
Was damit nicht gelöst ist
border-area ändert die Darstellung des Backgrounds. Die Border nimmt weiterhin Layout-Platz ein. Ein Inside-Stroke, der über einem Bild liegt, wird dadurch nicht automatisch zu einer passenden CSS-Border. Overlay und Box-Model sind immer noch zwei unterschiedliche Dinge.
Auch beim Inner Shadow würde ich weiter genau hinschauen. Die neue Layout-Berechnung sagt erst mal nichts darüber aus, an welcher Kante der Schatten beginnt. Der Unterschied bei der Platzierung des Schattens ist damit nicht automatisch behoben.
Und alte Dateien bleiben alte Dateien. Die neue Berechnung hilft erst, wenn die Komponente sie auch verwendet.
Was das für Agents bedeutet
Dev Mode und MCP liefern Werte. Je näher die Modelle dahinter beieinanderliegen, desto weniger muss bei der Umsetzung übersetzt werden. Das hilft Entwicklern und aus meiner Sicht genauso Agents.
Ob Figma das speziell dafür geändert hat, lässt sich daraus nicht ableiten. Der praktische Vorteil bleibt: weniger Sonderfälle für Padding und Border, weniger Hilfsebenen für einen Gradient-Rand.
Ein Agent muss trotzdem wissen, ob der Frame Included oder Excluded verwendet und welche Browser die Seite unterstützen soll. Diese Information steckt nicht allein in der Border-Farbe.
Fazit
Der Button sieht hinterher genauso aus. Seine Umsetzung wird einfacher.
Figma liefert ein passenderes Layout-Modell, CSS einen direkteren Weg für den Gradient-Rand. Die Workarounds verschwinden nicht überall, aber sie werden seltener nötig. Und genau so sollte es sein. Eine Border sollte kein eigenes kleines Projekt sein.