1. Why does text/xml not work? That demo isn't particularly clear about the inputs. I would not expect a different result between that and application/mathml xml.
2. We don't really want to extend DOMParser. See Add DOMParser option to parse declarative shadow DOM #8759.

Sorry for the lack of clarity. markup.js exports a string containing a MathML document. Depending on the toggle state, it is rendered as .innerHTML or after being parsed as text/xml.

The latter doesn't work, it renders plain text.

🎉 for setHTML() and friends. new DOMParser().parseFromString(src, type) is needlessy convoluted.

The only reason I'd see to pursue adding a MathML mime type to DOMParser would be a matter of velocity re. shipping the feature. If I get it correctly, it is as complex as adding an entry in the .idl/.webidl files and a few tests, whereas setHTML is still being spec'ed out.

In order to use MathML with XML syntax, you need to use the MathML namespace. That is <math xmlns="http://www.w3.org/1998/Math/MathML"><!-- content here --></math>. Otherwise, it will parse as an element with the name math in no namespace, which will render with the default CSS properties. This is probably what you're seeing when you say it renders as plain text. So parsing with text/xml works as it should.

If you want to use the HTML syntax for MathML, you could just use something like new DOMParser("<math><!-- content here --></math>", "text/html").querySelector("math").

Thanks @andreubotella, my bad, indeed, I picked a MathML sample from the Web and didn't check the XML name space. So DOMParser with text/xml works for the XML syntax.

My use case is the m.trust() API in Mithril.js, which creates a vnode that can render arbitrary markup (think React's dangerouslySetHTML, but these nodes can have siblings). The engine knows if these nodes are rendered in HTML, SVG or MathML context, and parses the markup accordingly (with custom logic to make sure nodes that require a specific parent like <td> aren't stripped by the parser).

We use some logic that looks like your suggestion for SVG, but is built on top of .innerHTML because we had to support IE back in the day, and it didn't support DOMParser (at least some versions didn't).

The optimal solution in any case would be to rely on something like setHTML once it ships.

Thanks for your input!