6 ms·

SVG: The Good, the Bad, and the Ugly (2021)

85 points by fanf2 2y ago

lilyball 2y ago
Previous discussion (2021): https://news.ycombinator.com/item?id=26114863 https://news.ycombinator.com/item?id=26114863
- dang 2y ago
  Thanks! Macroexpanded: SVG: The Good, the Bad and the Ugly - https://news.ycombinator.com/item?id=26114863 https://news.ycombinator.com/item?id=26114863 - Feb 2021 (219 comments)
eseidel 2y ago
I brought SVG to WebKit, back in 2005. So I guess I'm part of the problem. I generally agree with the article, SVG is bloated and confused about what it's trying to do. You're not alone in wanting something better. We had this same problem in Flutter. Ian Hickson (of HTML5 fame) made some attempts at seeing a better future you might be interested in: https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.8crpi5305nr https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...
- airstrike 2y ago
  IconVG was looking promising but it seems abandoned at this point... The README doesn't mention anything and the repo isn't archived, but the last real commit is from 3+ years ago https://github.com/google/iconvg https://github.com/google/iconvg
  - hgs3 2y ago
    There is also TinyVG [1]. See the previous discussion on HN [2]. [1] https://tinyvg.tech/ https://tinyvg.tech/ [2] https://news.ycombinator.com/item?id=35227635 https://news.ycombinator.com/item?id=35227635
    - Lammy 2y ago
      And HVIF: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html http://blog.leahhanson.us/post/recursecenter2016/haiku_icons... https://news.ycombinator.com/item?id=40196333 https://news.ycombinator.com/item?id=40196333
- rikroots 2y ago
  That document has a really good summary of all the problems surrounding text rendering onto a canvas[1]. Having been through the pain of implementing such a system for my canvas library earlier this year I can sympathise with the decision not to include it in the proposed format's MVP. What did disappoint me when reading the doc was the decision to place accessibility at the bottom of the list of priorities for the proposed format. There's a footnote that says "Accessibility being low on this list reflects that the needs can be met outside the format as well, and supporting them inside the format would be beneficial only to the extent that it provides greater flexibility to designers", but to me that seemed back-to-front: why not tell the engine/device that will display the image the (preferred) requirements for accessibly rendering (or describing) that image by including such data in the format, rather than hoping that the engine/device will make "best efforts" to support people with accessible needs in some unknowable way? [1] Text section in doc - https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.2fvcp5gqzghd https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...
deleted 2y ago
[deleted]
jauntywundrkind 2y ago
With great powers come a lot of people very mad about how we miuse them & that we might not be able to reimplement it all in a weekend. > This problem of SVG is actually just the problem of the web in general. It’s scope is huge, it’s bloated and hard to work with. > SVG is nothing you could implement in a day. Or a week. Or a month. The huge amount of specifications, that are most often only partly implemented, makes it very hard to overview what supports what, confusing the user as to what features they can actually use if they want their SVG file to be universally supported That just doesn't seem like a big problem, in fact. The webs gotten pretty good & the standard is pretty high. Yes people have some real pains but also my word, software is a world of contrived griefs, nonsense beefs. People love grandstanding against things.
- bobthepanda 2y ago
  yeah, this doesn't really touch on the beef i have with SVG. the problem I have is that SVG is complicated like the old web, but unlike the new web we also haven't created new standards like Flexbox and Grid that let you ignore the problems with the old ones. For example, in HTML-land we have had z-index for a while to describe the order in which elements should render on top of each other. This doesn't exist in SVG, so the order of elements is the order that they are declared in markup, which can lead to very kludgy things. In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. These are all things solved in SVG1.2, but of course the classic issue is that barely anyone has bothered implementing SVG1.2.
  - felixfbecker 2y ago
    > In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG. The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.
