
SVG has more potential - kp25
https://madebymike.com.au//writing/svg-has-more-potential/
======
c-smile
SVG is too complex/heavy for simple tasks and actually is not that good for
complex tasks - more or less complex image requires special editing WYSIWYG
application to create it.

Let's imagine that you need to render simple icon using CSS that should change
color on :hover:

    
    
       div.icon { 
         background: url(simple.svg) no-repeat; 
         background-size: 1em 1em; 
       }
    
       div.icon:hover { ??? what to do here to change the color ??? }
    

Just to render this thing you will need: to download the file, parse SVG,
build DOM tree and "play" that DOM tree on canvas. Each task is not trivial.

While ago I've proposed at w3c-styles simple and lightweight solution for
vector images and shapes in CSS - so called path URLs:

    
    
       div.icon { 
         background: url(path:c 50,0 50,100 100,100 c 50,0 50,-100 100,-100) no-repeat; 
         background-size: 1em 1em; 
         stroke: #000; /* vector stroke color */
       }
    
       div.icon:hover { 
         stroke: #F00; 
       }
    
    

The path uses the same format as "d" attribute in SVG's <path> element:

    
    
       <path d="c 50,0 50,100 100,100 c 50,0 50,-100 100,-100" fill="#000" /> 
    

Parsing is trivial and rendering of such "images" is just a set of primitive
drawing operations. No DOM or anything like that.

