Closed tmhpfnr closed 8 years ago
Sorry for the delayed response.
I've been having a look into this but I'm not 100% sure on the best way to move forward with it. I see that it's an issue but as XML should be case sensitive I'm not sure how to proceed.
My initial thought was lowercasing the whole XML string before parsing, but that's going to break stuff. We could potentially use something like this but I don't like that idea, it seems very hacky and a massive pain.
Any ideas?
I like the idea to keep it compatible to existing implementations. Why not just adding the missing (lower camel case) attributes/tags to the default list (like I did here). In my opinion your library should support the standardized attributes and tags, everything else is customization. I can't see any reason to support upper and lower case variants for the whole XML string.
A more detailed approach are different strategies for different use cases. In my case, I need a sanitized HTML inline SVG to style the paths via CSS and remove all (XML) comments, to keep the final HTML output clean.
That sounds fair enough to me, support the camel case tags and leave it open to customisation by other implementations.
When I get a moment, I'll add the camel case tags to the default list!
Hi! IMHO the whitelisted attributes and tags should be case sensitive, e.g. viewbox becomes viewBox.