I don't know if I'm reading [1] correctly but it appears that Google is finally working on implementing MathML in Chromium. There have been multiple commits and updates to this bug in 2020, especially in September.

Edit: It's not being implemented by Google. It's a sponsored effort because Google couldn't be bothered. [2]

1: https://bugs.chromium.org/p/chromium/issues/detail?id=6606

2: https://mathml.igalia.com

Igalia seems like such a great company. They are doing lots of important and exciting things in open source. Sure, they get paid for it and all that, but it seems like such a cool idea. I am glad it seems to work for them

The bad accessibility of math notation and math content is one of the main reasons there are very few visually impaired people in STEM, one of the main reasons why I'm doing code and not physics, and why Firefox is given as the accessibility default in web.

Actually often I wish that AI papers contained code instead of math so that it's clearer how it can be implemented, and how the variables are used. It would make the papers a bit longer, but implementations easier to understand.

> Actually often I wish that AI papers contained code instead of math so that it's clearer how it can be implemented

That's insanity. Sure, code is a nice addition, but it does not convey the same information as the math does.

It's akin to asking to replace an engineer's design of a bridge with a scale model.

I think this is more akin to construction workers asking for blueprints rather than cad models.

As someone who hasn't actively done formal math in a couple of decades the slog of relearning syntax to read papers about code can be off putting. I understand that this makes me a barbarian. However code is really the lingua franca we use as an industry but in papers it is treated exactly as you say a nice addition.

> I think this is more akin to construction workers asking for blueprints rather than cad models.

No, because those aim to express the same thing, albeit with different limitations and practical considerations. Code and math are entirely separate things.

> As someone who hasn't actively done formal math in a couple of decades the slog of relearning syntax to read papers about code can be off putting.

Surely the syntax is an incredibly minor part of it all?

> However code is really the lingua franca we use as an industry but in papers it is treated exactly as you say a nice addition.

Code is an implementation detail. Papers express ideas, not implementations.

Not quite the same field, but see https://news.ycombinator.com/item?id=24649992 for an article about PLT (programming language theory) notation.

Working daily with a blind scientist, I am translating the equations from old papers without good OCR in Fortran to discuss them. I haven't found a better way, but we would definitely appreciate more accessible content.

You're translating into fortran? Why?

Because Fortran is FORmula TRANslator and it is very easy to express complex equations with it. It the lingua franca of scientific computing.

TIL. I'm curious what Fortran buys you over, say, Julia.

We simply master Fortran because of all the number crunching we are doing, nothing more.

because it is powerful, fast, simple, object oriented, while being natively parallel, on both shared and distributed architecture.

Would mathematical[0] satisfy at least the first two requirement? I just found about it from the MathJax post today.

[0] https://github.com/gjtorikian/mathematical

FYI, LaTeX notation is used by many blind people to express math ideas even if they don't actually use LaTeX for typesetting. (I personally know two programmers, one math teacher and one scientist who are using it with a braille display on daily basis.) So it's not totally anti-accessibility.

KaTeX can be generated server-side (no JS on client-side). Its output is browser-independent. It contains MathML in its output and the remaining of the output is correctly tagged to be ignored by readers:

    <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>g</mi><mi>a</mi></msup><mspace></mspace><mspace width="0.6666666666666666em"></mspace><mrow><mi mathvariant="normal">m</mi><mi mathvariant="normal">o</mi><mi mathvariant="normal">d</mi></mrow><mtext> </mtext><mtext> </mtext><mi>p</mi><mo>=</mo><mi>A</mi></mrow><annotation encoding="application/x-tex">g^a\mod p=A</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.858832em;vertical-align:-0.19444em;"></span><span class="mord"><span class="mord mathnormal" style="margin-right:0.03588em;">g</span><span class="msupsub"><span class="vlist-t"><span class="vlist-r"><span class="vlist" style="height:0.664392em;"><span style="top:-3.063em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathnormal mtight">a</span></span></span></span></span></span></span></span><span class="mspace allowbreak"></span><span class="mspace" style="margin-right:0.6666666666666666em;"></span></span><span class="base"><span class="strut" style="height:0.8888799999999999em;vertical-align:-0.19444em;"></span><span class="mord"><span class="mord"><span class="mord mathrm">m</span><span class="mord mathrm">o</span><span class="mord mathrm">d</span></span></span><span class="mspace" style="margin-right:0.16666666666666666em;"></span><span class="mspace" style="margin-right:0.16666666666666666em;"></span><span class="mord mathnormal">p</span><span class="mspace" style="margin-right:0.2777777777777778em;"></span><span class="mrel">=</span><span class="mspace" style="margin-right:0.2777777777777778em;"></span></span><span class="base"><span class="strut" style="height:0.68333em;vertical-align:0em;"></span><span class="mord mathnormal">A</span></span></span></span>

This is:

    g^k\equiv a\pmod{p}

In my own experiments with mathematical writing, rendering KaTeX server-side increased the resulting HTML size by a nontrivial amount. I bet that if you took something small-textbook-sized, in terms of bytes it would be smaller to ship katex.js and get it to render the latex on the fly, rather than generating the HTML ahead of time.

Bit of a sad situation, but then again HTML and CSS is not really the best layout language for this kind of stuff.

JS on server-side can be taxing. If I don't use NodeJS, then I'd have to (1) call it from a script, eating the startup time (2) run a daemon of NodeJS workers running in parallel to my web server or (3) use an "embedded" JS engine, hoping I don't run into compatibility issues. All three options have performance costs + adds more dependencies.

If KaTeX were written in C, for example, it would be no problem FFI'ing it into just about any language. Plus whatever perf benefits there are of not using JS.

He wrote "can be generated". You can use KaTeX for setting up complete static web pages with no JS/server-side prozessing at all. Example from my blog:

https://depot.traits.de/pages/2020/02/21-markdown-example.ht...

For the vast majority of use cases, you should probably be pre-generating these anyways, and for the few use cases where content would be constantly changing, client-side rendering makes way more sense.

The thing specifically with KaTeX is that if you do this, you can blow page sizes out completely. In the example above, less than 20 characters of latex turned into a giant amount of HTML markup. Repeat this in many places for a mathematics-heavy page, and the browser might be better off just running KaTeX itself. Besides, you need to ship a whole bunch of fonts and a stylesheet anyway.

KaTeX has an 'output' option and one of his settings is 'mathml'. You can produce clean MathML this way and even mixed HTML/MathML output (default and what you see in the OP's example) with MathML for accessibility. Problem with the pure approach isn't KaTeX but the browser support.

Oh yeah, definitely, I was just responding to the "calling server-side JS" part. Even if the same library was implemented in native code, you still wouldn't want to be calling it inline from a cgi* script.

I think this might be what you're looking for: https://github.com/cqql/pelican-katex