(In reply to comment #11)

Peter, thanks for your input!

> 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)? 

In the Parsoid project we are developing a long-term HTML storage format for Wikipedia content. The VisualEditor uses our HTML, but also has the freedom to cut some corners for display in the shorter term. However, our long-term goal is to use Parsoid HTML also for regular page views. This is why we are now thinking about issues like copy&paste from read-only pages into a VisualEditor instance while refining the DOM spec at http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec.

Because of its rich metadata, Parsoid HTML is also useful for researchers and search engines. Ideally we'd also like to expose math in a way that works well for both content analysis / indexing *and* display.

> 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).

I'm also looking forward to learning more about LaTeXML vs. MathJax options. No browser supports Content MathML currently. The question then is if it is still useful to produce it for search while always rendering via Presentation MathML and/or server-generated SVG.

> 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).

That might be, although Martin suggests that Content is better for search in his paper.

> 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).

Copy&pasting entire formulas should be possible as long as our data-mw attribute on the outer wrapper node is preserved. That has the TeX source, which can be used to re-render the contents from scratch. This will enable copy&pasting of entire sections including formulas.

I also get the impression that copy&pasting parts of a formula directly might not be feasible. It works with Presentation MathML in FF, but that would not be useful as we don't have a way to convert that back to TeX. It might make more sense to let users copy the TeX and insert that in a new formula using a widget.

> * generating static speech strings is the lowest form of a11y, especially
> when
> you could use MathJax which math accessibility tools support.

Are there popular screen readers that handle math? I agree that MathML is probably better in the longer term, but for current screen readers a speech string could still be a useful fall-back. At least if that would not prevent a plugin like math player from using the MathML instead.

> * generating static images of any kind will remove all the advantages of
> reflowable and accessible content.

I think nobody is suggesting to generate *only* SVG. I'm not sure about the need for reflow in Wikipedia, as the limits of texvc seem to have motivated authors to handle this manually in TeX.