[sanxiyn]

MathJax is a unified way to render mathematical formulas in browsers. So that only leaves "native".

Why is it desirable to have "native" implementation? The usual answer is performance, but I am not aware of much performance complaint of MathJax. If not performance, how does it make sense to add more C++ code to browsers to be exploited, when memory safe JavaScript implementation is already available?

[aplaice]

In addition to the already mentioned performance issue with client-side MathJax, having native MathML makes it conceptually far simpler to do more complex things with equations, both for the end user and for the developer.

For instance, as a user, if you want to scale the equations by some amount or use a different maths font, it's a couple of lines of CSS, using exactly the same method you'd use to make any other changes to the appearance of a web-page. (Yes, you can easily do the former with MathJax, but I don't think the latter is possible user-side).

As a developer, if you'd want to interactively highlight parts of an equation, for educational purposes, it'd be trivial with MathML, but rather hard to do nicely with MathJax (statically coloured elements are possible with MathJax, with the "color.js" extension, but not dynamically coloured ones — and no, swapping out the entire equation to make colour changes is neither nice nor scalable). Alternatively, if you want to embed equations in a diagram or a graph, it's pretty easy with MathML[0][1], but would be difficult otherwise.

Obviously, all of the above is in principle possible with JavaScript implementations, but it's far harder. You might argue that this extra effort is worth the smaller attack surface. IMO, given the importance of maths and science, it isn't.

Also, why do we, say, have the CSS flexbox layout? After all, we could have used javascript to arrange elements into an appropriate table or even just set the x and y positions of all elements...

[0] http://fred-wang.github.io/MathUI2014/demos/2-mathml-in-svg....

[1] http://fred-wang.github.io/MathUI2014/demos/6-mathml-in-webg...

[sanxiyn]

Yes, I am also against "native" flexbox implementation. Yoga showed it's entirely possible to implement in "user level".

[felixfbecker]

This. There is so much gained from equations being represented as HTML elements, with full support for CSS styling and JS manipulation.

[detaro]

People regularly recommend other solutions over MathJax due to performance, and at least on complex pages there's a noticeable delay for it finish processing everything on the page. Is it worth it to do a native implementation because of that? maybe not, but there are issues with it.

[sanxiyn]

I'd much prefer optimizing MathJax over writing new C++ code in Chromium.

[xg15]

Even the most optimized JavaScript code will be less performant than a fully declarative language that can be directly interpreted by the layout engine.

From a user standpoint, it's ridiculous that I need to have JavaScript enabled, so the browser can download and compile a separate runtime, that itself reparses the page, just so I can look at a static documents with some math symbols.

Lastly, I think a common standard for math representation is valuable for the same reasons "official" <section> and <article> elements are valuable: They offer a common data model that tools, extensions and search engines can work on to provide extra functionality. A "de-facto standard" like MathJax doesn't provide this, because there is no requirement that two different sites use the same representation. The only requirement is that they put up something which the particular version of MathJax they embedded can understand. This makes things a lot harder for tools.

[est31]

Pages with lots of MathJax formulas take a lot of time to load.