Add elm/svg support

[YetAnotherMinion]

I wanted to use something like this library to work with SVGs. I factored out the String.Types module so that both Html and Svg modules could use the same serialization code.

Because the name of this library is elm-html-string, maybe it is better to put the svg support into a new elm-svg-string package instead.

[YetAnotherMinion]

Hold on. The toSvg function is not writing out properties other than id when converting to virtual dom nodes.

[YetAnotherMinion]

I ran into what looks like a fundamental difference between attribute names in JavaScript and HTML/SVG For all the builtin HTML attributes it looks like the rule is the hyphenate the string version. On the other hand for SVG it looks like attributes should not be hyphenated.

I made a quick hack in 550ed67 by adding a boolean parameter to Attribute and AttributeNS variants that controls if the attribute name should by hyphenated when converting to string. It got the SVG side working for my specific project, but adding a bool is an ugly solution.

I don't know what the rules are for hyphenating attributes in either HTML or SVG so I am not committed to using the bool flag.

[zwilias]

Right, I think this needs some more up-front design before diving into the implementation.

The easy part:

• abstracting Html.Types into a virtual-dom like construct
• converting to VirtualDom.Node a rather than Html a
• dealing with hyphenation: this shouldn't happen on attributes, so that's a bug in the current implementation

The hard part:

namespaces. There's sort of a mismatch between how the DOM works and how it's serialized.

In the serialized version, there's the default namespace, which can be set for an element (and its descendants and attributes), and there are named namespaces which can be used to namespace specific attributes (i.e. xlink).

In the DOM, however, namespaces have to be specific when creating nodes. Attributes use the default namespace of the node, unless specific otherwise. There is no concept of named namespaces, however.

Elm's virtual dom is - understandably - geared towards the DOM, rather than serialized HTML. As such, the transformation isn't very straightforward.

So the goal is to find a dependable way to make this transformation, without making very large sacrifices on the performance front.

This is something I'd like to think about some more, and figure out a design that works!

---

Long story short: give me some time to figure out a design that works 🙂