KKS-26 — Image radius plus the ring behind it
The Figma hero on KKS-Netzwerk-Vertragsgestaltung is an image with a rounded top-right corner and a thin orange ring showing behind that corner. Two composable options in the »Shape, mask and radius« panel, not one combined option, so each works on its own:
| Value | Class | What it does |
|---|---|---|
radius-top-right | .frame-option-radius-top-right | Rounded top-right corner, 50px at xl stepping to 16px |
circle-top-right | .frame-option-circle-top-right | 169px ring, 1px #F55E21, behind the image |
Both numbers are measured off the nodes rather than chosen. 281-10731 is the image — 1080×221 at Left 100 / Top 204, Radius top-right 50px. 281-10730 is Ellipse 12 — 169×169 at Left 1046 / Top 169, border 1px Orange #F55E21, no fill.
Which makes the offset exact and symmetric: image right edge 100 + 1080 = 1180 against ring right 1046 + 169 = 1215, so 35px out; image top 204 against ring top 169, so 35px up.
Both are stored as a share of the image width, not in pixels — 169/1080 = 15.6481% for the diameter, 35/1080 = 3.2407% for the offset — so the ring keeps this exact proportion and position at every viewport instead of only at 1280. Resize the window and check the console snippet below: the percentages do not move.
Two details make that work. aspect-ratio: 1 derives the height from the width, because a percentage height would resolve against the image’s height and turn the ring into an ellipse on any non-square image. And the offsets are negative percentage margins rather than negative top/right: percentages on margin resolve against the containing block’s inline size on all four sides, margin-top included, so both offsets scale on the single basis of the image width. A percentage top would have drifted apart from right on every aspect ratio.
The 1px border is deliberately not scaled — 1px of 169 becomes 0.3px on a phone, which renders as a washed-out or missing line rather than a thinner one.
The ring is drawn with border-radius: 50% and a 1px border, not as an SVG data URI. The supplied asset is literally <circle r="84" stroke="#F55E21"/> with no fill, so a CSS ring is the same artwork with none of the costs — nothing added to the icon store, no percent-encoding to get wrong, and it stays crisp at every zoom and pixel ratio instead of being a scaled raster.
Measure it:
var f = document.querySelector('#c92610 .imageframe'), b = getComputedStyle(f, '::before');
var w = f.getBoundingClientRect().width;
(parseFloat(b.width) / w * 100).toFixed(2) + '% ring, ' + (Math.abs(parseFloat(b.marginTop)) / w * 100).toFixed(2) + '% offset';
// expect "15.65% ring, 3.24% offset" at EVERY viewport
Vertragsgestaltung
The reference case — both options ticked, which is the Figma hero. The ring sits behind the image, offset 35px up and 35px right, so a quarter of it shows past the rounded corner.
Because the offset is proportional it also cannot outgrow the container gutter, which an earlier fixed 35px did — at 375px it pushed the page to scrollWidth 395 against a 375 viewport, i.e. a horizontal scrollbar on every phone. There is now no breakpoint special-casing at all.
The ring needs no help to sit behind the image: it is painted on a ::before of .imageframe at z-index: 0 while the img is lifted to z-index: 1. The image is lifted rather than the ring pushed to a negative z-index, because .imageframe has z-index: auto and so is not a stacking context — a negative child would escape past it and hide under the frame’s own background instead.
Praxisnahe Unterstützung für effiziente, rechtssichere und standardisierte Vertragsprozesse in der klinischen Forschung.
Radius alone
radius-top-right on its own — 50px on the image’s top-right corner, no ring. This is why the two are separate options rather than one: the corner is usable without the decoration.
Both corners now share one responsive scale — 50 / 40 / 30 / 24 / 16 from xl down to xs — which replaced an earlier split of 50px top-right against a flat 30px bottom-left. 50px is the measured Figma value (node 281-10731); the steps below it hold the same 4.63 %-of-image-width ratio within 4 %, because a flat value would be 3.1× rounder on a phone than on desktop.
⚠️ One limit worth knowing: the scale is keyed to the breakpoint, not to the individual image. This element’s image is a text-and-image column (505px at 1280), so 50px is 9.9 % of it rather than 4.63 %. A container-query implementation (4.6296cqw) would fix that exactly — verified in the browser as 23.38px on this very image — and is noted as a possible follow-up.
Ring alone
circle-top-right on its own — the ring against a square image corner. Useful for judging whether the ring reads on its own, and it is the case that shows the ring is positioned off the image box rather than the frame box.
This element is also the proof that the scaling tracks the image and not the viewport: it is a text-and-image element, so at 1280 its image is 505px wide and its ring comes out at 79px, while the full-width hero above has a 1080px image and a 169px ring. Different pixel sizes on the same page at the same viewport, both exactly 15.65 % of their own image.
The ring is deliberately not clipped. KKS-20 applies overflow: hidden when a corner radius meets the KKS-14 vector, but circle-top-right is excluded from that: this ring is meant to bleed past the image corner, so clipping it would delete the effect.
Control — nothing ticked
Same element, no options. Square corners, no ring — both are opt-in.