Consider removing XML compatibility from SSR or hiding it behind an option

[gaearon]

See #11708 (comment).
Not sure if it's important but seems suboptimal to send extra markup if most people don't need XML.

[syranide]

Perhaps there's far too much overlap, but the logical solution otherwise should be to separate ReadDOM into ReactHTMLDOM and ReactXHTMLDOM/ReactXMLDOM right? Considering XHTML is considered dead at this point IIRC, perhaps it wouldn't be so bad as it's unlikely that someone would ever try to use both at the same time, so the overlap is irrelevant as long as it's shared.

[gaearon]

This only concerns the SSR implementation, doesn’t it? In that case passing an option seems easier than creating another one from scratch. I don’t think we’d want a separate top level namespace since the use case is so uncommon.

[antonbasic]

Probably still not very common to need XHTML with React but would just like to make a case for keeping it. The European Securities and Markets Authority requires issuers on EU regulated markets to send financial reports in XHTML. I'm working on projects that use react to support this and would be nice to be able to do that.