Added parameter to avoid using ranges when creating tspans for mobilesafari; Added support for CSS transforms.

[LuigiPower]

When creating tspans on mobile Safari using the ranges, the output comes out empty. Using text content + string manipulations yields correct results (tested on an iPhone SE and an iPad). The change doesn't seem to affect behaviour on a desktop.

CSS Transforms were completely ignored by the library, as far as I'm aware. As the HTML element contains CSS transforms, and SVG transforms operate on a different coordinate system, I had to convert CSS transforms to SVG transforms.
To do this, I've computed the transform attribute on the final svg element by:

• Moving the element so it's center is positioned in svg coordinates 0,0
• Applying the computed style transformation matrix
• Moving the element back to it's position

This method should work correctly with all kinds of SVG transformations, but I've only tested a rotation around the center, as that was my use case.

[felixfbecker]

Thanks for the contribution! There seem to be two PRs in one here (it would be better to separate them, but I'll give my thoughts below):

1. Re using Selection: textContent is not equivalent to Selection.toString(). Selection.toString() applies (the very complex) whitespace collapsing algorithm per the HTML spec. This is necessary because SVG does not collapse whitespace in text, so we need to collapse it before outputting it into the SVG. textContent has all whitespace in it, so using it is not correct and will yield weird results for whitespace. I also connected to iOS Safari with the Safari remote debugger but I see Selection.toString() working fine, do you have an example where it fails?

2. Re handling transforms: Do you have an example page that fails currently? Currently we position SVG elements by the HTML element's getBoundingClientRect(), does that not include applied transforms?

[LuigiPower]

1- On my iPhone SE and two iPads (of which I don't know the exact model but were bought around 2017), the text appeared completely wrong in my implementation (every new line contained the entirety of the text instead of the single line). It might have been a layout problem, but switching the selection to using textContent seemingly solved all my problems and the SVG got created correctly. If I get a chance I'll try and replicate the problem in the my old implementation with the "normal" version of this library so we can find out.

2- I can try and replicate the problem in this case as well, as it's the same situation I had in point 1. The transformation matrix was correctly computed, but it was not applied correctly due to the difference between CSS and SVG coordinate systems. In my case the dom to transform is a complex layout made of multiple React components, each with its' own style and absolute positioning, so the rotated elements would "vanish" because of the wrong rotation pivot point. I tested my changes on Firefox, Safari, Mobile Safari, Chrome and while before my elements vanished, after the changes they appeared correctly.