Comment by aplaice | Hacker News Reader

Comment by aplaice | Hacker News Reader

It's lovely when a website actually uses MathML on browsers that mostly support it (i.e. Firefox and IE with mathplayer).

<rant>

For those not convinced why MathML is preferable to javascript-polyfills:

i) Browser rendering of MathML is much faster than MathJax and even slightly faster than client-side KaTeX.

ii) It supports a wider range of mathematical notation that KaTeX. (This point is partially dubious since MathJax is slightly better than current implementations of MathML, in this regard, though that is a limitation of the implementations, rather than the spec itself, and is a consequence of the fact that almost all of the work has been done by volunteers, not full-time staff, even in the case of Firefox/gecko.)

iii) There isn't an ugly mess of spans within spans in the DOM (mainly aesthetic preference).

iv) One can easily copy the given formula and paste it into another application which supports MathML, such as Mathematica or Thunderbird.

v) It can be easily embedded into svg and webgl, resulting in pretty diagrams or graphs. For example see http://fred-wang.github.io/MathUI2014/demos/2-mathml-in-svg.... or http://fred-wang.github.io/MathUI2014/demos/6-mathml-in-webg... .

vi) Javascript can easily interact with MathML, without worries about order of execution etc.

vii) It's a web standard :p

Obviously, it's great that MathJax and KaTeX exist, but it would be even better if they didn't _have to_.

</rant>

I'm confused, I thought MathML is a markup language, and MathJax is a rendering system.

Yes, you're right — I wasn't being sufficiently clear. MathJax is indeed a rendering system which takes an input format (TeX, AsciiMath, MathML and possibly others) and converts it into a chosen output format (HTML (with CSS) — effectively a hodge-podge of spans, SVG, or MathML — yes, MathML is both a possible input and output format).

Technologically, it makes sense to directly compare MathJax with native MathML rendering. For example, take a document containing MathML and compare how it renders in Chrome with MathJax enabled (where the MathML has to be converted into HTML, in order to be displayed) and in Firefox with MathJax disabled (so the MathML is directly rendered by the browser) — Firefox will be much faster.

From a social point of view, we can compare our world to one in which most browsers can competently render MathML. In the former, people creating webpages/writing comments on the web, containing maths, will, say, write some markdown with embedded LaTeX, and use a server-side processor which converts the markdown to HTML, leaves the LaTeX alone and includes the MathJax engine, so that the LaTeX can be rendered client-side. (Since they have to include MathJax anyway, they probably won't bother with the extra step of converting the LaTeX to MathML server-side. Hence, even browsers that could render MathML, will still need MathJax for the LaTeX.) In the latter world, the same person, writing the same document, would instead use a server-side processor converting both Markdown into HTML and LaTeX into MathML, and no longer needing to include MathJax. The complexity for the writer/publisher would be the same (or if you were using LateXML or TeX4ht, lower), but the experience of the reader would be much, much better.

So what you're saying is that browsers can directly understand and render raw MathML syntax?

Yes, if they're Firefox (to a large extent) or Safari (to a small-ish extent); not if they're Chrome or Edge, etc.

Reply on news.ycombinator.com