6 ms·

Ask HN:Whats the problem with SVG?

23 points by lousy_sysadmin 14y ago

I've been playing around with Inkscape for a while now to create vector image as its one of the easiest solution for Retina-esque site. However I'm having a hard time finding image hosting that support SVG. My question is, why is it so hard for image hosting service to support native SVG, instead of converting an image to other format. Would like to hear the limitations and challenges that comes with it. http://imgur.userecho.com/topic/23630-svg-support/

lsiebert 14y ago
It's not hard. However, I'd note that IE didn't have built in support until 2011, and the first browser with native svg support was Konqueror in 2004, whereas gif and jpeg have been around for a lot longer. Isn't SVG just XML? I'd assume you could host it that way.
- KorvinSzanto 14y ago
  It's XML based, really only uses a different schema.
  - tobyink 14y ago
    What schema does XML normally use?
    - Zash 14y ago
      XML has no default schema.
lmm 14y ago
XML being XML, it's hard-to-impossible to host SVG without allowing people to store arbitrary XML on your service, which sooner or later is going to be abused.
- JD557 14y ago
  Also, Its possible to use script tags to run javascript code in an svg. If you really wanted to, you could pretty much make your own webpage run on the image hosting server. Also, you could send a malicious script to someone hidden in a cute cat drawing, and it would look like it was the host's fault.
- threedaymonk 14y ago
  I don't think this has to be a problem: it's actually rather straightforward to write some XSLT to process incoming XML and emit only whitelisted elements and attributes.
- emn13 14y ago
  That's true for almost any hosting service - it's usually quite easy to encode other information in whatever wrapper is possible. Virtually all image formats (for instance) allow arbitrary metadata, and usually of arbitrary size. And if meta-data isn't allowed, a lossless format like PNG can easily be reinterpreted as a simple byte-array (e.g. 8bpp greyscale image). Of course, why would anyone bother? It's that hard to find hosters that will host anything, so why do through the hassle to encruft your data with some somewhat unwieldy wrapper? The fact that it's XML is in some way a "protection" here since for no particularly good reason some character codes cannot be represented by xml (not even encoded), meaning you'll need ugly workarounds to store arbitrary data.
nwh 14y ago
I'd considered making one some time ago, but gave up when I realised that somebody had already purchased http://s.vg/ http://s.vg/.
wisty 14y ago
IE6. XML viruses.
timrogers 14y ago
I'm guessing you could maybe host it with Gists, using the raw link? Although the content type headers might be an issue...
pre 14y ago
It's not hard, probably the image hosts concerned merely didn't think to include it. You can upload svg files with the right content type to Amazon S3 without trouble, is that not good enough?
mbq 14y ago
_Arbitrary_ SVG is a security/privacy problem -- it may inject JS or exploit quirks in rendering to manipulate site contents, import external images and fonts, or simply be a render bomb. And it is hard to filter out those problems.
- nwh 14y ago
  You could just have a dedicated domain for it, then there's no risk of XSS. It's doable, but it would be rather fragile. The render bomb point is a little trickier, as you can use some detailed filters to crash most browsers. Heck, even a single simple shape will crash any version of iOS.
jahewson 14y ago
SVG implementations on browsers have historically been poor, though this is certainly improving. You'll hit many bugs and unsupported features. IE < 9 doesn't support SVG at all, and Safari < 6 only does so in XHTML. SVG fonts are sparsely supported. The alternative - rasterising SVG on the server - is a heavyweight task, I've not found any libraries which can do this quickly. The worst problem may be SVG itself - SVG 1.2 which dates from 2004 was abandoned, and most browsers implement SVG 1.1 which is rather lacking in features. This makes it hard if you're a designer to produce SVG documents which a browser can actually render. At a bare minimum any SVG hosting project would have to involve some sort of SVG lint, to make sure that browser-incompatible SVG elements are not present, implement workarounds for browser-specific bugs, and check that there are no <script> tags etc. The sheer size and complexity of even SVG 1.1 makes it non-trivial. One pragmatic approach to sanitize SVG may be to round-trip SVG -> PDF -> SVG via cairosvg and pdftocairo, though it may burn some CPU.
- drhowarddrfine 14y ago
  Any technology on the web that's not supported well is due to IE not supporting it. IE always holds back the web.
- ChuckMcM 14y ago
  This is perhaps the best answer, browser support is poor. Rendering SVG to PNG prior to shipping it out works but you really want to cache it, not do that in real time. I keep hoping that epub will generate a renaissance of interest in SVG. So far no luck.
- jarek-foksa 14y ago
  SVG fonts are dead, so what? You can still embed other font formats the same way you do it in HTML/CSS. You don't need to sanitize SVGs to host them safely - you just put them inside <img> tag and browsers will do sandboxing for you. What features do you actually miss in SVG 1.1? Gradient meshes? 3d transforms? multiple fills? I can think of only advanced stuff that is rarely used and tricky to do with other web technologies anyway. Also, why would you want to strip browser-incompatible SVG elements? Browsers will simply ignore such elements.
