Hacker News Reader

Comment by chefandy | Hacker News Reader

Maybe it's just because I have so much experience with design and visual art, but I think SVG is one of the most, if not the most underutilized web format. It's great for the self-contained static vector graphics that it's most commonly used for, but it can do so much more. SMIL animations can be a little clunky, but having an alternative to gif and video that doesn't require JS is pretty rad-- especially for throbbers and things like that. That you can work with SVGs so easily using JS and CSS is awesome. You can even build your own filter stacks using its built-in effects... though last time I did that with a detailed full-screen art piece, performance was rough.

View on HN

>SVG is one of the most, if not the most underutilized web format

Yes. I think the problem is that you have to learn to author with it before you program with it, and the learning curve is actually fairly steep. OTOH the feedback is immediate and satisfying.

Personally, I've ignored SVG's built-in animation capabilities in favor of pumping DOM modifications into the scenegraph with a (requestAnimationFrame) timer. This gives you exquisite control requiring very little code.

https://simpatico.io/svg.md#clocksvg

+1 for requestAnimationFrame. SMIL animations are cool until you try doing 1,000 of them. Still, I do agree that SVG is underutilized. Not only can it do so much more but it has effects that can be used in conjunction with DOM elements. Things like dropshadow, glow, blur, greyscale, duotone, etc. Check out this SVG glitch effect [0]

[0] https://codepen.io/DirkWeber/pen/YzBYWY

Yeah it's great with JS, and I use it for most dynamic things I do with SVG. I'd still stick with SMIL for little animated icons that would be deployed multiple places and other little problems like that.

> Yes. I think the problem is that you have to learn to author with it before you program with it, and the learning curve is actually fairly steep.

Good point.

Totally agree. I bookmarked this guide that hit the top of HN a few weeks back, a good primer on how to get started manually programming paths, which unlocks a lot of cool dynamic SVG and animation opportunities: https://www.nan.fyi/svg-paths.

I try to keep my SVGs simple, and often tweak them by editing the XML data in a text editor. (Linus Torvalds relaxes with assembly language, I make image files smaller...) https://www.phoronix.com/news/Linus-Torvalds-Relax-Inline-AS...

This simple iOS app helps me play with path changes, sort of a unit-test use case for me:

http://genhelp.com/apps/svgpaths.html

I wish <img> would accept `fill` property through css. There's a neat trick to colorize SVG's: https://angel-rs.github.io/css-color-filter-generator/

There's definitely some super clunky stuff, there. "This is an image! no... wait... this is an embedded document! no... hold on... it's an ima... hmm...."

It all makes sense from a technical perspective when you dig into it, but it's totally counterintuitive in surprising ways, sometimes.

Safari renderer is so bad though, every single complex smil animation I’ve ever built just broke into pieces on Safari.

Funny you say this, I spent a good 5+ hours yesterday trying to get an SVG of a UI mockup to render properly on Safari before giving up and implementing it in HTML.

What was especially annoying was that different representations of the exact same SVG would behave differently (inline-svg vs img+src vs object)

SVG has… weirdnesses. I couldn’t say exactly what they are. But it feels like an older format from an XML-centric era. It also feels fairy lax on “optional features” and ambiguous spec (although I’m not sure this is true). There are noticeable differences between different rendering engines.

Most of drawing works fine as markup. However, animations and simple state changes are awful. CSS is much easier to use for some of those purposes.

I’d very much forgive SVG for its clunkiness, after all it’s old yet very powerful today. It’s a prime candidate for a revamp.

Noticable differences between rendering engines for what? Sometimes type can be janky, but no moreso than in html/css, and in SVG you're generally turning type into vector outlines. For graphics rendering, it's completely accurate in any environment I've used it in, and that's working with very very fussy brands.

I mean I'd say this is pretty noticeable: https://imgur.com/e6TbXFj

Same screen, same zoom levels. Viewbox properly set, height/width set, confirmed compliant units. Switching between img/object would get it unblurry but then lose the embedded image data. Switching to inline-svg would in turn get the image data working but the drop shadow was completely broken.

Yes-- filters and type aren't super consistent. I wouldn't rely on SVG to use either of them for significant elements.

I don’t recall exactly. Filters or blending modes probably.

How was it made?

Figma, and I got to the point of running it through SVGO and hand patching any constructs that had known issues with Safari.

Going based off the types of bugs I was seeing alone I wouldn't trust SVGs for anything but the most basic shapes.

Quickly rifling through a the sites of some huge extremely valuable brands, Apple, Coca Cola, Walmart, Target, and Toyota all use SVG for their logos. SVG is not the right choice to lay out documents. It's not a replacement for PDF. It's a perfect choice for creating discrete vector graphics.

Reply on news.ycombinator.com