DrDroop 2y ago
There was a time that SVG was going to replace flash, or something like that, but these days people just use the "simple" subset. I've seen multiple implementations for the vector graphics based on compute shaders, impressive stuff, can render the tiger svg with no problem. Parsing the bezier curves out of the xml is not that hard compared to all the work needed the have this work on the GPU. Most people also don't understand XML, I'm building a sort of compiler for it with full support for Namespaces, Schema, XLinks and all of that, boring stuff that needs to be done, I don't understand why this needs to be your problem though and even then those standard are not THAT hard. You will only understand XML if you need to use XML. Yes XML is verbose but also your mom is fat and you still love her don't you? Developers look at me weird when I start talking XML, like I am some sort of boomer that want to limit women's right to choice or something like that. Better not to mention it, or I'll have to listen to them explaining why JSON is just better for hours on end without ever considering the strange bizz requirements I labour under.
- bawolff 2y ago
  > I'm building a sort of compiler for it with full support for Namespaces, Schema, XLinks and all of that, boring stuff that needs to be done, I don't understand why this needs to be your problem though Well if you just do the generic version uncritically, you end up with all sorts of security vulnerabilities. Things like xml external entities, xinclude have causes quite a few security issues over the years when processing svgs.
dagss 2y ago
Not about SVG as such, but the XML nature of SVG. I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job. JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format. And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...]) I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.
- mofosyne 2y ago
  Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.
- diegof79 2y ago
  The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain). However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)
- lenkite 2y ago
  XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc. We just need browsers to implement SVG 2.0
  - mort96 2y ago
vg_head 2y ago
One other thing that is a bit weird about SVG is how some parts don't feel tightly integrated. For example, paths and SMIL events have their own syntax. And a lot of APIs related to them seem to be either abandoned, deprecated, or just hard to find. There's also SVG2 which is confusing, as it seems like no browser will ever implement it fully. That being said, SVG allows you to create quite beautiful and complex effects with relatively little code.
deleted 2y ago
[deleted]
omoikane 2y ago
> Bezier curves, elliptic curves, fills, outlines and gradients should mostly suffice to represent every unanimated SVG There are also filters, pattern fills, dashed strokes, etc. Also, mesh gradients (as supported by Inkscape) are immensely powerful but not yet standardized. A lot of people are surprised to find <script> in SVGs and maybe that's a bad idea, but everything that someone thought was pure unnecessary bloat are actually features that users depend on. Maybe there is a cleaner and purer universal standard that covers everyone's use cases, but users already have SVG and would rather see incremental improvements here, as opposed to waiting for a new thing that is less capable.
- felixfbecker 2y ago
  <script> in SVGs is also not a concern nowadays if you use a CSP (even for user-uploaded content).
- felixfbecker 2y ago
  It would be amazing if browsers just implemented all the features that were already specified in SVG2. Currently it seems like any new spec work on features that would be amazing for the web (e.g. SVG connectors) has been completely paused because browsers haven't even implemented what has already been spec'ed over a decade ago.
- WillAdams 2y ago
  I found the <script> capability very useful for making interactive SVGs for CNC assembly diagrams for the Shapeoko 2.
