Option to remove `standalone="no"` from XML declaration

[Volker-E]

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

As standalone="no" is the default value it should be stripped from SVGs by SVGO. One could go further and strip it anyways by default as the only relevant use case were a given DTD, which on the other hand is error prone (and to be removed in SVG 2 and set to remove by SVGO by default as of now.

Currently you can't reach into XML declaration with for example removeAttrs plugin.

[GreLI]

Generally, there is removeXMLProcInst plugin that removes XML processing instructions at all. SVG images don't need them really.

[Volker-E]

@GreLI There doesn't seem to be a definite answer if there are editors/browsers not rendering SVGs due to a missing XML declaration?! I vaguely remember that I've run into issues around it (maybe sev years ago?). Therefore I've tested with BrowserStack through all kinds of browsers/OS combinations going back to IE 9 on Win7, Opera 12.16, Firefox 3.6, Samsung with Android 2.3 with both – a standalone SVG without XML declaration and a HTML page loading the same SVG as CSS background-image. And although the last two had issues, the issues didn't seem connected to the test scenario and it seemed generally fine not to include the XML declaration. In my work resulting in this thread I was following this StackOverflow answer together with my described past experience. If I'm wrong with the necessity of including the declaration we might shove a huge number of unnecessary data down the line.

Although XML 1.0 states it's optional, it would be good to have a consensus what issues might arise from leaving it out.

[GreLI]

AFAIK, Firefox 3.6 doesn't support SVG except in <object>, and Android 2.3 doesn't support SVG at all. These are surely “issues”, but I think, it doesn't worth supporting SVG for them—a fallback should be provided in a such case.

I've heard nothing about something couldn't render SVG because of absent prolog. The only case was, that some primitive utils like file couldn't get MIME-type right, discussed in #306.

[Volker-E]

Citing @Krinkle at https://phabricator.wikimedia.org/T178867#3801679

The main concern I'd have is MIME-type checking (e.g. https://github.com/svg/svgo/issues/306).

Many MIME-type tools wrongly interpret files starting with <svg as something different.

With <?xml header: image/svg+xml. Without:

• PHP 7.1 mime_content_type on macOS: text/html
• file command on Linux: text/plain
• file command on macOS: image/svg (promising!)

I know that within our systems, ResourceLoader (CSSMin) and MediaWiki more generally prefer mime-type guessing based on file name in many cases, but not all cases. So I can't confidently say nothing will break when we remove the header.

So the XML declaration is useful in those use cases, but it should be able to boil it down to the bare minimum <?xml version="1.0" encoding="UTF-8"?>…