4 ms·

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

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.

javajosh 3y ago
>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 https://simpatico.io/svg.md#clocksvg
- gabereiser 3y ago
  +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 https://codepen.io/DirkWeber/pen/YzBYWY
- chefandy 3y ago
  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.
psygn89 3y ago
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/ https://angel-rs.github.io/css-color-filter-generator/
- chefandy 3y ago
  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.
wbobeirne 3y ago
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 https://www.nan.fyi/svg-paths.
- watersb 3y ago
  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-ASM 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 http://genhelp.com/apps/svgpaths.html
BoorishBears 3y ago
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)
- klabb3 3y ago
  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.
  - chefandy 3y ago
    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.
    - BoorishBears 3y ago
      I mean I'd say this is pretty noticeable: https://imgur.com/e6TbXFj 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.
      - chefandy 3y ago
        Yes-- filters and type aren't super consistent. I wouldn't rely on SVG to use either of them for significant elements.
FractalHQ 3y ago
Safari renderer is so bad though, every single complex smil animation I’ve ever built just broke into pieces on Safari.

javajosh 3y ago

>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 https://simpatico.io/svg.md#clocksvg

gabereiser 3y ago
+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 https://codepen.io/DirkWeber/pen/YzBYWY
chefandy 3y ago
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.

psygn89 3y ago

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/ https://angel-rs.github.io/css-color-filter-generator/

chefandy 3y ago
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.

wbobeirne 3y ago

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 https://www.nan.fyi/svg-paths.

watersb 3y ago
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-ASM 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 http://genhelp.com/apps/svgpaths.html

BoorishBears 3y ago

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)

klabb3 3y ago
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.
- chefandy 3y ago
  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.
  - BoorishBears 3y ago
    I mean I'd say this is pretty noticeable: https://imgur.com/e6TbXFj 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.
    - chefandy 3y ago
      Yes-- filters and type aren't super consistent. I wouldn't rely on SVG to use either of them for significant elements.

FractalHQ 3y ago

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