More on the subject (with illustrations in Sciter) :
[http://sciter.com/lightweight-inline-vector-images-in-
sciter...](http://sciter.com/lightweight-inline-vector-images-in-sciter/)

~~~
yoz-y
I would argue that rendering simple paths is not really the goal of CSS (or
implementing icons for that matter). We already have images, we already have
fonts. If there is a third way to render simple vector paths then
transitioning to something more powerful (when somebody decides that they want
colour in their icons) will be just more painful.

~~~
masklinn
> I would argue that rendering simple paths is not really the goal of CSS

The goal of CSS is styling and decoration, simple vector paths seem comparable
to border images (and border image slices) and a simple and great way to
implement responsive decorative elements.

------
ptrincr
Look no further than D3.js as an example of the kind of visualisations which
are possible with SVG.

[https://github.com/d3/d3/wiki/Gallery](https://github.com/d3/d3/wiki/Gallery)

At least this is what introduced me to working with SVG. As much as I like D3,
mainly for charting, it's not the easiest thing to pick up.

~~~
th0ma5
If you skip the whole .enter() pattern then D3 is more approachable, IMHO.

~~~
Hupriene
d3v4 is improving the logic around .enter() a bit. See
[https://medium.com/@mbostock/what-makes-software-
good-943557...](https://medium.com/@mbostock/what-makes-software-
good-943557f8a488) Search for "Removing the magic of enter.append"

~~~
vanderZwan
You can also use Vega or Vega-Lite and let d3 be the low-level architecture:

[http://vega.github.io/](http://vega.github.io/)

[https://www.youtube.com/watch?v=Y8Fp9z-9DWc](https://www.youtube.com/watch?v=Y8Fp9z-9DWc)

[https://vimeo.com/177767802](https://vimeo.com/177767802)

I especially like how they handle interaction (event streams/signals; about
six, seven minutes into the youtube video).

Supposedly there's a big update coming late fall, that upgrades vega and vega-
lite to the latest version of D3. It also (finally) introduces the interactive
bits to vega-lite.

------
igt0
SVG is amazing, my main concern about it. it is because it creates a huge
burden to browser developers. The spec is _huge_ [1]. And some parts are
outdated[2].

[1]
[https://github.com/WebKit/webkit/tree/master/Source/WebCore/...](https://github.com/WebKit/webkit/tree/master/Source/WebCore/svg)
[2] [https://developer.mozilla.org/en-
US/docs/Web/SVG/SVG_animati...](https://developer.mozilla.org/en-
US/docs/Web/SVG/SVG_animation_with_SMIL)

~~~
amelius
> SVG is amazing, my main concern about it. it is because it creates a huge
> burden to browser developers.

Yes, it would have been better if SVG was designed _on top_ of something
simpler; and this something simpler could be implemented by browser
developers. Probably, such an approach is more secure too. But, I guess it is
too late now.

~~~
bobajeff
I imagine they could implement it on top of Canvas/WebGL.

~~~
josephcooney
Like [https://github.com/canvg/canvg](https://github.com/canvg/canvg) (which
AFAIK doesn't do hit testing like 'real' SVG, but is a promising start).

------
formula1
I am using svgs in a project now.

\- The first issue was the designer Im working with didnt know how to export
to svg.

\- Second problem is my svgs ended up with very weird numbers and groups. Such
as the main groups offset was -60, 190 then another group to dlightly
compensate. Then the paths themselves compensated further.

\- Another issue is "cutouts" are nonintuitive for designers and also complex
to reverse when they are curves.

\- Another issue is linking and styling to an external svg. Despite you can
put them in an image tag, it cannot be styled this way. If you put it inside a
use tag, styling externally requires targeting ids.

\- anothwr issue is that they dont follow the normal rules of width/height. By
default they are 300x150 and takes a bit of patience to ensure they exist as
100% width (which I assumed was default)

Other than that, I am quite pleased with the format and am expecting great
things for it!

~~~
Falkon1313
Hand-written SVG, treated as elements of the markup (rather than an external
black-box object or image), usually works well. It's easily* styled, scripted,
and has good clean structure and values. There are, however, a couple of
problems.

Hand-writing a complex graphic is difficult! (ex: editing coastlines on a map)
Unfortunately, current WYSIWYG editors produce bloated, illogical output full
of bizarre measurement schemes, unnecessary translations, and incompatible
proprietary garbage - sort of like the bad old days of Frontpage and
Dreamweaver.

*There are also some quirks in both styling and scripting them (as others have mentioned, height is one, another is having to use NS versions of DOM functions instead of normal ones - but only sometimes).

Maybe by the time SVG turns 21, those things will be mostly sorted out. It's
still in its awkward teenage years.

~~~
ajstarks
An alternative to to hand-written SVG is to use a (Go) library like svgo [1]
to generate the markup programmatically. More info is also at [2] and [3]

[1] [http://github.com/ajstarks/svgo](http://github.com/ajstarks/svgo) [2]
[https://speakerdeck.com/ajstarks/the-other-side-of-go-
progra...](https://speakerdeck.com/ajstarks/the-other-side-of-go-programming-
pictures) [3]
[https://www.youtube.com/watch?v=nuDO1oQxARs](https://www.youtube.com/watch?v=nuDO1oQxARs)

------
CiPHPerCoder
SVG also has more risk: stored XSS, which isn't something you'd expect from a
file whose MIME type starts with "image/".

[https://github.com/w3c/svgwg/issues/266](https://github.com/w3c/svgwg/issues/266)

~~~
ogig
And more. I got a bug bounty by uploading a malicious svg witch would get
parsed and fetch external resources, even read local images.

If your app receives and parses svg server side you might have a hole there.

~~~
happyslobro
Forgive my ignorance, but why would anyone ever need to parse an SVG server
side?

Now that you got me thinking, SVG might be a decent, if somewhat large, format
for accepting sketches from users. Something like "draw a map, and we'll find
it on Google maps for you". But I am certain that that (SVG user input) isn't
a thing yet.

~~~
nitrogen
Maybe you need PNG thumbnails for user-uploaded SVGs.

------
Pxtl
When I first heard about svg, I was excited. Finally everybody getting behind
a vector graphics format... and since then the more I see the worse it looks.
A boosted, text-oriented, JavaScript-enhanced resource monster. All the worst
attributes of HTML, but in vector graphics.

Did anybody want this? I know I wanted a jpg of vector graphics - a resource-
friendly small system for embedding vector graphics into things. Something
where I don't have to worry about an image having an xss vulnerability.
Something that degrades gracefully so it can still work in some form on an
anemic piece of equipment.

But no. We throw bigger and heavier hardware at more trivial problems.

~~~
michaelchisari
Are vector graphics a trivial problem? I can't say that they are.

~~~
kensign
SVG is an untapped technology. It functions as an embedded document. When used
within the Object tag, it can run javascript and CSS and ideally renders
complex graphics with a much smaller payload. Also, they look amazing on all
devices as they use the browser's rendering pipeline. SVG has been a fully
supported standard for years.

[https://sarasoueidan.com/blog/art-directing-svg-
object/](https://sarasoueidan.com/blog/art-directing-svg-object/)

------
Animats
SVG as a representation language for draw programs is pretty good. Most draw
programs don't utilize it fully. While SVG can represent dimensions as inches
or mm, most programs only support dimensions as pixels, which makes SVG
useless for CAD drawings.

If you need drawings with lines and boxes, Inkscape is very helpful. Most
drawings in Wikipedia are in SVG, and many were drawn with Inkscape. You can
update drawings in Wikipedia by bringing them into Inkscape and editing them,
then checking them back in as an update. It's not a read-only notation, like
Postscript.

Manually tweaking SVG text, though? Painful. It's encapsulated like XML, so
you can, but you probably shouldn't. After you've done that, most draw
programs won't be able to handle the fancy stuff. And really, drawing by
typing text is like pounding a screw with a hammer.

~~~
the8472
> Manually tweaking SVG text, though?

Well, you could embed xhtml into svg and use regular html styling and text
layout instead.

~~~
OliverM
Only supported in Chrome and FF, no?

~~~
the8472
I think among the browsers it's only IE that doesn't support <foreignObject>,
edge does.

But of course then there also is the issue of SVG editing tools that don't use
a browser rendering engine

------
contingencies
Timing! I just pulled a 4AM night last night creating my first ever Lua
library, _svglover_ [0], to facilitate SVG display in LÖVE[1], for a
roguelike. Motivation was primitive[2] posted[3] last week. It's actually
pretty easy to work with, even for lazy coders who find regex parsing
acceptable like me[4] :) I'm no oldschool demo coder, but the coordinate
transformation system is basically just a simple layer on top of an OpenGL
pipeline. You don't even need viewbox, just groups with <g></g>

[0]
[https://github.com/globalcitizen/svglover](https://github.com/globalcitizen/svglover)
[1] [http://love2d.org/](http://love2d.org/) [2]
[https://github.com/fogleman/primitive](https://github.com/fogleman/primitive)
[3]
[https://news.ycombinator.com/item?id=12539109](https://news.ycombinator.com/item?id=12539109)
[4] _Make it work first, then make it work fast_.

------
niedzielski
Gordon Lee[0] has made a ton of sophisticated SVGs for Wikipedia and its
projects and recently presented at Wikimania. The Burj Khalifa[1] is one of my
favorites. Inspired, I wrote this short script for fun that chops up a Blender
file into PNGs[2] which I used to generate an animated SVG.

[0]
[https://en.wikipedia.org/wiki/User:Cmglee](https://en.wikipedia.org/wiki/User:Cmglee)
[1]
[https://upload.wikimedia.org/wikipedia/commons/0/06/Burj_Kha...](https://upload.wikimedia.org/wikipedia/commons/0/06/Burj_Khalifa_floors.svg)
[2]
[https://github.com/rndmem/ndice/blob/master/blend/d/render](https://github.com/rndmem/ndice/blob/master/blend/d/render)

------
iamleppert
SVG works for the trivial graphics use cases that are presented. But it falls
apart for anything that requires more complexity, or dealing with documents of
arbitrary complexity.

There is little provision for incremental rendering, and poor control and
visibility of the internals of the rendering process. Once you dump your SVG
to the browser, that's basically it. There's no way to find out what is going
on.

It's really nice to just set a break point in your imperative Canvas code, or
WebGL code and see exactly what is happening, and use all the standard
debugging and profiling techniques. I have yet to see the same for SVG.

~~~
e1g
We solved this issue by using a rendering engine that has rich tooling, strong
profiling and inspection capabilities, and is centered around predictability -
React.

D3 v4 provides all of its goodness in loosely coupled modules with clear
boundaries, so you can use it for all heavy lifting that it's amazing at
(layouts, animations, shapes), then setState() all over the place to reflect
the results in the DOM. Performance wise, the only limits we are hitting are
native SVG limits on the number of nodes.

Our visualisations are complex (science and finance, to an expert and expertly
distracted audience), but no more complex than the rest of the app. React
paradigm is predictable, well known, and has a deep user base to lean on.
Performance and inspection tools are solid. And the only difference is that
the render method has a <g> instead of a <div>.

~~~
Chris_Newton
I’ve done similar things with React and SVG and I concur. As with scaling
anything up using React, you need to be careful about how you structure your
components so you can write shouldComponentUpdate everywhere you need it to
get acceptable performance. That in turn means you have to be careful about
how you represent the underlying data and any further data you derive from it
to use when rendering your SVG. However, assuming those things have been done,
I have found React+SVG to be a reasonably effective combination so far.

------
edejong
Three years ago I was amazed by the versatility of SVG when I discovered it
through D3 and it inspired our graphical designer to ask us designs never
before seen in SaaS applications. Once you're willing to dive into the
specifications, you'll find a treasure trove of possibilities.

There are some caveats beginning users should be aware of. First of all,
better forget multi line text or sophisticated text layout within the SVG. I
still think that's really missing in the current specification. As a commute
project I once wrote the dynamic programming layout of Knuth (used in TeX) for
SVG and JavaScript, but it was slow and didn't allow for multi line
selections.

Another problem is rendering speed. SVG renderers can be fast, but you have to
know what can be optimized by the gpu and what requires the CPU.

~~~
comex
> First of all, better forget multi line text or sophisticated text layout
> within the SVG.

Can't you do it by embedding an HTML document into the SVG with foreignObject?

(edit: corrected name)

~~~
edejong
You are absolutely right [1]! It is not supported by IE, unfortunately.

[1] Made a small jsfiddle:
[https://jsfiddle.net/7y27wfuy/](https://jsfiddle.net/7y27wfuy/)

------
thom
Annoyances with SVG:

\- Modularity is tough: you can nest <svg> or <g> elements with various
transforms, but there's no first class layout concept.

\- Pixel imperfections: browsers don't always render things 'nicely', and all
sorts of horrid aliasing can happen.

\- Styling options: all sorts of simple stuff like a double outline of a shape
is really difficult (without extremely complex filters)

\- Export: taking an SVG and exporting it as an image has lots of
complications, especially with embedded fonts.

All that said, the output is mostly okay, and it's possibly the easiest
graphical technology to integrate with React-style frameworks.

~~~
taivare
if anyone has a link etc. where I can find more / better info on exporting an
SVG as a image. It would be appreciated.

~~~
ceautery
A poor man's version is to draw it onto a canvas and save the canvas, e.g.:

    
    
        var svg = '<svg version="1.1" xmlns="http://www.w3.org/2000/svg" height="100" width="100"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" /></svg>';
        i = new Image();
        var cnv = document.createElement('canvas');
        var ctx = cnv.getContext('2d');
        i.onload = function() {
            ctx.drawImage(i, 0, 0);
            console.log(cnv.toDataURL());
        }
        i.src = 'data:image/svg+xml;base64,'+ btoa(svg);

~~~
thom
Now copy across all styles, embed all fonts and external images etc etc etc.
Nightmare.

------
amelius
I'm wondering if it would be possible to parameterize SVG files. Suppose I
have an icon in the file "icon.svg", it would be awesome if I could say in the
CSS:

    
    
        .icon:hover
        {
            background-image: url("./icon.svg") main-color=#ff0000;
        }
    

where "main-color" is a parameter of the SVG file. So the icon turns red upon
hovering (just an example).

Is something like this possible?

~~~
emilsedgh
background-image: url("./icon.svg?main-color=ff0000")

And serve icon.svg dynamically.

As others have mentioned, only for colors, there are easier ways.

But using this technique you can do anything.

~~~
marcosdumay
Just be wary of code injection. It is XML, so it should be easy on any
framework.

------
shurcooL
I really like SVG and this was a great article that contained many things I
didn't know.

That said, I _tried_ to use SVG for something as simple as displaying some
multiline monospaced text with whitespace preserved, and found it's either
really hard, or actually not possible (unless you position each glyph
manually). Is that really the case?

~~~
mrb
Why use SVG? Why not use CSS "white-space: pre-wrap"?

~~~
shurcooL
Well, I wanted SVG for its other features. Text is just a component of what I
wanted to draw.

------
mojuba
SVG has another interesting application: it can be used as a UI language for
graphically rich and complex interfaces, almost game-like but not quite. You
often see this kind of interfaces in audio, i.e. soft synths/effects. Though
you will need to create your own extension to the markup and a subsystem that
supports it in your OS, which in the end is not too complicated.

(Shameless self-plug as an example of an SVG-based GUI:
[https://itunes.apple.com/us/app/magnetola-vintage-
cassette/i...](https://itunes.apple.com/us/app/magnetola-vintage-
cassette/id1027234156))

------
tofflos
I'd use it a bit more if I could style it with CSS without inlining the SVG
source code within my HTML.

~~~
gotofritz
There are JS libraries that will inline SVG sprites for you

------
robszumski
As a designer using SVGs across the web, there are a few drawbacks that are
easy to fix:

\- platforms like Twitter and Google Slides not accepting SVGs. I assume this
is due to security concerns.

\- Using SVGs on a website doesn't render with included WebFonts like normal
text would. This leads to outlining text, which is a huge maintainability
burden.

\- Graphics programs have tones of SVG bugs. Even "leading" software like
Illustrator and Sketch have a lot of bumps in the road.

Overall really excited about SVGs and use them as much as possible.

------
xnmvvv
The main problems I've experienced:

* SVG's performance degrades sharply after a few hundred objects, then you have to use canvas or WebGL, or prerender to images * browser differences

otherwise good

------
Hyperized
We use SVG extensively at: [https://fd.nl/krant](https://fd.nl/krant)

------
flatline
Generally I agree that SVG is awesome, but there are a variety of cross-
platform issues with it and I worry it does not get enough serious use to see
them addressed. The status quo is pretty good, but if you run into issues
there is not always a work around.

------
dahart
I'm quite excited for SVG absolute positioning to become available in all
browsers. It'll mean real responsive images, not just resizing, being able to
move parts of the SVG instead of scaling proportionally, as the image is
resized.

------
wrong_variable
The issue that makes me not enjoy working with svg is the lack of negative
scaling values. It makes it hard to do complex transformations on your vector
widgets. Canvas is so much more better.

~~~
formula1
Style= "transform : scale(-1, 1)"

I remember this was very important fir a personal logi of mine

~~~
carapace
Hey! Thank you so much. I was working in Jupyter with Sympy to generate SVGs
illustrating geometric relationships etc. (proofs of Pythagorean Theorem and
stuff like that) and I had to subtract the y values from the height of the
viewport to use the Sympy objects to generate coordinates for SVG.

This is so much cooler. :-)

------
bradoyler
This is why d3-node is the way to go...
[https://www.npmjs.com/package/d3-node](https://www.npmjs.com/package/d3-node)

------
aikah
The second example is supported neither in Edge nor in Firefox, that's the
problem. Extremely poor SVG support accross browsers.

~~~
itsnotvalid
Agreed. Just launched it over with different "modern" browsers and was
disappointed by the support.

------
SFJulie
SVG? Wasn'it the new tech (10 Years after ARM) in 2000 that was supposed to be
so wonderful it would be very easily adopted?

We are in 2016 ... ARM are still promising and SVG is still the new promising
thing. Well, SVG has not taken a wrinkle, nor grown up a lot. It is still
overpromising and complex.

Let me watch my backyard cristal balls for new innovations..

DCOM and RPC maybe? Oh, crumbs, it is called the cloud. All FW problems solved
by using HTTP with cookies that are so safe.

I can't wait for the next new thing... GUI, Universal Display format (aka
display postscript from NeXT), Xanadoo, XUL, sprites, linear framebuffers with
blitters?

