dginev
commented
5 years ago Let me preface with saying that the good news is we can change between these options with relative ease, and nothing has to remain set in stone for decades to come. There may be upcoming swings in MathML support (one way or another, be it Chrome adding support or the next HTML dropping it), so this discussion likely won't mark a final outcome as far as arXiv is concerned.
As another tech preliminary: There is a lot of advanced latex used in arxiv's equations (as one would expect), so I'm assuming the implicit basis for Ben's approaches is a run with latexml that spits out either the fully expanded TeX source or latexml's idea of a MathML tree (for which there is a performance penalty, but you only need to run it once server-side).
Next, you get the usual server-side vs client-side trade-offs, complicated by the politics of the MathML situation. We're bound to disagree on a "best practice" answer here, given all the turmoil.
Some thoughts:
-
There has been a long-standing regret for a shortage of Content MathML out in the wild, to bootstrap a development effort. And CMML was made with the original promise of aiding both accessibility and machine-readability for an open-ended set of applications. I've returned to working with @brucemiller on improving the latexml-generated Content MathML dialect this year, and we're making good headway with formalizing more of the DLMF equations. Most of these improvements also translate into better CMML for arXiv. More importantly, latexml has been run against the entirety of arxiv on an annual basis, with cross-referenced presentation and content MathML generated. We've always hoped to see those formula results published live "officially", at least as an experiment. Given the importance of arXiv, it may be a helpful push for the community -- I'm sure at least the "Math search engine" teams will be delighted.
-
On the "client-side" front, if you use Firefox today, you can preview an example arxiv article with MathML without having to ever run mathjax, and the rendering tends to be blazing fast. If you run any of the other major browsers, you'll need to wait for your polyfill of choice to render the page, certainly. If Chrome moves forward and re-adds a MathML rendering capacity, 2019 may be the year of fast client-side MathML.
- Back to 2018, I've seen various takes - in fact too wide a variety of takes - to use two parallel representations, one for rendering performance, the other for accessibility. I've even seen that trade-off made with using mathjax vs katex in different page contexts of the same site. It's somewhat easy to make the client-side experience glitchy, or make the accessible representation so custom that you're forced to write custom code for the arxiv pages. The "sane" solutions I've seen seem to fall into:
- Prepare multiple server-side versions of the article and serve the preferred one to each user (either by browser detection, or better - as a user preference for the site)
- KISS and sacrifice the less relevant dimension to some extent
- of the custom approaches, I don't really love any, but my least disliked is usually serving the performance-optimized page, and adding custom markup to each equation that links to a remotely hosted accessible version, much akin to a
srcattribute of animgtag. It's an annoying automated workflow, but keeps the common usage pattern (which is currently the vast majority of visits?) simple and efficient.
Since I have skin in the game, I would definitely prefer picking an approach that makes serving Content MathML easy, if not included by default. Will leave it at this for now.
bfirsh
For displaying math in the arXiv project we need to balance the needs of 3 users:
Two broad approaches, I think:
Rendering the math server-side using MathJax and putting MathJax's output in the HTML. This is the current approach on arxiv-vanity.com. Advantage is it is super fast, so best option for able users reading in a web browser. Disadvantage is that it is not good for screen readers without MathJax's accessibility extensions (I think) and is a proprietary format.
Putting MathML in the HTML, and rendering MathJax client-side (either directly from the MathML or with a TeX annotation). This is best for interoperability and accessibility (I think?). Downside is it is really slow.
I think there might be a third approach, which is a mix of the two. Perhaps we could include both the MathML and pre-rendered MathJax in the HTML, doing some cleverness client-side to display the correct thing depending on how the user is reading it. (e.g.
display: nonethe MathML so it is just for machines).@dginev, @kohlhase, @pkra - thoughts / opinions?
Background reading