3 ms·

The two big problems with SVG are: It's unsafe because it can contain javascript. You can't just let users upload SVG files, you need to strip them. As far as

The two big problems with SVG are: It's unsafe because it can contain javascript. You can't just let users upload SVG files, you need to strip them. As far as I know there is no image hoster that supports SVGs and I know of no website that contains user-uploaded pictures that allows SVGs. Then there's the issue that SVG is an extremely complex format. It's not a format that's optimized for rendering like jpg, png, gif, but one optimized for working on it like psd, xcf, raw. No browser supports all of SVG. You can animate SVGs without javascript with the <animate> tag, but Firefox doesn't support it. There's some weird features basically nobody supports, like defining fonts inside of SVG. There are many features that are made for editing SVGs by hand, but if you ever opened a SVG generated by a GUI program like Inkscape you know that nobody would ever want to do that. The path format on the other hand is optimized for space and isn't really human readable.

therealunreal 11y ago
> 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.
neerdowell 11y ago
> I know of no website that contains user-uploaded pictures that allows SVGs Wikipedia.
espadrine 11y ago
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_Image https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_I... [2]: https://github.com/atmos/camo/blob/master/server.coffee#L43 https://github.com/atmos/camo/blob/master/server.coffee#L43 [3]: http://www.w3.org/TR/SVG11/ http://www.w3.org/TR/SVG11/ [4]: http://www.w3.org/TR/PNG/ http://www.w3.org/TR/PNG/
- legulere 11y ago
  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 http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf PNG: 81 pages http://www.w3.org/TR/REC-png.pdf http://www.w3.org/TR/REC-png.pdf
jarek-foksa 11y ago
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 http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf) - HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf https://html.spec.whatwg.org/print.pdf) - ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2 https://www.oasis-open.org/standards#opendocumentv1.2) - PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf 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).
- legulere 11y ago
  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 http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf 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.

therealunreal 11y ago

> 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.

neerdowell 11y ago

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

espadrine 11y ago

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_Image https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_as_an_I... [2]: https://github.com/atmos/camo/blob/master/server.coffee#L43 https://github.com/atmos/camo/blob/master/server.coffee#L43 [3]: http://www.w3.org/TR/SVG11/ http://www.w3.org/TR/SVG11/ [4]: http://www.w3.org/TR/PNG/ http://www.w3.org/TR/PNG/

legulere 11y ago
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 http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf PNG: 81 pages http://www.w3.org/TR/REC-png.pdf http://www.w3.org/TR/REC-png.pdf

jarek-foksa 11y ago

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 http://www.w3.org/TR/SVG/REC-SVG11-20110816.pdf) - HTML 5 - 1156 pages (https://html.spec.whatwg.org/print.pdf https://html.spec.whatwg.org/print.pdf) - ODF 1.2 - 1217 pages (https://www.oasis-open.org/standards#opendocumentv1.2 https://www.oasis-open.org/standards#opendocumentv1.2) - PDF 1.7 - 1310 pages (http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf 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).

legulere 11y ago
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 http://www.w3.org/TR/REC-png.pdf) or EPS 31 Pages (http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf 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.