3 ms·

What makes gradient fills for inline svg difficult?

tyingq 10y 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 10y 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 10y 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 10y 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.

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