mbylstra / html-to-elm

An online tool for converting HTML to elm-html. Go to
http://mbylstra.github.io/html-to-elm/
394 stars 23 forks source link

SVG output is unnecessarily verbose. #10

Open pdamoc opened 8 years ago

pdamoc commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@pdamoc writes in https://github.com/mbylstra/html-to-elm/pull/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 commented 8 years ago

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.