3 ms·

> 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

> 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?

jonathanlydall 2mo ago
SVGs can define styles and element ids. 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.
- jancsika 2mo ago
  Why not use classes instead of element ids?
  - jonathanlydall 2mo ago
    When I referred to “styles” I was referring to classes. 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.
    - jancsika 2mo ago
      Ah, I see. 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 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.
      - bawolff 2mo ago
        That's not really the problem namespaces were intending to solve in XML. (XML namespaces are about extensibile semantics, not content isolation)
        jancsika 2mo ago
        Right. It's just funny that there is an always-increasing number of extant cases like OP's for SVG and/or internal hyperlink specs where content isolation would have been much appreciated, and literally zero cases I can think of where anyone used XML namespaces to extend either SVG or hyperlinks. (As well as the case I mentioned above where the working group apparently just said "fuck it" wrt specifying xlink at all.) 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.

jonathanlydall 2mo ago

SVGs can define styles and element ids. 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.

jancsika 2mo ago
Why not use classes instead of element ids?
- jonathanlydall 2mo ago
  When I referred to “styles” I was referring to classes. 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.
  - jancsika 2mo ago
    Ah, I see. 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 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.
    - bawolff 2mo ago
      That's not really the problem namespaces were intending to solve in XML. (XML namespaces are about extensibile semantics, not content isolation)
      - jancsika 2mo ago
        Right. It's just funny that there is an always-increasing number of extant cases like OP's for SVG and/or internal hyperlink specs where content isolation would have been much appreciated, and literally zero cases I can think of where anyone used XML namespaces to extend either SVG or hyperlinks. (As well as the case I mentioned above where the working group apparently just said "fuck it" wrt specifying xlink at all.) 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.