Bridging design and code through technical experiments with SVG

Wiring the first feedback loop between input and visual output

SVG's core attributes are just numbers in the markup. That made range sliders a natural fit, a decision I wrote about. A min, max, step size, and current value was all it took to put direct visual control in a user's hands. Targeting foundational attributes like opacity, stroke-width, width, and height first confirmed the pattern worked reliably.

CHALLENGE

But not every attribute was a single number.

Solving scaling problems by adopting SVG's built-in pattern tag

Pattern tiling with CSS background images worked until rounding errors and sub-pixel gaps exposed the limits of custom calculation. SVG's native <pattern> element handled the math internally far more reliable and even unlocked pattern rotation.

Overcoming transform complexity and unpredictable transform origins

Unlike simple numeric attributes, transform values are compound strings — rotate, scale, and translate chained together, each dependent on the others. That required its own parsing system just to wire up controls.

transform="rotate(90 500 400) scale(1 1.2) translate(0 -50)"

CHALLENGE

Harder still, transform order matters: the same operations in a different sequence produce a different result. And scaling shifts the coordinate system entirely, making transform-origin: center unreliable.

SOLUTION

Finding the solution had me scour the internet down many dead ends, but a comment in a Stack Overflow post helped me piece together a workaround. The solution was to lead with rotate using its explicit center coordinates, then wrap scaling in a translate/reverse-translate pair to compensate. Keying this complexity into a single slider unlocked a new category of designs: elements that rotate, shift, scale, and assemble into parabolic aand other geometric forms.

Animating SVG gradients in ways CSS could not support at the time

Having hit dead ends animating gradients through CSS in the past, it was one of the first things I tested with SMIL and it worked. A video of me explaining the technique reached 10,000 views, a signal that others had hit the same wall.

Researching SVG's uncertain animation future and publishing the results

Customer requests pushed animation up the priority list, but choosing the right tool mattered. GSAP was an option, but relying on an external library conflicted with SVG Backgrounds' self-contained, copy-and-paste designs. SMIL kept the animation inside the file itself avoiding dependencies.

The problem was an influential article had declared SMIL dead. Researching the claim uncovered a more optimistic picture: the deprecation decision had been reversed, and browser support had improved as SMIL outlived the browsers that made it problematic. I published my findings in an in-depth article and made the call to ship with SMIL.

Building animated preloaders by coordinating multiple animation parameters

Preloaders are typically graphics with a simple repeating motion sequence, a fitting use case for SMIL, especially since both the graphic and animation are stored in a single self-contained file. Compared to animated GIFs, equivalent designs came in 20-40x smaller. Building a variety of preloaders meant experimenting with SMIL's full range of animation parameters and targetable elements. That exploration became a product: a collection of 24 preloaders for SVG Backgrounds members.

Witnessing first-hand how design choices increased file size

The obvious culprits were easy to spot: too many elements, complex paths with dense anchor points, coordinates carrying way too many decimal places. The less obvious patterns emerged when comparing my software's raw output to code after a pass through an optimizer.

Changing my design approach to produce smaller, more efficient SVGs

Once I've spotted common causes of character bloat, I started thinking about ways around the problem, leading me to consider file size as a design constraint.

For instance, Illustrator makes it trivially easy to add anchor points and surprisingly hard to remove them. Getting them out safely, without affecting the visual, meant building a toolkit of strategies:

• Smooth tool simplifies curves, often with fewer anchor points
• Remove points hidden behind other elements or off-screen
• Merge separate shapes into a single path
• Use a plugin to reduce unnecessary anchor points mathematically
• SVG optimizers rewrite paths with fewer characters

Writing SVG markup directly to achieve maximum optimization

Design tools have a ceiling. Some optimizations are only possible when writing markup directly.

The perfect example is that <use> clones complex elements by reference to avoid repeated markup. Nesting those clones made intricate designs like halftone patterns achievable with minimal code.

Beyond that, there's a small list of other techniques, such as grouping elements to share <fill>, <stroke>, and <opacity> attributes trimmed the redundancy that exporters routinely leave behind.

Documenting my optimization discoveries into an educational resource

After years of working with SVGs, I decided to write about my optimization strategies. I pulled together every technique I'd considered, tested, and applied into a complete reference for reducing SVG file size. It has since brought in consulting inquiries from teams dealing with these types of problems at scale.