An SVG Wish List
At 4/19/2024
It’s no secret: I love SVG. But it isn’t perfect. Here are some features I hope eventually come to the standard, if not in SVG 2 then in some future successor (or even a preprocessor).
Expanded CSS Layout
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.
Round All The Things!
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.
use
Simplified Single use
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.)
Responsive Bitmaps
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.
De-Fuzzified Edges
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.
@supports
Support
Better @supports
Support
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.
Inherited Color in External 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.
Simplified Security
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?”
Hopefully More…?
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?