Hacker News Reader

Comment by runarberg | Hacker News Reader

This is just wrong. MathML is not about notation, it is about rendering. Notation is secondary (as is evidence by the number of translators out there). Having native rendering yields numerous benefits including:

* Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.

* Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).

* More options. Maybe LaTeX is not the right choice of syntax (more people write math then professional mathematicians and PhD students). As translating to LaTeX is hard, translating to MathML is easier (I know, I’ve written one my self).

View on HN

Maybe something similar to Troff eqn language? Or the formula language in Libreoffice Math? Both of these are a bit more approachable than LaTeX's math mode, IMO.

I think the LO Math formula language is nearly an exact implementation of eqn. I prefer eqn to LaTeX because it is easier to remember/write/read, but complex equations tend to take some fiddling to avoid ambiguities.

The point is that MathML is easier to translate to then many of these other languages. I wrote a language my self a few years ago that translates to MathML (https://runarberg.github.io/mathup/) and MathML was an absolute joy to target.

In mathup I included a second target to update the DOM directly .toDOM() and .updateDOM(oldMathNode) instead of .toString(). This would have been quite difficult if there wasn’t a nice mapping between the language and the DOM nodes. By implementing math in MathML browsers have made it easier for us software authors to write these other languages that serve different purpose then LaTeX. Our users benefit from this proliferation. Ultimately they don’t need to know which language is the native one, because all they write is:

    <math-up>ln x = int_1^x 1/t  dt</math-up>

And let the library translate to MathML for them.

I think UnicodeMath [1] is really interesting and approachable and is a standard that Unicode themselves have been keeping an eye on/helping maintain. It takes advantage of the richness of Unicode in interesting ways that makes the formula encodings in plain text better resemble their formatted counterparts. (You just have to forgive that the standard originated from the Microsoft Office team.) The interesting thing to me that UnicodeMath partly implies is the idea that math formatting could be considered similar to "regular font rendering" in a similar way to how ubiquitous emoji have become.

[1] https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1....

> * Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.

> * Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).

Those two wouldn’t be there _if_, as the OP suggested, browsers would have supported a TeX-like way to render math instead of MathML.

Yeah but TeX has problems on its own which makes it a poor choice as a native language. E.g. if you wanted to create an anchor inside your expression, or apply some DOM manipulations. Then there is the whole problem of TeX not having a clear specification, and being turing complete. Both issues make it a noop for browsers to implement as a markup language. Like if you wanted to dynamically change the color of the denominator in the expression 1/x. Which node would you target, and which attribute would you change, and to what, in your script if the expression markup looks like this:

    \frac{1}{x}

How about now:

    <mfrac>
      <mn>1</mn>
      <mi>x</mi>
    </mfrac>

MathML is a lot easier for library authors target and for web developers to work with, which makes it a superior choice as a native language to TeX.

Reply on news.ycombinator.com