Hacker News Reader

SVG is in some way an advanced, editable version of PostScript, PDF's ancestor.

Any SVG inside of an <img> tag is as safe as any image format. The JS code won't run, any external resources linked to from inside the SVG won't be loaded, the :visited CSS style is disabled[1]…

For added security, you can even send an HTTP tag called Content-Security-Policy: default-src 'none'; img-src data:; style-src 'unsafe-inline' gives good results. That's what GitHub uses, by the way[2].

> It's not a format that's optimized for rendering like jpg

You could argue the same of jpg in a comparison between jpg and bmp.

You can animate SVGs even within an <img> tag with SMIL or CSS.

Sure, there are a lot of features, and you could argue that it makes SVG complex; but the SVG specification[3] is not that much bigger than the PNG specification[4], if at all. It is irrelevant anyway when edited through a program, as PNGs usually are.

[1]: https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_I...

[2]: https://github.com/atmos/camo/blob/master/server.coffee#L43

[3]: http://www.w3.org/TR/SVG11/

[4]: http://www.w3.org/TR/PNG/

If you look at the pdf versions you will see that the png specification is shorter by a factor of 10.

SVG: 826 pages http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf

PNG: 81 pages http://www.w3.org/TR/REC-png.pdf

> I know of no website that contains user-uploaded pictures that allows SVGs.

openclipart.org does exactly that. I don't know if they strip scripts or simply forbid files containing scripts.

> I know of no website that contains user-uploaded pictures that allows SVGs

Wikipedia.

SVG is a complex format, but it's not that bad compared to other widely adopted standards. Just for comparison:

- SVG 1.1 - 826 pages (http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf)

- HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf)

- ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2)

- PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdf...)

SVG 2 spec is even smaller because it removes sections that are either duplicating other W3C standards (filters, styling) or not implemented by all major vendors (animations, fonts, path APIs).

You forgot that it also requires XML and CSS. I'm surprised PDF is just marginally bigger, considering that it's carrying around lots of legacy stuff is so much more than just a vector graphics format.

Anyway. SVG is not or only partly competing with the formats you listed. It's actually a format that's supposed to be included in those formats you listed. It's competing with PNG 81 Pages (http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_S... which is kind of cheated though because it requires the ~800 page postscript specification, at least it doesn't need XML and CSS additionally)

Removing sections that are standardized somewhere else doesn't make a file format easier, especially if you want to implement it outside of a browser.

There's still tons of features in SVG that are probably not used or not really needed:

Mandating IEE 754 binary floating point coordinates, while representing them as decimals that are usually rounded to 0.001 or 0.0001. This causes rounding errors all the time. The 16.16 fixed point format used in ttf seems more sensible for this usecase.

Including (parts of) external SVGs with <use>. <use> doesn't seem to be supported in Safari, Firefox or Inkscape anyway.

<switch> to make an SVG render differently on computers with different locale.

ARIA (accessibility) support, what happened to a description of the image?

Commas as optional separators in paths, but only at certain locations and only at most one of them. There have been several bugs in programs using SVG concerning the parsing path strings that were related to white space.

Basic shapes that can just as easily can be constructed using <path>, especially the polygon and polyline.

The total absurdity that is <text>. Text usually isn't the main content of images, yet the chapter about text is the longest in the SVG specification, containing stuff like text flowing along a path. And all this without supporting multi-line text. Just use <path> instead, bitmap graphics also uses rasterized text. If fonts aren't installed it may cause overlapping, or it might not get rendered at all.

XML dependence will become optional in SVG 2 and hopefully it will be deprecated in SVG 3. Chrome team is already considering switching to HTML parser no matter whether the SVG document uses XML or HTML serialization.

<use> elements with external references are tricky due to the same origin policy restrictions and various browser bugs, but referencing local IDs works just fine. Inkscape for example creates clones and symbol instances with <use> elements.

The most obscure part of the paths specification, i.e. the pathSegList interface, is gone in SVG 2. There were some plans to deprecate the "d" attribute and instead introduce a nicer function-based syntax such as data="move(10, 10) line(20, 20)", but AFAIK this idea has been dropped. Still, the path data grammar is clearly defined in the spec, I'm not sure why browser vendors don't follow it.

SVG 2 will support multi-line text and embedded WOFF fonts. This feature is important when you are authoring e.g. UI mockups or posters. Even low level drawing APIs such as canvas have the text primitive. If you express textual content with <path> instead of <text> element then it will not be editable and selectable, screenreaders won't recognize it and search engines won't index it.