Arg -- I had responded twice, twice it was lost... Trying again.

===

On Sept 4 (after the IRC chat log) I tried to post:

Obviously, I'd love to see MathML + MathJax on Wikipedia. That would be a huge step forward for math on the web, accessibility, and education. 

But on the wikitech-I thread I started a while ago, there was a bit of uneasiness when it comes to MathJax performance, especially on mobile. I got the feeling that fallback images will be required for a while. Perhaps SVG might be better though and MathJax could help there, too. 

MathJax is modular on input, internal and output which is sometimes confusing in discussions; so yes we have an HTML/CSS output and an SVG output. At the same time, the texlive+texvc backend is a bit horrible. Personally, I think LateXML is a great tool for converting full LaTeX documents but I worry that you'll need another texvc to limit it -- it's too powerful. MathJax might just fit better because of its restricted syntax (and is extensible through javascript). Obviously, I'm terribly biased. For the record, LaTeXML is miles better than texvc. I'm meeting Martin Schubotz (the author of the arXiv link) over the next few days, so I hope to learn more about his projects (and he's coming up to WMF after that I hear so that's awesome).

Copy&paste is tricky. Yes, it works in FF, but often OS clipboards do not know how to handle it, apps sanitize it away etc. MathJax offers a context menu to access TeX & MathML source (and in our upcoming release any annotation-xml); cumbersome but it works everywhere. We are considering web components / shadow dom, but given the state of support that's for the future (current implementations have some funky copy&paste behavior).

I did get the strong impression on wikitech-I that wiktext should keep TeX as its internal format, so I'm wondering what you have in mind for pasting MathML. MathML isn't semantically rich enough to produce human readable TeX.

Regarding Content MathML, that's a topic of debate. I'm not an expert on Content MathML but I've heard relatively negative things about it from a semantic point of view. A case in point is that accessibility tools don't do better on Content MathML than on Presentation MathML -- they build their own semantic structures on top of it anyway. In any case, you don't see a lot ContentMathML in the wild since no one can render it.

From a search point of view there doesn't seem to be much difference (but of course a specific search technology might prefer Content, Presentation, or TeX).

It's more important to produce high quality Presentation MathML instead of low quality Content MathML. MathML today is a bit like HTML 1 -- we have the language, some basic rendering, that's it. MathML has missed out on 20 years of web development (although it's the de-facto standard in publishing and technical writing workflows). MathML on Wikipedia would be important to push things forward but small steps in what's currently possible would be better.


====

Yesterday I tried to post:

cc'ing Fred and Moritz who have been actively working on the math extension recently.

@Gabriel I'm a bit confused by your last two messages. [[well, less so after seeing that mine didn't get through]] 

Are you just collecting thoughts on this? Are you thinking about long term or short term? Is the topic now the back end or is it still the front end (as the issue title suggests)? 

Anyway, here a few more thoughts, trying to provide some outside input.

* Content MathML won't help on the front end -- you need Presentation MathML on the front end and use polyfills where necessary. MathJax works on all current browsers and while older machines and older Android devices may still see performance issues, those will continue to improve. Replacing images (PNG or SVG) on the fly is a progressive enhancement on all systems.
* the prototype that Gerardo mentioned combines MathJax and ChromeVox, so you'll run into the same problem for MathML support.
* generating static speech strings is the lowest form of a11y, especially when you could use MathJax which math accessibility tools support.
* generating static images of any kind will remove all the advantages of reflowable and accessible content.
* the math extension does not yet use LaTeXML but Fred and Martin are working on that.

I can't help but point out that there are also a number of serious issues with WIkipedia's math that are more important than ContentMathML. For example, there's no display math mode which is an incredible shortcoming. There's also poor unicode support and poor RTL support. None of this will improve by switching to Content MathML -- garbage in, garbage out would be the result.