Work around libxml2 namespace reconciliation for SVG elements in HTML5

Yes, this is ugly.

Author: mpdude

src/Webfactory/Dom/PolyglotHTML5ParsingHelper.php

@@ -17,6 +17,8 @@ protected function sanitize($xml)
     {
         $xml = parent::sanitize($xml);
 
+        $xml = str_replace('xmlns="http://www.w3.org/2000/svg"', '_xmlns="http://www.w3.org/2000/svg"', $xml);
+
         $escaped = str_replace(
             array('&', '<', '>', '"', '''),
             array('&', '<', '>', '"', '''),
@@ -55,6 +57,8 @@ protected function fixDump($dump)
             }
         }
 
+        $dump = str_replace('_xmlns="http://www.w3.org/2000/svg"', 'xmlns="http://www.w3.org/2000/svg"', $dump);
+
         return $dump;
     }
 }

test/Webfactory/Dom/Test/PolyglotHTML5ParsingHelperTest.php

@@ -44,4 +44,39 @@ public function testHtmlEntitiesSupportedAsConvenience()
 
         $this->assertEquals('<p>ä x ö x ü " &lt; &gt; \' <x foo="&quot; &lt; &gt; \'"></x></p>', $d);
     }
+
+    public function testSvgNamespaceIsNotReconciled()
+    {
+        /*
+         * libxml2 will attempt (under which circumstances?) to reconciliate namespace declarations, that is, find
+         * namespaces used by several nodes and move these declarations up the DOM tree.
+         *
+         * This also affects the default namespace as commonly used by <svg> inlined in HTML5 documents. As you cannot
+         * move the default namespace away from an element, libxml turns it into a regular "named" namespace and
+         * chooses a namespace prefix like "default" (sic), possibly followed by a number, for it. This happens
+         * in xmlNewReconciliedNs, see https://github.com/GNOME/libxml2/blob/35e83488505d501864826125cfe6a7950d6cba78/tree.c#L6230.
+         *
+         * The result is that markup like <svg xmlns="http://www.w3.org/2000/svg"><path ...></path></svg> will be turned
+         * into <default:svg><default:path>...</default:path></default:svg>, with xmlns:default="http://www.w3.org/2000/svg"
+         * somewhere up the tree.
+         *
+         * This is reported (not for the SVG namespace, but the general case) at https://bugs.php.net/bug.php?id=55294
+         * and https://bugs.php.net/bug.php?id=47530, with the conclusion that it would need to be fixed in libxml2.
+         *
+         * libxml2, on the other hand, will argue that the result is perfectly fine when applying XML semantics. The
+         * problem is that browsers may or may not make this distinction. According to https://stackoverflow.com/questions/18467982/are-svg-parameters-such-as-xmlns-and-version-needed,
+         * it might depend on wheter the page is served as application/xhtml+xml or text/html. In the latter case,
+         * XML namespace semantics do not apply.
+         *
+         * For <svg> in HTML5, a possible workaround is to completely remove the XML NS declaration: This is
+         * possible as <svg> is included in HTML5 as a "foreign element" (https://www.w3.org/TR/html5/syntax.html#foreign-elements).
+         * That is, the elements from the SVG namespace are also valid in HTML5.
+         *
+         * Instead of completely removing the xmlns, our current workaround is to move the namespace declaration
+         * "out of the way" when parsing the XML and fixing it up again later when dumping the XML.
+         */
+        $this->readDumpAssertFragment(
+            '<div><svg xmlns="http://www.w3.org/2000/svg" class="x" width="300" height="150" viewBox="0 0 300 150"><path fill="#FF7949" d="M300 5.49c0-2.944-1.057-4.84-2.72-5.49h-2.92c-.79.247-1.632.67-2.505 1.293L158.145 96.56c-4.48 3.19-11.81 3.19-16.29 0L8.146 1.292C7.27.67 6.43.247 5.64 0H2.72C1.056.65 0 2.546 0 5.49V150h300V5.49z"></path></svg></div>'
+        );
+    }
 }