Declare the namespaces in the <svg> about bytefield-svg HOT 8 CLOSED

I used to include these, and removed them because they caused validation errors the way that @Swiftb0y was serving pages. I may have parameterized that though, let me take a look.

from bytefield-svg.

How are you calling it? This is controlled by the embedded argument as described on the project homepage: https://github.com/Deep-Symmetry/bytefield-svg#invoking-from-javascript

from bytefield-svg.

Yes, it appears that kroki is specifically requesting that bytefield-svg omit these headers. If you stop doing that, they will be present: https://github.com/yuzutech/kroki/blob/8cd767e2c4f213d6d22d7ae12b2c0c278348da12/bytefield/index.js#L12

from bytefield-svg.

For a chuckle see also #13 😆

from bytefield-svg.

Ooops, I forgot about that sorry 😓

from bytefield-svg.

No worries! I wrote the silly thing, and didn’t remember how it worked until I went back and looked! Hopefully you will have a straightforward way of deciding when you want to generate embedded svg elements or standalone SVG files?

Can we close this issue?

from bytefield-svg.

Hopefully you will have a straightforward way of deciding when you want to generate embedded svg elements or standalone SVG files?

Not really but I will opt for the "standalone" mode. In my opinion the header <?xml version="1.0" encoding="UTF-8" standalone="no"?> should be removed because, as far as I know, it does not bring any value (but I might be wrong).
Having said that, other popular diagrams librairies (for instance, PlantUML) are using it so I can live with that.

Can we close this issue?

Yes, sorry about the noise 🔇

from bytefield-svg.

Unfortunately I get that XML header from the library I use when I tell it to wrap an SVG file, so we would need to open the issue upstream to remove that.

from bytefield-svg.