Handeling the <defs> block in SVGs

[FWeinb]

Currently the block is ignored. So merging svgs that are build with custom filters or <use> will break!

Ids aren't a problem because all ids are prefixed by the md5 hash of the file they are from, so there aren't any collisions.

[TxHawks]

+1 for fixing this.
Would allow for gradients the use of gradients. perhaps the easiest way to handle this would be to move each def to its own element at the top, so the can be used later.

So something like this:

<svg>
  <defs>
    <linearGradient id="grad1" x1="0%" y1="0%" x2="100%" y2="0%">
      <stop offset="0%" style="stop-color:rgb(255,255,0);stop-opacity:1" />
      <stop offset="100%" style="stop-color:rgb(255,0,0);stop-opacity:1" />
    </linearGradient>
  </defs>
  <ellipse cx="200" cy="70" rx="85" ry="55" fill="url(#grad1)" />
</svg> 

would become something like this:

<svg>
  <defs>
    <linearGradient id="grad1" x1="0%" y1="0%" x2="100%" y2="0%">
      <stop offset="0%" style="stop-color:rgb(255,255,0);stop-opacity:1" />
      <stop offset="100%" style="stop-color:rgb(255,0,0);stop-opacity:1" />
    </linearGradient>
    <g id="icon1">
      <ellipse cx="200" cy="70" rx="85" ry="55" fill="url(#grad1)" />
    </g>
  </defs>
</svg> 

This should work, right?

[FWeinb]

This will only work if you don't set the svg-sprite to display:none; so you have to use width:0px;height:0px;visibility:hiddento hide the svg. I do not know if there are performance issue with that.

See: http://codepen.io/FWeinb/pen/0986be8a8292ee1902aa7648dc2d97c4

[FWeinb]

This should be fixed in version 0.2.0

[TxHawks]

I don't know for a fact, but can imagine this could have a pretty significant performance impact if you have a lot of rather complicated icons, as they will all be rendered by the browser an additional time. Not ideal.

Since we aren't limited to one defs-svg, I think that it may be a better idea to simply create a second svg just for the def blocks.

Here is an example: http://codepen.io/veganarchist/pen/FCHxJ

[FWeinb]

I will investigate a little bit more in performance on this. I think that the impact might not be that big because elements that have visibility:hidden are only taken into account for layout.