Open pdamoc opened 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.
@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
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.
Can the output have some patterns replaced based on a series of simple rules?
For example, with the following output:
maybe replace
node "path"
withpath
,attribute "d"
withd
andattribute "xmlns"
withxmlSpace
If a simple dictionary of these correspondences can be maintained, the output could look much better.