svg
svg copied to clipboard
Use of xlink:href in SVG causes rendering problems
This is similar to #22 but I thought I would add more details since this was actually causing problems with rendering.
Summary: Use of xlink:href
in SVG output causes rendering problems with the shadow DOM and IDs.
Minimal demo: An Ellie was created. This demo shows three examples of SVG. The structure of the SVG has common shapes (the note-heads, for example) defined once, and then re-used by reference in the body.
- The top uses
xlink:href
and renders using the Elm view, using the elm-svg-parser to turn a string into Html nodes; as you can see the note heads and other symbols do not appear. The shapes that are defined in-line (the staff lines and note stems) display fine. - The middle is the same setup, except all
xlink:href
references have been replaced with justhref
. - The bottom is the control; this is the exact same SVG as in the first example, but set using
innerHTML
directly in the JavaScript. The references are stillxlink:href
. This displays correctly.
The best I can figure is that the use of xlink:href
does not work with the Shadow DOM or the Elm DOM diffing system; only href
works. Outside of the Shadow DOM, it works fine.
The following screenshot shows the output of the DOM; As you can see, in the second and third examples, the Shadow DOM node correctly 'points' to the shared symbol definition and shows it as a child.

Note that this isn't necessarily an issue with the SVG generator in Elm, and the application that generates the SVG examples here is being updated to support non-namespaced href attributes. But since #22 is still open and gathering use cases and examples, I thought it would be good to add another account of my experiences.