4 ms·

SVG is such a superior format for icons, it scales perfectly, is very efficient size-wise. The only annoyance is getting them inline so that they can be styled

SVG is such a superior format for icons, it scales perfectly, is very efficient size-wise. The only annoyance is getting them inline so that they can be styled with CSS.

tyingq 9y ago
Gradient fills are something of a pain as well if trying to do them inline or sprited. Though I guess HTTP/2 makes additional downloads less of an issue.
- jancsika 9y ago
  What makes gradient fills for inline svg difficult?
  - tyingq 9y ago
    It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site. Many svg creation tools autoname the gradient and then you have to hand edit it so that it's unique. Or you end up with two gradients called "SVGID_AUTOGENERATED_1" in the same html file. Here's a real world example. Two SVG icons from the same github repo: https://camo.githubusercontent.com/e448a75c4115d60100a0a2b29d9143c195670907/68747470733a2f2f73332d75732d776573742d322e616d617a6f6e6177732e636f6d2f737667706f726e2e636f6d2f6c6f676f732f746f7275732e737667 https://camo.githubusercontent.com/e448a75c4115d60100a0a2b29... https://camo.githubusercontent.com/d9522bd55c6c95a14f51f8e7c8619a8d372e88ed/68747470733a2f2f73332d75732d776573742d322e616d617a6f6e6177732e636f6d2f737667706f726e2e636f6d2f6c6f676f732f6b657963646e2e737667 https://camo.githubusercontent.com/d9522bd55c6c95a14f51f8e7c... While they are in the exact same repo/collection, they have clashing gradient names. If you grabbed those and put them both inline, in the same page, it wouldn't work. It also doesn't play well with dynamic content where you have the cache headers set to not allow local browser caching, as it causes a second request. Would have been nice if there was an additional way to reference the gradients, maybe css (not using a url fragment that is...defining the gradient itself).
    - jancsika 9y ago
      > It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site. Ah, I see. Yes, you're right. Additionally, the HTML5 spec is written such that FuncIRIs won't work in about:blank, making it impossible to quickly test svg gradients or patterns in Firefox. (But it works in Chromium for some reason, which is nice.) I think the Snap.svg framework gets this right-- it allows the user to specify the gradient with a single string, much like the "d" path data.
      - jancsika 9y ago
        > While they are in the exact same repo/collection, they have clashing gradient names. If you grabbed those and put them both inline, in the same page, it wouldn't work. Seems like the only way around that is to take a hash of the gradient.innerHTML and use that as the id of the gradient. Of course that increases the size of the svg file, but as you point out it's necessary (comically so, given all the complexity of xml namespaces don't prevent this clash).
        jancsika 9y ago
        > Seems like the only way around that is to take a hash of the gradient.innerHTML ... in which case the same gradient in two different inline svgs would create a duplicate id. Too bad CSS gradients don't work in svg shapes.
pen2l 9y ago
I love SVG in general... I am curious to hear, is there any reason not to use them? Maybe that it's not as well supported on older browsers?
- edent 9y ago
  The only serious argument I've heard against them is that it makes life easier for people who want to reverse engineer your graphics. But, frankly, I'm switching as much of my stuff over to them as possible.
- Silhouette 9y ago
  I am curious to hear, is there any reason not to use them? As an alternative image format to things like PNG? There aren't many, if it's an image that lends itself to a vector format in the first place. SVGs have been widely supported for some time, often have significant file size benefits as we see here, and scale cleanly to different screen resolutions. You have to go back to versions of IE that even the likes of Microsoft and Google won't support any more or to very old mobile devices to start running into general compatibility problems. One thing to be aware of is that you are effectively programming your graphics if you're using SVG, not just recording the image itself. If you start playing with the more powerful features, particularly using non-trivial filters, you might occasionally run into issues in the rendering code that turns your program into an on-screen image. Depending on how much of that code is in the browser itself and how much is delegated to the underlying OS/graphics drivers for acceleration, that can cause problems including slow display of images, distortion so the rendered image doesn't look right, or in extreme cases even hanging the browser or graphics driver if you're unlucky enough to trigger some underlying bug (which is obviously a rare result, but I have personally seen it happen in my own development work). For the kinds of very simple SVGs we're looking at here, I can't imagine any of these potential problems being a serious risk, though.
- RazrFalcon 9y ago
  It doesn't supported well even in modern browsers. There are so many edge-cases that are completely ignored. Yes, you probably newer encounter them, but they are still there.
userbinator 9y ago
is very efficient size-wise Compared to raster graphics, yes. Compared to other vector formats like SWF, no.

SVG is such a superior format for icons, it scales perfectly, is very efficient size-wise. The only annoyance is getting them inline so that they can be styled with CSS.

tyingq 9y ago

Gradient fills are something of a pain as well if trying to do them inline or sprited. Though I guess HTTP/2 makes additional downloads less of an issue.

jancsika 9y ago
What makes gradient fills for inline svg difficult?
- tyingq 9y ago
  It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site. Many svg creation tools autoname the gradient and then you have to hand edit it so that it's unique. Or you end up with two gradients called "SVGID_AUTOGENERATED_1" in the same html file. Here's a real world example. Two SVG icons from the same github repo: https://camo.githubusercontent.com/e448a75c4115d60100a0a2b29d9143c195670907/68747470733a2f2f73332d75732d776573742d322e616d617a6f6e6177732e636f6d2f737667706f726e2e636f6d2f6c6f676f732f746f7275732e737667 https://camo.githubusercontent.com/e448a75c4115d60100a0a2b29... https://camo.githubusercontent.com/d9522bd55c6c95a14f51f8e7c8619a8d372e88ed/68747470733a2f2f73332d75732d776573742d322e616d617a6f6e6177732e636f6d2f737667706f726e2e636f6d2f6c6f676f732f6b657963646e2e737667 https://camo.githubusercontent.com/d9522bd55c6c95a14f51f8e7c... While they are in the exact same repo/collection, they have clashing gradient names. If you grabbed those and put them both inline, in the same page, it wouldn't work. It also doesn't play well with dynamic content where you have the cache headers set to not allow local browser caching, as it causes a second request. Would have been nice if there was an additional way to reference the gradients, maybe css (not using a url fragment that is...defining the gradient itself).
  - jancsika 9y ago
    > It's not hard to to do it manually for a single svg, but having to track the namespace and match them back to the right svg element via url fragments is cumbersome in a real world site. Ah, I see. Yes, you're right. Additionally, the HTML5 spec is written such that FuncIRIs won't work in about:blank, making it impossible to quickly test svg gradients or patterns in Firefox. (But it works in Chromium for some reason, which is nice.) I think the Snap.svg framework gets this right-- it allows the user to specify the gradient with a single string, much like the "d" path data.
    - jancsika 9y ago
      > While they are in the exact same repo/collection, they have clashing gradient names. If you grabbed those and put them both inline, in the same page, it wouldn't work. Seems like the only way around that is to take a hash of the gradient.innerHTML and use that as the id of the gradient. Of course that increases the size of the svg file, but as you point out it's necessary (comically so, given all the complexity of xml namespaces don't prevent this clash).
      - jancsika 9y ago
        > Seems like the only way around that is to take a hash of the gradient.innerHTML ... in which case the same gradient in two different inline svgs would create a duplicate id. Too bad CSS gradients don't work in svg shapes.

pen2l 9y ago

I love SVG in general... I am curious to hear, is there any reason not to use them? Maybe that it's not as well supported on older browsers?

edent 9y ago
The only serious argument I've heard against them is that it makes life easier for people who want to reverse engineer your graphics. But, frankly, I'm switching as much of my stuff over to them as possible.
Silhouette 9y ago
I am curious to hear, is there any reason not to use them? As an alternative image format to things like PNG? There aren't many, if it's an image that lends itself to a vector format in the first place. SVGs have been widely supported for some time, often have significant file size benefits as we see here, and scale cleanly to different screen resolutions. You have to go back to versions of IE that even the likes of Microsoft and Google won't support any more or to very old mobile devices to start running into general compatibility problems. One thing to be aware of is that you are effectively programming your graphics if you're using SVG, not just recording the image itself. If you start playing with the more powerful features, particularly using non-trivial filters, you might occasionally run into issues in the rendering code that turns your program into an on-screen image. Depending on how much of that code is in the browser itself and how much is delegated to the underlying OS/graphics drivers for acceleration, that can cause problems including slow display of images, distortion so the rendered image doesn't look right, or in extreme cases even hanging the browser or graphics driver if you're unlucky enough to trigger some underlying bug (which is obviously a rare result, but I have personally seen it happen in my own development work). For the kinds of very simple SVGs we're looking at here, I can't imagine any of these potential problems being a serious risk, though.
RazrFalcon 9y ago
It doesn't supported well even in modern browsers. There are so many edge-cases that are completely ignored. Yes, you probably newer encounter them, but they are still there.

userbinator 9y ago

is very efficient size-wise Compared to raster graphics, yes. Compared to other vector formats like SWF, no.