> We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
What do you mean by "named the same" here?
What do you mean by "named the same" here?
The problem is if these same element ids and styles are used in different places in your DOM, including other SVGs.
Our product is a bit of a platform with extensibility which includes icons for ui elements. It was very easy for us or our users to accidentally use the same style names or element ids when exporting from Adobe Illustrator, especially for icons which are similar to others and started as a copy.
When using SVGs as a background it’s not an issue, but we want our SVGs to be able to have different colours be usable in light or dark mode which CSS can do, except it doesn’t work when making the SVG a background.
Shadow DOM solves this issue perfectly.
If the same class was defined in a multiple SVGs under their respective <style/> elements, they would affect each other.
So sometimes if two icons were in the DOM at the same time, the one’s colours might look wrong since both had the same class names they were using.
Element ids were also not used so much for styling but instead for common SVG components (or something, I don’t know the terminology), so would similarly cause rendering issues.
Like I said it was especially common if the one started as a copy of the other in Illustrator.
The “fix” was to ensure unique element ids and class names, but this was an annoying extra step.
Using a shadow DOM for each icon which is an SVG circumvents the entire problem as they ignore anything outside their isolated DOM.
What's so funny about this is that XML is absolutely brimming with rich namespace solutions for all the problems you don't have. For example, if your users ever want to blithely roll their own "href" namespace, don't worry! The xmlns http://www.w3.org/1999/xlink is there for them to safely disambiguate all the custom:hrefs from the xlink:href things!
Meanwhile, in 2026 you've got two designers who each use their own "bgcolor" and XML is like, "Nope!"
Digression-- I just checked MDN and apparently xlink is deprecated! This makes me want to write alternate history from the mid-2000s about the href wars: XML namespacing parties where front-end designers would mash up dozens of href namespaces in the same document.
Even toy examples! I'm trying to think back through my recollection of the W3C archives, and I can't remember a single time when a proposed feature had a demo that utilized XML namespaces. Unnamespaced pseudocode, yes. JS polyfills, yes. XML namespaces? Please link me some examples for my fan fiction research.