An SVG Wish List

CSS and SVG are great together. But I’m tired of translating my design intent to increasingly complicated transform rules which don’t even work consistently across browsers. In a world where elements don’t push each other around, why can’t I change x, y, cx, cy, width, height, r, rx, ry or even viewBox attributes from CSS?

Tools like GSAP are great, but I’d use them far less often if I could reliably transition every display property within my stylesheets.

The rx and ry attributes let us round the corners of a rectangle. But there’s more to life than rectangles, darn it!

Let’s say we have a simple image like this one:

Its straightforward shapes make it easy to tweak and manipulate later:

<svg viewBox="0 0 100 50" width="100" height="50">
  <polyline points="10,40 50,40 50,10 90,10" stroke="#456BD9" stroke-width="3" stroke-linecap="round" stroke-linejoin="round" fill="none"/>
  <polygon points="80,0 100,10 80,20" fill="#456BD9"/>
</svg>
Code language: HTML, XML (xml)

But if we want to round its corners…

…we have to convert every shape to a <path>. The same is true if you only want to round some corners of a rectangle.

I’d love to have a set of rounding properties I could apply to any shape, with results similar to Illustrator’s Live Corners.

The use element is pretty neat, but it’s often kinda lonely:

<svg>
  <use xlink:href="#icon"/>
</svg>
Code language: HTML, XML (xml)

It’d be super cool if we could embrace an even more concise shorthand (also removing vestigial XML xlink noise while we’re at it):

<svg href="#icon"></svg>
Code language: HTML, XML (xml)

(I saw Chris Coyier suggest something similar here and fell in love with the idea.)

While SVG fully supports bitmaps via the image element, that element does not allow srcset or sizes like its HTML5 equivalent. This would help optimize pages like our portfolio, which display bitmap screenshots within stylized vector containers.

Whenever I want an SVG image to align with an adjacent element, I almost always have to overlap it by a pixel or two to avoid a visible seam where the anti-aliasing of the image edge is a bit fuzzy. Being able to apply shape-rendering: crispEdges but only to the viewBox edge would remove dozens of -1px property values from my CSS.

Feature queries are awesome, but they come up short when SVG’s standards are out of step with HTML and CSS. An example:

@supports (transform: rotate(45deg)) {
  /* … */
}
Code language: CSS (css)

This feature query will evaluate to true in Edge. But Edge doesn’t support CSS transforms on SVG elements, and there’s no way to specify an element as part of the support condition, which means you can’t rely on feature queries for SVG.

One of the biggest reasons people continue to use icon fonts in spite of their drawbacks is so their presentational assets can easily inherit the parent element’s text color. I regularly use plugins like postcss-inline-svg to embed and customize the appearance of presentational assets:

@svg-load foo ("images/foo.svg") {
  fill: var(--color-blue);
}

@svg-load foo-enter ("images/foo.svg") {
  fill: var(--color-cyan);
}

.foo {
  background-image: svg-inline(foo);
}

.foo:hover,
.foo:focus {
  background-image: svg-inline(foo-enter);
}
Code language: CSS (css)

The danger with this approach is the lack of asset caching and bulkiness of the resultant stylesheet. It would be awesome to have a built-in and performant way of pulling off something so commonplace.

It’s awesome that SVG can include stuff like JavaScript. But sometimes those capabilities can get in the way, like when we want to upload SVG files into WordPress or load our icon sprite from a CDN.

It would be cool if there were some way of telling the browser, “Hey, this SVG is just an image, so don’t evaluate any JavaScript and please let me do all the normal image stuff with it, kay?”

I think SVG is awesome. But as with our work, its shortcomings are best exposed through actual usage… and best resolved by a cycle of discussion and iteration.

So let’s discuss. What’d I miss? Which ideas are misguided or worth fighting for?