CSS has given us border-radius for rounded corners since forever, and most of us never thought much about it. Then corner-shape came along, and suddenly the rendering engine team had to do real math.
The Chrome DevBlog post on implementing corner-shape in Blink is one of those “I did not expect to be this interested” reads. It walks through what it actually takes to support a property that lets you define corner geometry beyond simple arcs — things like bevel cuts, notches, squircles, and scoop shapes.
What corner-shape actually enables
The property adds a new axis of control to corners. Where border-radius gives you a circular arc, corner-shape lets you specify the type of curve (or non-curve) at each corner:
round— the familiar arcangle— a sharp point, like a starbevel— a straight diagonal cutnotch— an inward bevelscoop— a concave arcsquircle— a superellipse, the shape Apple loves
That last one is where things get interesting. A squircle isn’t a circle or a square — it’s a Lamé curve, defined by the equation |x/a|ⁿ + |y/b|ⁿ = 1 where n is somewhere between 2 and infinity. Rendering that accurately with bezier curves (which is what SVG and canvas ultimately use under the hood) requires approximation, and approximation means making careful tradeoffs between accuracy and performance.
The actual corner cases
The literal corner cases are where this gets messy. What happens when two adjacent corners with different shapes meet? What if border-radius is large enough that the corners would overlap? How does the shape interact with border-image or clip-path? What about RTL layouts?
Each of these is a separate geometric edge case that has to be handled explicitly. You can’t just define the happy path and ship it — a rendering engine has to be correct for all valid CSS, including the weird combinations nobody uses in production but someone will definitely try.
The implementation also has to be fast. Corner-shape affects layout and painting, so any computation has to be cheap enough to not tank scroll or animation performance on pages that use it heavily.
Why I find this kind of work fascinating
I spend most of my time in Discord bot land, which is about as far from rendering engines as you can get. But there’s something I genuinely respect about the engineering that goes into “simple” CSS features.
The surface area exposed to developers — a single CSS property with a handful of keyword values — is deceptively small compared to the implementation surface below it. This is true of a lot of platform features. The API is the easy part. Making it correct across every valid input, interaction, and edge case is where the real work lives.
If you have any interest in how browsers actually render things, or just want a concrete example of why “it’s just geometry” is never actually just geometry, the post is worth your time.