SVG: The Good, the Bad and the Ugly

It's not just specs. In my experience you need a comprehensive test suite that implementations can use to test they cover the edge cases.

One thing I wish this mentioned in the "Ugly" section is how allowing Javascript, and to some extent using XML, creates security issues, such as potential XSS (because of javscript), XXE (because of XML), etc. You can avoid vulnerabilities if you're careful. But you have to be careful, and know what to look out for.

> Instead you compile it into an PDF (which is also a horrible format and badly bloated, but well)

Yeah... PDF might actually be worse in some ways (and it can have javascript too). With SVG, it isn't too hard to be able to use a subset of SVG to generate images. With PDF though, just making a valid, useful PDF is pretty complicated and requires a decent understanding of the spec (which is big). Being able to properly render any valid PDF is probably even worse.

True, but the lack of a clear distinction also seems like a weakness in the specific DSLs rather than a weakness in the format. HTML has (with some exceptions) a very clear distinction between them: attributes are for metadata, elements are for visible page content. Android's XML draws a similar distinction, with attributes used to describe properties of a view and elements used to describe child views.

(I do concur with others who have noted here that the "elements" versus "attributes" distinction makes XML a poor choice for serialization, but XML as a serialization format isn't really the issue here.)

I think it would be nice to have a design language:

  def port 0,0 100,100:
    L 10,10 90,0 90,70 70,70 70,90 20,90 20,70 10,70 10,10
  
  def bank 0,0 400,100:
    port 0,0 100,100
    port 100,0 200,100
    port 200,0 300,100
    port 300,0 400,100

  def router 0,0 1100,200:
    port 50,50 150,150
    bank 200,50 600,150
    bank 650,50 1050,150
    
  router 0,0 1100,200

I was thinking it would be cool to have an "about" page in openwrt showing your router with all the ports labeled in svg. Should be simple, but I couldn't figure out luci.

The idea to stuff paths into attribute strings instead of using elements came from Microsoft's VML (one of the competing vector graphics standards that influenced SVG).

https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Devel...

Pragmatically it was a brilliant practical compromise in response to one of XML's horrible flaws as a serialization format (it's way too fluffy), saving enormous amounts of memory and fragmentation by using one string per path, instead of creating thousands of DOM objects with tens of thousands of attributes and text nodes. But you're right, that's the "original sin" of XML that SVG is doomed to suffer with.

PDF is basically just the PostScript imaging model without the Turing-complete stack based programming language.

SVG is just the latest expression of PostScript graphics model (if you ignore all the stuff about fonts), which is based on the Stencil/Paint imaging model with Porter Duff Compositing, and descendent from Interpress and Jam).

The canvas 2d api is pretty much just immediate mode SVG / PostScript graphics, with a few new features added.

JSON's a much better format for structured graphics in some ways, but has its own set of flaws and limitation, like not having comments, and being terrible for binary data. But at least JSON arrays are a bit more (but not much) memory efficient than XML elements, and JavaScript itself has typed binary arrays, although standard JSON doesn't support them (using base 64 strings sucks). So representing paths as flat strings like SVG, instead of JSON arrays of numbers, is probably still a win for JSON if you're mainly drawing static paths, but not if you want to read, process or edit those paths a lot.

Now, instead of using SVG, it's usually easier and more efficient to just use your own (or some standard) JSON format for structured graphics, and draw it with the canvas api. But there will never be one universal JSON graphics format, just many special purpose ones. For example, d3 has a lot of different JSON formats (domain specific languages) for representing different kinds of graphics and data.

More on PostScript and its history:

https://news.ycombinator.com/item?id=21968175

>Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:

https://groups.google.com/g/fa.laser-lovers/c/H3us4h8S3Kk