cdrini 2y ago
Not a huge fan of this hot-take that pops up every once in a while. I love SVG and use it all the time, and think it's a fantastically designed language and system. The places where it's lacking have nothing to do with bloat or verbosity. It's biggest short-comings are all fixed in SVG 1.2 (flowable text, stroke placement on path, etc), but it's just _still_ not implemented anywhere. And on top of that, some auto-layout options would be quite handy... or maybe some charting primitives. A few responses: 1. The spec is too long/complicated: Yeah that's cause graphics is inherently complicated. You can't simplify out the core of the thing you're trying to do. Sure "shapes" are simple, but anything that would be actually useful involves paths (interpolation modes), transforms, groups, blend modes, effects, gradients, masks, stamps, FONTS (don't get me started on fonts!) typography, and on and on. And that's just stationary 2d graphics! Add animations in there and it's a whole other deal. Strip it all out and yes, your spec is shorter. But then you need like 20 different file formats! One for each sub-domain. And good luck trying to make them all work with each other. The fact that it interoperates with CSS/JS _is a huge plus!_. You can have SVG without these things if you really wanted to, but the fact that they interplay with each other is a testament to good language design on everyone's part here. Also: The Postscript spec is 920 pages, and the PDF spec from 2008 is 750 pages. Graphics are hard! 2. SVG is verbose because it's XML: XML is pretty compact honestly, especially in SVGs. Consider: <rect width="200" height="100" x="10" y="10" /> vs. { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } And that's me following best practices to have `"` around the values in the XML! It could be even more compact. It's only more verbose I guess when you have closing tags which in SVGs is mostly for the `<g>` element which is literally only one letter :P So... <g> <rect width="200" height="100" x="10" y="10" /> </g> vs { "type": "g", "children": [ { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } ] } XML is really not significantly verbose for uses like this, and the auto-closing `/>` makes it even more compact. And at the end of the day even if it were more verbose, it's not sufficiently more verbose for me to super care. 3. Who is SVG for? It's for both humans and computers and strikes a compromise between the needs of the two. Computers: built in a hugely well-supported language like XML makes it super easy to parse/process computationally. If you wanted to build a renderer that supports just a subset of SVG, that would be a < 1 day task. The more you want to support, the more it would take. And it's human readable -- or at least as human readable as any textual representation of 2D graphics can be. And that's another piece of inherent complexity here: representing 2D graphics in (effectively 1D) text is _always_ going to be hard to "read", if by "read" we mean understand what it's supposed to be displaying. No text format will be able to get around that. TLDR: The flaws listed here with SVG are either mostly preference/minutia or complexity inherent to the problem-space itself (2D graphics in a 1D format) that aren't likely overcomeable. Don't get me wrong there are definitely flaws with SVG! But I don't think these are it.
mauvehaus 2y ago
Ooh, ooh, how about text is kind of a nightmare? I ginned up some pretty inelegant stuff to rotate text 90 degrees[0] because I got tired of trying to figure out if there was a sane, blessed approach that I could generate with whatever Python library I was using. Ditto right justifying text. I just ended up fudging it [1]. Like, this is a pretty basic functionality if you're mixing text into your graphics. And I'm pretty willing to go down a rabbit hole if I can find one. I realize that doing this requires knowing the size of the text as rendered or doing something funny like rendering LtR text RtL reversed (which wouldn't work for centered?), but this is something that seems reasonable to expect a straightforward solution to. [0] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028b0faebbae98bb1dd3bab9b3c025eb741/cutlist.py#L199 https://github.com/longwalkwoodworking/cutlist/blob/a7c96028... [1] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028b0faebbae98bb1dd3bab9b3c025eb741/cutlist.py#L129 https://github.com/longwalkwoodworking/cutlist/blob/a7c96028...
- skgough 2y ago
  Usually when I have to use text in SVG I give up and use HTML in a <foreignObject> [1] tag. The article mentions that SVG is in an awkward halfway point between being useful for humans or a compile target for vector graphics. Text is where this becomes really obvious. Trying to generate SVG with <text> elements in it that end up where you want them is hopeless, especially if you don't know what font the text will be rendered in. I prefer specifying the x,y, width,height of a box that HTML goes into in a <foreignObject> tag and letting the browser reflow the text as necessary within that space. But that's still often not perfect, and I have run into browser incompatibilities when doing any more than basic CSS rules on the HTML inside. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject https://developer.mozilla.org/en-US/docs/Web/SVG/Element/for...
- Tao3300 2y ago
  I wanted to programmatically generate chord diagrams for ukulele in SVG. My solution was to make an SVG file in Inkscape that had everything in it that could possibly be in the diagram, and then marked it up for use with a template library. Not very elegant, but it saved me time to work on the thing I actually wanted to work on. Not sure if this sort of approach would be applicable for your cut lists.
ethellK 2y ago
Years back, I had the most fun I've had with creative UI when creating really expansive svgs and animating path with css. I will likely never do it again, but it was a great intro into splashy web development.
- cdrini 2y ago
  Same actually! Here's an old project: https://rawgit.com/cdrini/wikidata-spiral/master/index.html?root=Q2095&property=P279 https://rawgit.com/cdrini/wikidata-spiral/master/index.html?... Do you have any of your old projects public to share? I love creative UI stuff!
bob1029 2y ago
I don't really have any complaints or accolades for the internals of SVG, but I was recently evaluating image format for use with a tile-based browser game and stumbled upon a performance issue. After some quick experiments, I found that SVG is a total non starter compared to PNG and JPEG. At image counts in the tens, you can't tell the difference. If you are rendering a 20x30 grid of 600 images, SVG can take seconds, whereas the raster formats can redraw at monitor refresh rate. My process now is to treat the SVGs as art source code and to raster them into various formats as required at design time. I am a little bit disappointed by this outcome, as I was hoping for "infinite resolution" game art that would accommodate the varying zoom levels automagically. I will now be working with pre rastered tile sets for discrete zoom thresholds. I was expecting SVG to be slower, but not that much slower.

85 points by fanf2 2y ago

lilyball 2y ago

Previous discussion (2021): https://news.ycombinator.com/item?id=26114863 https://news.ycombinator.com/item?id=26114863

dang 2y ago
Thanks! Macroexpanded: SVG: The Good, the Bad and the Ugly - https://news.ycombinator.com/item?id=26114863 https://news.ycombinator.com/item?id=26114863 - Feb 2021 (219 comments)

eseidel 2y ago

I brought SVG to WebKit, back in 2005. So I guess I'm part of the problem. I generally agree with the article, SVG is bloated and confused about what it's trying to do. You're not alone in wanting something better. We had this same problem in Flutter. Ian Hickson (of HTML5 fame) made some attempts at seeing a better future you might be interested in: https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.8crpi5305nr https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

airstrike 2y ago
IconVG was looking promising but it seems abandoned at this point... The README doesn't mention anything and the repo isn't archived, but the last real commit is from 3+ years ago https://github.com/google/iconvg https://github.com/google/iconvg
- hgs3 2y ago
  There is also TinyVG [1]. See the previous discussion on HN [2]. [1] https://tinyvg.tech/ https://tinyvg.tech/ [2] https://news.ycombinator.com/item?id=35227635 https://news.ycombinator.com/item?id=35227635
  - Lammy 2y ago
    And HVIF: http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html http://blog.leahhanson.us/post/recursecenter2016/haiku_icons... https://news.ycombinator.com/item?id=40196333 https://news.ycombinator.com/item?id=40196333
rikroots 2y ago
That document has a really good summary of all the problems surrounding text rendering onto a canvas[1]. Having been through the pain of implementing such a system for my canvas library earlier this year I can sympathise with the decision not to include it in the proposed format's MVP. What did disappoint me when reading the doc was the decision to place accessibility at the bottom of the list of priorities for the proposed format. There's a footnote that says "Accessibility being low on this list reflects that the needs can be met outside the format as well, and supporting them inside the format would be beneficial only to the extent that it provides greater flexibility to designers", but to me that seemed back-to-front: why not tell the engine/device that will display the image the (preferred) requirements for accessibly rendering (or describing) that image by including such data in the format, rather than hoping that the engine/device will make "best efforts" to support people with accessible needs in some unknowable way? [1] Text section in doc - https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOkS9JyA_lEURI8p5PsZlg/edit#heading=h.2fvcp5gqzghd https://docs.google.com/document/d/1YWffrlc6ZqRwfIiR1qwp1AOk...

deleted 2y ago

[deleted]

jauntywundrkind 2y ago

With great powers come a lot of people very mad about how we miuse them & that we might not be able to reimplement it all in a weekend. > This problem of SVG is actually just the problem of the web in general. It’s scope is huge, it’s bloated and hard to work with. > SVG is nothing you could implement in a day. Or a week. Or a month. The huge amount of specifications, that are most often only partly implemented, makes it very hard to overview what supports what, confusing the user as to what features they can actually use if they want their SVG file to be universally supported That just doesn't seem like a big problem, in fact. The webs gotten pretty good & the standard is pretty high. Yes people have some real pains but also my word, software is a world of contrived griefs, nonsense beefs. People love grandstanding against things.

bobthepanda 2y ago
yeah, this doesn't really touch on the beef i have with SVG. the problem I have is that SVG is complicated like the old web, but unlike the new web we also haven't created new standards like Flexbox and Grid that let you ignore the problems with the old ones. For example, in HTML-land we have had z-index for a while to describe the order in which elements should render on top of each other. This doesn't exist in SVG, so the order of elements is the order that they are declared in markup, which can lead to very kludgy things. In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. These are all things solved in SVG1.2, but of course the classic issue is that barely anyone has bothered implementing SVG1.2.
- felixfbecker 2y ago
  > In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc. You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG. The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.

DrDroop 2y ago

There was a time that SVG was going to replace flash, or something like that, but these days people just use the "simple" subset. I've seen multiple implementations for the vector graphics based on compute shaders, impressive stuff, can render the tiger svg with no problem. Parsing the bezier curves out of the xml is not that hard compared to all the work needed the have this work on the GPU. Most people also don't understand XML, I'm building a sort of compiler for it with full support for Namespaces, Schema, XLinks and all of that, boring stuff that needs to be done, I don't understand why this needs to be your problem though and even then those standard are not THAT hard. You will only understand XML if you need to use XML. Yes XML is verbose but also your mom is fat and you still love her don't you? Developers look at me weird when I start talking XML, like I am some sort of boomer that want to limit women's right to choice or something like that. Better not to mention it, or I'll have to listen to them explaining why JSON is just better for hours on end without ever considering the strange bizz requirements I labour under.

bawolff 2y ago
> I'm building a sort of compiler for it with full support for Namespaces, Schema, XLinks and all of that, boring stuff that needs to be done, I don't understand why this needs to be your problem though Well if you just do the generic version uncritically, you end up with all sorts of security vulnerabilities. Things like xml external entities, xinclude have causes quite a few security issues over the years when processing svgs.

dagss 2y ago

Not about SVG as such, but the XML nature of SVG. I see JSON these days for everything including, for instance, savefiles for documents; templates in Azure, etc etc I wonder if I will honestly, un-ironically, use XML in my next project for something where JSON could have done the job. JSON is missing these small things make it very annoying (mainly comments, comma at end of last element not allowed, and the crappy ambiguities standard vs implementations about numbers, autoformatting of pretty printed JSON not standardized). Also not very readable as config format. And YAML is human editing friendly but so horrible in other ways ( [US, GB, SE, DK, NO, ...]) I am sure there are lots of small competitors. But XML is already there, so well supported everywhere.

mofosyne 2y ago
Something similar to the CBOR diagnostics format but formalized would be nice... since being able to tag semantics would make consistent interpretation of data content easier.
diegof79 2y ago
The problem with XML is that most tools around 2000-2010 used it for everything, including simple configuration files and even DSLs (the Maven v1 XML was a nightmare to maintain). However, there are features of XML that are very useful for a document format like SVG. One of them is namespaces. For example, you can create an SVG and add custom metadata in another namespace, and then any viewer who uses a decent XML parser will show it without issues. That’s not possible with JSON, as there is no guarantee that an unknown key will pass. (although I prefer a simple format like JSON or TOML for config files)
lenkite 2y ago
XML is easier to edit by humans than JSON any-day. SVG is one of the few graphic markup languages whose basics one can pick up in a couple of hours and go to production. If folks object to XML, then they should also object to HTML, JSX, etc. We just need browsers to implement SVG 2.0
- mort96 2y ago

vg_head 2y ago

One other thing that is a bit weird about SVG is how some parts don't feel tightly integrated. For example, paths and SMIL events have their own syntax. And a lot of APIs related to them seem to be either abandoned, deprecated, or just hard to find. There's also SVG2 which is confusing, as it seems like no browser will ever implement it fully. That being said, SVG allows you to create quite beautiful and complex effects with relatively little code.

deleted 2y ago

[deleted]

omoikane 2y ago

> Bezier curves, elliptic curves, fills, outlines and gradients should mostly suffice to represent every unanimated SVG There are also filters, pattern fills, dashed strokes, etc. Also, mesh gradients (as supported by Inkscape) are immensely powerful but not yet standardized. A lot of people are surprised to find <script> in SVGs and maybe that's a bad idea, but everything that someone thought was pure unnecessary bloat are actually features that users depend on. Maybe there is a cleaner and purer universal standard that covers everyone's use cases, but users already have SVG and would rather see incremental improvements here, as opposed to waiting for a new thing that is less capable.

felixfbecker 2y ago
<script> in SVGs is also not a concern nowadays if you use a CSP (even for user-uploaded content).
felixfbecker 2y ago
It would be amazing if browsers just implemented all the features that were already specified in SVG2. Currently it seems like any new spec work on features that would be amazing for the web (e.g. SVG connectors) has been completely paused because browsers haven't even implemented what has already been spec'ed over a decade ago.
WillAdams 2y ago
I found the <script> capability very useful for making interactive SVGs for CNC assembly diagrams for the Shapeoko 2.

cdrini 2y ago

Not a huge fan of this hot-take that pops up every once in a while. I love SVG and use it all the time, and think it's a fantastically designed language and system. The places where it's lacking have nothing to do with bloat or verbosity. It's biggest short-comings are all fixed in SVG 1.2 (flowable text, stroke placement on path, etc), but it's just _still_ not implemented anywhere. And on top of that, some auto-layout options would be quite handy... or maybe some charting primitives. A few responses: 1. The spec is too long/complicated: Yeah that's cause graphics is inherently complicated. You can't simplify out the core of the thing you're trying to do. Sure "shapes" are simple, but anything that would be actually useful involves paths (interpolation modes), transforms, groups, blend modes, effects, gradients, masks, stamps, FONTS (don't get me started on fonts!) typography, and on and on. And that's just stationary 2d graphics! Add animations in there and it's a whole other deal. Strip it all out and yes, your spec is shorter. But then you need like 20 different file formats! One for each sub-domain. And good luck trying to make them all work with each other. The fact that it interoperates with CSS/JS _is a huge plus!_. You can have SVG without these things if you really wanted to, but the fact that they interplay with each other is a testament to good language design on everyone's part here. Also: The Postscript spec is 920 pages, and the PDF spec from 2008 is 750 pages. Graphics are hard! 2. SVG is verbose because it's XML: XML is pretty compact honestly, especially in SVGs. Consider: <rect width="200" height="100" x="10" y="10" /> vs. { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } And that's me following best practices to have `"` around the values in the XML! It could be even more compact. It's only more verbose I guess when you have closing tags which in SVGs is mostly for the `<g>` element which is literally only one letter :P So... <g> <rect width="200" height="100" x="10" y="10" /> </g> vs { "type": "g", "children": [ { "type": "rect", "width": 200, "height": 100, "x": 10", "y": 10 } ] } XML is really not significantly verbose for uses like this, and the auto-closing `/>` makes it even more compact. And at the end of the day even if it were more verbose, it's not sufficiently more verbose for me to super care. 3. Who is SVG for? It's for both humans and computers and strikes a compromise between the needs of the two. Computers: built in a hugely well-supported language like XML makes it super easy to parse/process computationally. If you wanted to build a renderer that supports just a subset of SVG, that would be a < 1 day task. The more you want to support, the more it would take. And it's human readable -- or at least as human readable as any textual representation of 2D graphics can be. And that's another piece of inherent complexity here: representing 2D graphics in (effectively 1D) text is _always_ going to be hard to "read", if by "read" we mean understand what it's supposed to be displaying. No text format will be able to get around that. TLDR: The flaws listed here with SVG are either mostly preference/minutia or complexity inherent to the problem-space itself (2D graphics in a 1D format) that aren't likely overcomeable. Don't get me wrong there are definitely flaws with SVG! But I don't think these are it.

mauvehaus 2y ago

Ooh, ooh, how about text is kind of a nightmare? I ginned up some pretty inelegant stuff to rotate text 90 degrees[0] because I got tired of trying to figure out if there was a sane, blessed approach that I could generate with whatever Python library I was using. Ditto right justifying text. I just ended up fudging it [1]. Like, this is a pretty basic functionality if you're mixing text into your graphics. And I'm pretty willing to go down a rabbit hole if I can find one. I realize that doing this requires knowing the size of the text as rendered or doing something funny like rendering LtR text RtL reversed (which wouldn't work for centered?), but this is something that seems reasonable to expect a straightforward solution to. [0] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028b0faebbae98bb1dd3bab9b3c025eb741/cutlist.py#L199 https://github.com/longwalkwoodworking/cutlist/blob/a7c96028... [1] https://github.com/longwalkwoodworking/cutlist/blob/a7c96028b0faebbae98bb1dd3bab9b3c025eb741/cutlist.py#L129 https://github.com/longwalkwoodworking/cutlist/blob/a7c96028...

skgough 2y ago
Usually when I have to use text in SVG I give up and use HTML in a <foreignObject> [1] tag. The article mentions that SVG is in an awkward halfway point between being useful for humans or a compile target for vector graphics. Text is where this becomes really obvious. Trying to generate SVG with <text> elements in it that end up where you want them is hopeless, especially if you don't know what font the text will be rendered in. I prefer specifying the x,y, width,height of a box that HTML goes into in a <foreignObject> tag and letting the browser reflow the text as necessary within that space. But that's still often not perfect, and I have run into browser incompatibilities when doing any more than basic CSS rules on the HTML inside. [1] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject https://developer.mozilla.org/en-US/docs/Web/SVG/Element/for...
Tao3300 2y ago
I wanted to programmatically generate chord diagrams for ukulele in SVG. My solution was to make an SVG file in Inkscape that had everything in it that could possibly be in the diagram, and then marked it up for use with a template library. Not very elegant, but it saved me time to work on the thing I actually wanted to work on. Not sure if this sort of approach would be applicable for your cut lists.

ethellK 2y ago

Years back, I had the most fun I've had with creative UI when creating really expansive svgs and animating path with css. I will likely never do it again, but it was a great intro into splashy web development.

cdrini 2y ago
Same actually! Here's an old project: https://rawgit.com/cdrini/wikidata-spiral/master/index.html?root=Q2095&property=P279 https://rawgit.com/cdrini/wikidata-spiral/master/index.html?... Do you have any of your old projects public to share? I love creative UI stuff!

bob1029 2y ago

I don't really have any complaints or accolades for the internals of SVG, but I was recently evaluating image format for use with a tile-based browser game and stumbled upon a performance issue. After some quick experiments, I found that SVG is a total non starter compared to PNG and JPEG. At image counts in the tens, you can't tell the difference. If you are rendering a 20x30 grid of 600 images, SVG can take seconds, whereas the raster formats can redraw at monitor refresh rate. My process now is to treat the SVGs as art source code and to raster them into various formats as required at design time. I am a little bit disappointed by this outcome, as I was hoping for "infinite resolution" game art that would accommodate the varying zoom levels automagically. I will now be working with pre rastered tile sets for discrete zoom thresholds. I was expecting SVG to be slower, but not that much slower.