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