This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification disallows any type for DOMParser.parseFromString that isn't enumerated. That means anything except SVG and XHTML has to pretend to be generic XML, even though SVG and XHTML don't actually get any special treatment from the algorithm, so why not let other XML types be honest about what they are and use their full MIME type? Right now Webkit browsers actually behave that way (i.e. you can use "application/whatever+xml" as the second argument to parseFromString and they won't throw an error), while Firefox follows the spec to the letter.
So what is the use case you have? If you just want a Document created from a string, why don't you pass "text/xml"?
Note that Blink also follows the spec here.
I know I can just pass "application/xml" or "text/xml". I just don't like that the DOMParser as specified uses an argument that *looks* like a MIME type but doesn't behave accordingly. It's misleading, especially with disagreeing implementations. If you want a small enumeration, why not just use {"html", "xml"} and nothing else, since that's what really matters for the algorithm at this point? but it's too late for that, so loosening the definition would be the next best thing.
I don't see a particularly compelling argument to change the spec and implementations here.
WebKit also follows the spec: http://svn.webkit.org/repository/webkit/trunk/Source/WebCore/xml/DOMParser.cpp I'm not sure what the original poster is referring to.
The latest version of Safari on OS 10.8, for example, has different behavior from WebKit nightlies here.