Currently, SVG images [^1] are not allowed to link to any other resources, even when these resources are same origin, which severely cripples them across several areas.
Pain points
Fonts
This is probably the biggest issue today.
SVG images cannot reference any web fonts, so any text is limited to system fonts. This is now even more restrictive than in the past, as Apple has excluded user-installed fonts from font matching, which restricts SVG images to preinstalled system fonts.
In practice, authors result in the following workarounds, both with severe downsides for end-users:
Using a vector graphics application to "convert fonts to outlines", i.e. convert each flyph to a <path>. Sometimes there is textual fallback, but usually not.
Embedding the entire web font into the SVG as a data URI. This is a real example from a D2 diagram:
Both of these workarounds are wasteful wrt bandwidth, which is particularly harmful to users in developing countries, and the first creates a serious accessibility issue. The 2nd workaround privileges languages with certain scripts more than others (e.g. East Asian fonts tend to be way too large for 2 to be viable).
Duplication galore
Stylesheets: SVG images cannot reference stylesheets, so they have no access to the page’s design tokens (colors, fonts, etc.). In practice authors have to duplicate these in the SVG and maintain multiple sources of truth.
Other SVGs: They cannot reference other SVGs via the <use> element so simple variations, such as a different color (e.g. a dark mode version), a modifier (e.g. a + icon at the bottom right) duplicate the entire graphic.
Potential solutions
At the very least, linking to resources in the same origin should be safe, and already solves a swath of use cases. Ideally there should also be an opt-in of some sort for external ones, so that use cases like downloading diagrams can just work. Hopefully CORS can be reused, so we don’t have to introduce yet another mechanism.
Specifically for fonts, another solution could be to bring SVG fonts back, and redesign them around the use case of making converting text to outlines less problematic (which is essentially what PDF does, I think?). It is far more palatable to convert glyphs to outlines once rather than every time the glyph is used, and it completely resolves the accessibility issues. This may be worth it on its own, to make it possible to create self-contained SVG images with custom fonts.
[^1]: Meaning SVG files used in image contexts, such as CSS images, or HTML’s <img> element.
Currently, SVG images [^1] are not allowed to link to any other resources, even when these resources are same origin, which severely cripples them across several areas.
Pain points
Fonts
This is probably the biggest issue today.
SVG images cannot reference any web fonts, so any text is limited to system fonts. This is now even more restrictive than in the past, as Apple has excluded user-installed fonts from font matching, which restricts SVG images to preinstalled system fonts.
In practice, authors result in the following workarounds, both with severe downsides for end-users:
<path>. Sometimes there is textual fallback, but usually not.Both of these workarounds are wasteful wrt bandwidth, which is particularly harmful to users in developing countries, and the first creates a serious accessibility issue. The 2nd workaround privileges languages with certain scripts more than others (e.g. East Asian fonts tend to be way too large for 2 to be viable).
Duplication galore
<use>element so simple variations, such as a different color (e.g. a dark mode version), a modifier (e.g. a + icon at the bottom right) duplicate the entire graphic.Potential solutions
At the very least, linking to resources in the same origin should be safe, and already solves a swath of use cases. Ideally there should also be an opt-in of some sort for external ones, so that use cases like downloading diagrams can just work. Hopefully CORS can be reused, so we don’t have to introduce yet another mechanism.
Specifically for fonts, another solution could be to bring SVG fonts back, and redesign them around the use case of making converting text to outlines less problematic (which is essentially what PDF does, I think?). It is far more palatable to convert glyphs to outlines once rather than every time the glyph is used, and it completely resolves the accessibility issues. This may be worth it on its own, to make it possible to create self-contained SVG images with custom fonts.
[^1]: Meaning SVG files used in image contexts, such as CSS images, or HTML’s
<img>element.