> Why does text rendering in svg elements always look slightly off?

The rendering of text is pixel exact between HTML and SVG in every modern browser I've tested with.

What you might be noticing is the distance between consecutive lines of text. HTML can flow text in a rectangle and automatically handle whatever inter-line settings were given in CSS (or the browser default).

SVG cannot flow text-- the user has to specify an x,y for each line. My guess is that it's difficult to figure out how to replicate whatever the HTML algo is for interline spacing of text for arbitrary fonts.

Additionally, the SVG library would need to manually handle word wrapping.

Just with those two you can easily end up in the uncanny value of SVG, especially when the user starts zooming in or out.

If you're confident that you'll always be dealing with a browser environment, this is a situation where embedding HTML in SVG via <foreignObject> is a pretty reasonable approach, IMO.

what do you mean by "pixel exact". svg definitely renders differing amounts of pixels on my different devices. one with dpr 2.0, one with dpr 3.0, one with dpr 1.25

They mean that a specific browser version on a specific device renders text the same regardless of whether you use html or svg.

Possibly different subpixel antialiasing and hinting settings in the SVG renderer and for text outside of SVG elements.

My hunch is that subpixel antialiasing and hinting is disabled for SVG elements. As withing SVG images you typically have some amount of vector graphics surrounding a few text elements, it could probably also look off if it was applied to the text parts of the image, but other shapes would be unaltered.

Technically you could trivially apply subpixel antialiasing for all kind of shapes within the SVG image. Possibly it's even possible to apply some hinting at limited scenarios (horizontal and vertical lines). I don't think any browser SVG renderer does any of this.

edit:

I tested this now with Edge on Windows, and I get subpixel antialiasing for both within and outside SVG. So maybe this theory does not hold up.

I do not get a pixel-perfect match however, but that could be because of subtle subpixel positioning of the text itself.

> I do not get a pixel-perfect match however, but that could be because of subtle subpixel positioning of the text itself.

It almost certainly is because you're not putting them at the same position in the page.

There's a hack to normalize the positioning of an HTML to match the x,y position of an SVG text, but I can't remember what it is atm.

Edit: typo

Probably because there hasn't been a ton of browser-level work on their SVG engine, as opposed to CSS rendering at least. Like the SVG2 spec has been lingering for years. Personally I'd love to see more activity there - SVG is awesome and it has more potential than is currently being utilized (IMO).