Crafting Parametric SVG Code Blocks

If you spend enough time reading technical blogs, you realize that code blocks almost always look the same: a rounded rectangle with a contrasting background color. Sometimes, there is a language label sitting awkwardly inside the padding, or a copy button floating over the text.

I wanted something more organic and structured for Zerdalu. I envisioned a shape where the code block feels like a physical file folder—with the language label acting as a tab on the top-left, and the copy button sitting in its own dedicated space on the top-right.

To achieve this, the main background of the code block needed two “cutouts” on the top corners. The label and button would sit in these visual voids, making them feel separated from the code content, yet unified by the overall shape.

Here is how we built it, why we couldn’t just use standard CSS or design tools, and what we plan to do next.

The Problem with CSS clip-path

My first instinct was to use the CSS clip-path property. With clip-path: polygon(...), you can easily chop off the top corners of a div.

However, clip-path has two major drawbacks for this specific design:

1. It destroys borders: When you clip a shape, you also clip its outer CSS border (border-width). There is no easy way to add a nice, uniform stroke around a complex clipped shape.
2. Sharp corners: clip-path polygons result in sharp, rigid vertices. I wanted perfectly smooth, rounded corners (both for the outer edges and the inner joints where the cutouts meet the main body).

Why Inkscape Couldn’t Save Us

If CSS couldn’t do it, my next thought was to open Inkscape (or Figma), draw the exact shape with perfectly rounded 8px corners, export it as an <svg>, and set it as an absolute background.

But a static SVG fundamentally cannot work here for two reasons:

1. Distortion on Resize: If you put a static SVG behind a code block, the browser has to stretch or squash the vector graphic to fit the container. When an SVG stretches horizontally, your beautifully perfect circular 8px corners turn into ugly, stretched ovals.
2. Dynamic Label Widths: The cutouts need to wrap tightly around the floating elements. A label that says JS is much narrower than a label that says TYPESCRIPT. A static SVG from Inkscape has no way of knowing how wide the text will be when the blog post renders on the server.

The Solution: Real-time Parametric SVG Math

To get perfectly rounded corners, a uniform border stroke, and dynamic cutouts that adapt to their content, we had to build a custom, real-time vector graphics engine using JavaScript.

Instead of writing a static SVG, our script does the following:

1. It injects a visually empty <svg> behind the code block.
2. It measures the exact width of the language label and the copy button in the DOM.
3. It takes a few visual configuration variables—like tm = 20 (a top margin to lower the middle bridge and make the tabs pop), r = 8 (outer border radius), and ir = 8 (inner joint radius).
4. It mathematically calculates the exact x and y coordinates for every line (L) and arc (A) to draw a flawless path.

Here is a look at the exact generator logic doing the heavy lifting (and if you are reading this on the blog, the code block wrapping this very code is being generated by it!):

wrapper.__updatePath = () => {
    const W = wrapper.offsetWidth;
    const H = wrapper.offsetHeight;
    
    const tm = 20; // Top margin lowers the middle bridge
    const r = 8;   // Outer border radius
    const ir = 8;  // Inner joint radius
    const gap = 2; // Visual gap separating floaters
    
    const tlW = langLabel.offsetWidth + gap;
    const trW = button.offsetWidth + gap;
    const ch = 36 + gap; 

    // Fallback for extremely squished blocks
    if (W < tlW + trW + 40) {
        path.setAttribute("d", `M ${r} ${tm} L ${W-r} ${tm} A ${r} ${r} 0 0 1 ${W} ${tm+r} L ${W} ${H-r} A ${r} ${r} 0 0 1 ${W-r} ${H} L ${r} ${H} A ${r} ${r} 0 0 1 0 ${H-r} L 0 ${tm+r} A ${r} ${r} 0 0 1 ${r} ${tm} Z`);
        return;
    }

    // Mathematically generating the custom shape containing inner and outer arcs
    const d = `
        M ${tlW + r} ${tm}
        L ${W - trW - r} ${tm}
        A ${r} ${r} 0 0 1 ${W - trW} ${tm + r}
        L ${W - trW} ${ch - ir}
        A ${ir} ${ir} 0 0 0 ${W - trW + ir} ${ch}
        L ${W - r} ${ch}
        A ${r} ${r} 0 0 1 ${W} ${ch + r}
        L ${W} ${H - r}
        A ${r} ${r} 0 0 1 ${W - r} ${H}
        L ${r} ${H}
        A ${r} ${r} 0 0 1 0 ${H - r}
        L 0 ${ch + r}
        A ${r} ${r} 0 0 1 ${r} ${ch}
        L ${tlW - ir} ${ch}
        A ${ir} ${ir} 0 0 0 ${tlW} ${ch - ir}
        L ${tlW} ${tm + r}
        A ${r} ${r} 0 0 1 ${tlW + r} ${tm}
        Z
    `.replace(/\s+/g, ' ').trim();

    path.setAttribute("d", d);
};

We wrapped all of this in a ResizeObserver. Whenever the browser window resizes, the script recalculates the math and redraws the SVG path frame-by-frame.

The result is a responsive, perfectly stroke-bordered shape that adapts to any syntax language length, without ever distorting its corner radii.

What’s Next?

Writing this exact path logic—calculating where an arc starts, where it ends, and accounting for the radii—is tedious and hard to visualize purely in code.

Because we couldn’t use Inkscape for this, we realized there is a massive gap in modern web design tooling. In the future, we are planning to build a web-based visual node tool tailored specifically for designing parametric SVGs.

Imagine a canvas where you can draw a shape, but instead of hardcoding a width of 100px, you can bind that edge to a variable like label.width + 16px. The tool would instantly generate the complex JavaScript math for you to drop right into your Astro or React components.

Until then, we’ll keep hand-crafting the math, one arc at a time.