Turing_Machine 14y ago
You might look at http://openclipart.org/ http://openclipart.org/ to see how they're handling it.
youngtaff 14y ago
My question is why do you want to host your SVG images elsewhere? If you just want to shop them you could convert them to bitmap or host them on GitHub If you want to include them on your website, they're small and compress well with gzip so why have the complexity of relying on a third party services It you have too much traffic to be able to host them yourself then you should look at something like a CDN e.g. Cloudfront, infront of S3

lsiebert 14y ago

It's not hard. However, I'd note that IE didn't have built in support until 2011, and the first browser with native svg support was Konqueror in 2004, whereas gif and jpeg have been around for a lot longer. Isn't SVG just XML? I'd assume you could host it that way.

KorvinSzanto 14y ago
It's XML based, really only uses a different schema.
- tobyink 14y ago
  What schema does XML normally use?
  - Zash 14y ago
    XML has no default schema.

lmm 14y ago

XML being XML, it's hard-to-impossible to host SVG without allowing people to store arbitrary XML on your service, which sooner or later is going to be abused.

JD557 14y ago
Also, Its possible to use script tags to run javascript code in an svg. If you really wanted to, you could pretty much make your own webpage run on the image hosting server. Also, you could send a malicious script to someone hidden in a cute cat drawing, and it would look like it was the host's fault.
threedaymonk 14y ago
I don't think this has to be a problem: it's actually rather straightforward to write some XSLT to process incoming XML and emit only whitelisted elements and attributes.
emn13 14y ago
That's true for almost any hosting service - it's usually quite easy to encode other information in whatever wrapper is possible. Virtually all image formats (for instance) allow arbitrary metadata, and usually of arbitrary size. And if meta-data isn't allowed, a lossless format like PNG can easily be reinterpreted as a simple byte-array (e.g. 8bpp greyscale image). Of course, why would anyone bother? It's that hard to find hosters that will host anything, so why do through the hassle to encruft your data with some somewhat unwieldy wrapper? The fact that it's XML is in some way a "protection" here since for no particularly good reason some character codes cannot be represented by xml (not even encoded), meaning you'll need ugly workarounds to store arbitrary data.

nwh 14y ago

I'd considered making one some time ago, but gave up when I realised that somebody had already purchased http://s.vg/ http://s.vg/.

wisty 14y ago

IE6. XML viruses.

timrogers 14y ago

I'm guessing you could maybe host it with Gists, using the raw link? Although the content type headers might be an issue...

pre 14y ago

It's not hard, probably the image hosts concerned merely didn't think to include it. You can upload svg files with the right content type to Amazon S3 without trouble, is that not good enough?

mbq 14y ago

_Arbitrary_ SVG is a security/privacy problem -- it may inject JS or exploit quirks in rendering to manipulate site contents, import external images and fonts, or simply be a render bomb. And it is hard to filter out those problems.

nwh 14y ago
You could just have a dedicated domain for it, then there's no risk of XSS. It's doable, but it would be rather fragile. The render bomb point is a little trickier, as you can use some detailed filters to crash most browsers. Heck, even a single simple shape will crash any version of iOS.

jahewson 14y ago

SVG implementations on browsers have historically been poor, though this is certainly improving. You'll hit many bugs and unsupported features. IE < 9 doesn't support SVG at all, and Safari < 6 only does so in XHTML. SVG fonts are sparsely supported. The alternative - rasterising SVG on the server - is a heavyweight task, I've not found any libraries which can do this quickly. The worst problem may be SVG itself - SVG 1.2 which dates from 2004 was abandoned, and most browsers implement SVG 1.1 which is rather lacking in features. This makes it hard if you're a designer to produce SVG documents which a browser can actually render. At a bare minimum any SVG hosting project would have to involve some sort of SVG lint, to make sure that browser-incompatible SVG elements are not present, implement workarounds for browser-specific bugs, and check that there are no <script> tags etc. The sheer size and complexity of even SVG 1.1 makes it non-trivial. One pragmatic approach to sanitize SVG may be to round-trip SVG -> PDF -> SVG via cairosvg and pdftocairo, though it may burn some CPU.

drhowarddrfine 14y ago
Any technology on the web that's not supported well is due to IE not supporting it. IE always holds back the web.
ChuckMcM 14y ago
This is perhaps the best answer, browser support is poor. Rendering SVG to PNG prior to shipping it out works but you really want to cache it, not do that in real time. I keep hoping that epub will generate a renaissance of interest in SVG. So far no luck.
jarek-foksa 14y ago
SVG fonts are dead, so what? You can still embed other font formats the same way you do it in HTML/CSS. You don't need to sanitize SVGs to host them safely - you just put them inside <img> tag and browsers will do sandboxing for you. What features do you actually miss in SVG 1.1? Gradient meshes? 3d transforms? multiple fills? I can think of only advanced stuff that is rarely used and tricky to do with other web technologies anyway. Also, why would you want to strip browser-incompatible SVG elements? Browsers will simply ignore such elements.

Turing_Machine 14y ago

You might look at http://openclipart.org/ http://openclipart.org/ to see how they're handling it.

youngtaff 14y ago

My question is why do you want to host your SVG images elsewhere? If you just want to shop them you could convert them to bitmap or host them on GitHub If you want to include them on your website, they're small and compress well with gzip so why have the complexity of relying on a third party services It you have too much traffic to be able to host them yourself then you should look at something like a CDN e.g. Cloudfront, infront of S3