SVG output is unnecessarily verbose.

[pdamoc]

Can the output have some patterns replaced based on a series of simple rules?

For example, with the following output:

svg [ height "327", width "763", attribute "xmlns" "http://www.w3.org/2000/svg" ]
    [ node "path" [ attribute "d" ...
    ...

maybe replace node "path" with path, attribute "d" with d and attribute "xmlns" with xmlSpace

If a simple dictionary of these correspondences can be maintained, the output could look much better.

[mbylstra]

Sure thing. html-to-elm does this for html tags and attributes by listing the names in https://github.com/mbylstra/html-to-elm/blob/master/elm-src/HtmlToElm/ElmHtmlWhitelists.elm. I never got round to doing this for svg. All that needs to be done is to list the SVG tags and attributes in this file. However, I hadn't considered the case where elm-svg tag and attribute functions do not have identical names to the html tags/attributes, such as with xmlSpace and animateColor. So, as a first improvement, names such as d and path can just be added to these lists. A refactor would be needed to support camelcase and ':'s.

[mbylstra]

@pdamoc writes in #11:

Now, the main challenge is around attributes that clash with nodes as it is the case for clipPath and with attributes that solve to a non-obvious name as it is the case with xmlns -> xmlSpace

[mbylstra]

I think the easiest solution for clipPath is to use the fully qualified names Svg.clipPath and ``Svg.Attributes.clipPath`. As you suggest at the top of the issue, the list of whitelisted tags and attributes can be replaced with a dict to deal with names that aren't an exact correspondence.

A bigger issue is when html and svg is used at the same time - there are many clashes between the html and svg libraries such as text. We'd obviously prefer not to use fully qualified names for html. However, solving html and svg clashes and preserving short names where possible would require a lot of intelligence from html-to-elm (it's currently very dumb). Perhaps just a simple warning to html-to-elm users that you cannot currently combine html and svg would suffice for now. I can imagine a lot of very confusing compiler error messages if they are used together.