This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG (which obviously only works if your SVG renderer also supports at least a subset of HTML). SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.
> - cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how?
Somebody did think of it. SVG 1.1 added the `<font>` element[1]; SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already, so it’s obvious why this was changed, but embeddable SVG fonts have existed for a long time (I don’t know why/how they got memory holed).
> - browsers do not publish, which version and features they support
It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly in most places.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.
There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.
There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)
Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.
This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG (which obviously only works if your SVG renderer also supports at least a subset of HTML). SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.
> - cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how?
Somebody did think of it. SVG 1.1 added the `<font>` element[1]; SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already, so it’s obvious why this was changed, but embeddable SVG fonts have existed for a long time (I don’t know why/how they got memory holed).
> - browsers do not publish, which version and features they support
It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly in most places.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.
There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.
There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)
Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.
[0] https://www.w3.org/TR/SVG2/text.html#InlineSizeProperty
[1] https://www.w3.org/TR/SVG11/fonts.html
[2] https://www.w3.org/TR/SVG2/changes.html#fonts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
[4] https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessing...