Mathml is not important for being a latex replacement, it's important for being a unified and native way to render mathematical formulas in browsers.

With mathml supported by Chrome, you could instead of the whole Mathjax renderer use only a lightweight "latex/asciimath to mathml" translater and let the browser do the rendering job.

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?

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

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

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

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.

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

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.

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

MathML is here today and works in Firefox. I use it on Wikipedia[0], which is the only major ("non-niche"[1]) website that provides it, and it's much nicer than the image-based equations (and much, much faster than MathJax would be).

[0] https://www.mediawiki.org/wiki/Extension:Math/advancedSettin...

[1] not that "niche" websites like nLab[2] should be disregarded, since the web was originally designed to help scientists...

[2] https://ncatlab.org/nlab/show/HomePage

arXiv.org uses MathJax. https://arxiv.org/help/mathjax

So, because we have a JS library, we should drop an effort to natively support first class math rendering in the browser?

That's why we can't have nice things.

It’s not first class. It’s cross-browser-inconsistent garbage layout largely unsuitable for anything but the simplest mathematical expressions, and a horrible markup syntax for authors.

If MathJax or KaTeX is too slow for some purpose, someone should try to compile a more streamlined TeX renderer to wasm.

> garbage layout largely unsuitable

I dunno. Looking at the math rendering torture test at https://mdn.mozillademos.org/en-US/docs/Mozilla/MathML_Proje...

I prefer the MathML version in 15 of the examples and the LaTex in 11. (No preference in the others.)

I think the MathML sizing, positioning, and spacing of glyphs is strictly worse in every example at your link, sometimes quite dramatically. In a few cases (like the deeply nested fraction) the LaTeX is also not great.

This would be a fairer comparison if they saved the LaTeX as SVG outlines, or as a higher resolution bitmap. As it is the LaTeX version looks fuzzy on my high DPI display.

First of all, it can be used as a target for any markup syntax if authors don't like it. The syntax is an irrelevant part of the feature (in fact MathJax already supports it).

Second, it is first class. "cross-browser-inconsistent" is not an argument that it's not first class, tons of things are inconsistent (JS features, CSS implementations, etc).

Third, you missed the whole idea that the proposal is about enhancing the rendering, and also has buy-in from Mozilla people.

>If MathJax or KaTeX is too slow for some purpose, someone should try to compile a more streamlined TeX renderer to wasm.

That's not even wrong. It's beyond right and wrong, into the realm of crazy.

It’s confusing to use the term “first class” when what you mean is “mediocre but built in”. The standard English definition of that term is “highest quality”. There are certainly many parts of CSS that I would not consider first class.

> The syntax is an irrelevant part of the feature

This viewpoint explains a lot about web technology. The syntax doesn’t matter. The visual output doesn’t matter. Practical adoption by users doesn’t matter. All that matters is ticking features down on a checklist somewhere.

>It’s confusing to use the term “first class” when what you mean is “mediocre but built in”

"First class" in computing terms means strictly "built in", "supported as a native object" -- it doesn't say anything about quality (as opposed to e.g. "first class" airplane seats).

>This viewpoint explains a lot about web technology. The syntax doesn’t matter. The visual output doesn’t matter. Practical adoption by users doesn’t matter. All that matters is ticking features down on a checklist somewhere.

Sounds like a generic lament.

What matters here is: (a) performance, which is and always will be better than some plain-js implementation. (b) being native (which means it will eventually be on all browsers, without asking the users to load anything extra, and will mean writers can just depend on it), (c) the visual output will be better (for one, it will be native vector fonts laid out, not a canvas drawing which is not infinitely zoomable or non-math aware SVG where it's just pretty pictures), (d) it will be able to interact with all other browser capabilities better than any pure-JS implementation.

The syntax is irrelevant, as it can be a target for any other syntax one prefers. In fact MathJax already delegates to MathML rendering where it can.

The article is about fixing all those issues.

Yes, because JS is superior to C++ in terms of security.

I am in favor of bundling MathJax's MathML implementation in browsers though.

>Yes, because JS is superior to C++ in terms of security.

Yeah, because moving 1/100th of web rendering (the math rendering part) to JS is going to make things more secure...

Is it? Keep in mind that the JavaScript is likely running on a C++ interpreter, and has mostly unfettered access to the page's content by design.

Yes it is. Bundled JS won't add new use-after-free, new C++ code will.

I've been coding C++ for 15 years and I've never seen a use-after-free in the wild. (I've seen lots of other bugs and security problems, but not use-after-free.)

Use-after-free is a C thing, not a C++ thing. Granted, C++ makes is super easy to code in C, but that's an organization problem that is already solved in any sane project.

Not to mention something that almost any static analyzer will catch on the first run...

Can you recommend a static analyzer to Chromium developers? They appear to have problems with basic C++ programming; such a pity that Google cannot afford to hire competent developers like otabdeveloper2.

https://bugs.chromium.org/p/chromium/issues/list?can=2&q=%22...

That's supposed to be a witty retort? Did you bother to read those bug reports you've linked to?

They are already tied to static analyzers, which is how they were found. What do you think the: "Sanitizer: address (ASAN)" or "Issue 938699: AutotestPrivateApiTest.AutotestPrivate getPrinterList failing on ASAN/LSAN" in the bug reports means?

I see, you are merely unfamiliar with terminology.

The word "static" refers to compile-time; a static analysis reports errors or warnings based only on the source code of the program.

Sanitizers are dynamic analysis based on instrumentation. https://github.com/google/sanitizers/wiki/AddressSanitizer

  The tool consists of a compiler instrumentation module
  (currently, an LLVM pass) and a run-time library which
  replaces the malloc function.

In order to detect bugs with sanitizers, you have to find a test input that actually moves program execution towards UB. This is best done with a fuzzing setup like clusterfuzz, and lots and lots of CPUs, which Google fortunately has no shortage of.

https://github.com/google/clusterfuzz

As Dijkstra said, Program testing can be used to show the presence of bugs, but never to show their absence.

Having first-class tex/postscript support in the browser would certainly be better than having to support the MathML monstrosity.

MathJax is too slow for more appy and interactive use cases. With firefox's native implementation I have seen nothing but "instant" rendering.

Using MathML notation directly isn't a bright idea and MathJax rendering kind of works, but having a formulae renderer directly in browsers/document viewers is much better. Using a javascript library or even remote http calls (!) to render static formulae on client side is extremely slow, wasteful and limiting way to render mathematical formulae.

Is MathML even made to be written by hand ? Or should we use another tool that translates our formulae into MathML ? The syntax is awful and redondant

Mathjax is slow and requires client side JavaScript.

You can render Mathjax offline for non-interactive purposes (ie most use-cases) using 'mathjax-node-page'. I recently implemented this for my website; now pages like https://www.gwern.net/Embryo-selection display math instantly (instead of requiring ~5s - it's a big page), and also no longer require the MathJax JS, just the fonts/CSS.

Or KaTex, which I believe is superior to MathJax.

MathJax requires JavaScript, though; MathML doesn't.