MathML has more capabilities than the ad hoc notation of LateX simply in virtue of being XML-based. Whether these capabilities are ever realized is another question, but LaTeX had a pretty big head start and better tools.

This confuses me... TeX and LaTeX by extension are entire programming languages, in terms of _capability_ MathML is to LaTeX what JSON is to Javascript - just a representation of the final output, rather than the logic to produce it.

That said I think just having a universal "target" format for formulae will make things much better (much like JSON itself is an "advancement" in it's own right, because of the easy interoperability it unlocks).

Indeed. That’s the sense that I get as well. MathML is ultimately about rendering but not the language, but they had to pick a language, so they picked one that was easy to translate into, and had a nice mapping to the DOM structure.

User as in reader? That's definitely not true. It becomes integrated into the document (vs a rasterized image), can copy/paste, etc.

User as in author? That's true, but latex -> mathml conversion already exists and is decent, and will get increased attention now that the major browsers all support it to a baseline level.

FWIW a rasterized image isn't LaTeX any more than a rasterized image is MathML. Both are markups and both can (and are able to) be rendered into the document in a way they are selectable, sharply resizable, and so on.

Characterizing LaTeX as a rasterized image is really putting up a straw man - MathJax and similar have existed for a long time.

As a reader of raw markup, LaTeX is much much more readable than MathML. As a human writing the stuff, MathML is basically unusable.

If you're using some gui/whatever then the backend format is just a tooling issue - why opt for the one that is obtuse for humans to interact with? It's very similar to the reason why we've evolved from HTML to markdown and the like - XML is terrible to interact with if you're not a computer. And even if you are a computer, there's a seeming preference for json, yml and the like over XML as it's human readable/modifiable.

There are path dependance issues here.

Sadly, TeX is (today) wedded way too much to the PDF format, which not only has tons of baggage, but also is not really appropriate for digital documents.

HTML is probably the best digital document format we have, and hopefully more people will try again to make it into a self-contained document format :

https://www.russellbeattie.com/notes/posts/the-decades-long-...

The TeXmacs editor - not to be confused with TeX or emacs, exports and imports to HTML, thanks to MathML :

https://www.texmacs.org/tmweb/help/faq.en.html#general-1

For instance :

http://www.texmacs.org/joris/naw/naw.html

(EDIT : oops, at least it used to use MathML, I guess they might have made it optional considering the lack of support by Chrome ?)

Also, LaTeX specifically has the issue that a LOT of its tooling has poor Unicode support, though Lua(La)TeX and Xe(La)Tex are trying to make that better.

I don't think MathML is designed for human creation, it's somewhat human readable but I believe the main goal was to remove the possibility of ambiguities.

It was designed explicitly to be written by other programs, to the point that they have an "error message" element for when your latex-like parse-and-output-mathml program failed, whose example in the spec is "Syntax error: \frac{1}": https://www.w3.org/TR/mathml-core/#error-message-merror

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

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.

LaTeX is nice to write until it is not, like you need an equation block or tables or wants to generate an equation programatically. And it goes through a mysterious backend engine that renders something that is correct 90% of the time.

I was with you, especially with the "mysterious backend engine", until the 90% thing. Do you have examples where LaTeX's rendering is incorrect?

Bad choices of my words, LaTeX always render correct but I can't be sure my input is going to give me what I actually want

okay, fully with you now :-)