`svg:` prefix breaks detection as SVG file

[aamnah]

Hi, i'm a web developer currently designing a weather app and landed here after coming across this presentation. Great work with the SVGs!

Is there any particular reason we have tags like svg:svg, svg:title, svg:description, svg:metadata, svg:g and so on in the files? They seem to break preview on Github and make it impossible for design tools like Figma to detect them as SVGs. If i remove the svg: prefix, they are detected without any issues. To be honest, i have never seen this svg: prefix in my years of web development, so really curious as to why it is there. Scripting reasons maybe?

On Github, i get the code Error rendering embedded code. Invalid image source.

On Figma, i get Failed to import. Unable to convert SVG

In order to make them usable (in design tools that are not Inkscape), I was able to update all files with a bash one liner

grep -rl 'svg:' ./ | xargs sed -i 's|svg:||g'

[chris-little]

@aamnah Thank you for the comment and issue. @chris-little and @tomkralidis will discuss offline. But the reasons are almost certainly historical.

1. When SVG adoption started becoming widespread, the svg: prefixes were used to make each symbol a standalone SVG 'picture', so they would display in GitHub and other environments, such as non-Web based. Nowadays, you are right - svg is commonplace and much better integrated into ecosystems. (For example, the very first users of the weather sysmbols immediately converted them in to PNGs to use in their appplications!)
2. I suspect the multiple svg:svg: .. prefixes may be a consequence of reuse of symbol fragments. Again, this may have been because early svg renderers did not all implement "fragment re-use" (groups = <g>...</g>) and we wanted to only use SVG V1.0. I think that at the time, V1.1 was published, but V1.2 and later were moving targets.
3. We also wanted to embed the full semantics of each symbol, as defined by WMO/OMM, with reference to their machinable register.
4. Work that we never finished, or even started, was support for the bicolour versions of the symbols, as defined by WMO/OMM, as efficiency of displaying 1000s of symbols in sub-second response times was, and is, an issue. We could not decide on the most effecive approach.
5. I agree that support outside of Inkscape is needed.

[aamnah]

Thank you for taking the time out to explain it for me :) Let me know what kind of work is required for the bicolour versions and maybe i can contribute? I have already got a Figma file going here for my own use case. If my understanding of bicolour version is correct, then it is multi-color icons in SVG and nothing too domain specific and technical. Feel like i should be able to handle.

[chris-little]

@aamnah If you loook at my original fork of this repo you will see that the SVGs renders correctly, even though they have the svg: namespace prefix. I suspect that the scripting on this repo has introduced some artefact to stop the rendering. @tomkralidis have you any suggestions?

[tomkralidis]

I'm not sure what would have happened over the years, the syntax appears pretty much the same.

Any XML parser should treat the below functionally equivalent, i.e.:

Explicit namespacing (master branch)

<svg:svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" version="1.1" width="55" height="55" viewBox="0 0 55 55" id="svg3816">

Implicit namespacing

<svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.w3.org/2000/svg" version="1.1" width="55" height="55" viewBox="0 0 55 55" id="svg3816">

Having said this, I've issued #49 with implicit namespacing for testing/review. If this works for your use case @aamnah, we can merge given they also pass CI.