
MathML in Chromium - aplaice
https://mathml.igalia.com/news/2019/02/12/launch-of-the-project/
======
fdej
I really wish browsers would just render formulas directly from TeX. Let me
write <tex>\sqrt{1+x}</tex> or whatever. TeX is the de facto standard for
writing mathematical formulas. That browsers don't render it natively just
screams of NIH syndrome on the part of browser and web standards developers.

MathML still hasn't caught on after two decades, for three reasons: 1) not
working in all browsers; 2) even when it worked, the rendering was often buggy
or plain ugly; 3) no one wants to write MathML directly.

MathJax instantly solved all problems, which made it an overnight success.
MathML might be able to overcome 1) and 2), but 3) should not be
underestimated. MathJax will be around as long as it is the most convenient
solution for showing equations in a browser (no user-side compilation
required), and rendering times and network traffic will suffer accordingly.

~~~
felixfbecker
I'm sorry but Latex is an inconsistent touring-complete mess. Latex commands
are far from intuitive, otherwise Detexify wouldn't be so popular. It's a
million macros held together with duct type with no consistency in naming and
syntax, and always dependent on which age-old package you're referencing. It's
good at outputting pixel-perfect printable, non-accessible PDFs, and that's
it.

I'm excited by this because I hope that with a proper widely-supported system
for math in HTML we can eventually write more papers to be digital-first. An
HTML document is so much more accessible, searchable, semantically analysable
and flexible than Latex and its PDF output. I dream of a world where the
standard for papers is not Latex .pdf but .mhtml or .maff.

~~~
svat
It is true that the LaTeX ecosystem as a whole is a mess of packages and
macros. But most of its mathematical typesetting comes from the underlying TeX
(and a set of macros maintained by the AMS), and it's fairly small and
consistent. The Detexify you mention is only for looking up specific symbols
provided by various fonts (packages), and has nothing to do with mathematical
typesetting or LaTeX macros in general: TeX/LaTeX engines support Opentype
fonts now and if you want to use one of them, you can just type ∞ instead of
\infty or ℝ instead of \mathbb{R} (actually you can do this regardless with
unicode-math), bypassing the need for looking up symbols-a4 or Detexify.

Encoding the aesthetics of good mathematical typesetting is not trivial, and
Knuth and others have spent decades on it based on studying and absorbing all
the tricks that hot-metal typesetters had come up with over centuries. It
would be foolish to throw away all that hard-won knowledge and implement half-
baked solutions from scratch: those working in the field understand this
(though the original MathML proponents perhaps did not), which is why the
linked post mentions “math rendering based on TeXbook’s appendix G”.

More generally, in this conversation (and in any discussion about MathML),
several things get conflated:

1\. What syntax the user types to get their mathematics. I think it's beyond
dispute here that no one wants to type MathML by hand (and even the MathML
advocates do not propose it AFAIK). Also, so many people are familiar with
TeX/LaTeX syntax that it must be supported by any complete solution, though
alternatives like AsciiMath or some interactive input are still worth
exploring.

2\. How the mathematics is actually encoded in the HTML file, or delivered to
the browser. Frankly I don't think this one matters much because it's
invisible to the user; any of raw TeX syntax, or MathML syntax, or fully-
positioned HTML+CSS, or SVG, will probably do.

3\. Who does the rendering and typesetting / layout. The promise/dream of
MathML is that a standard will be specified and all browsers will implement
it; though this is yet to become reality. Meanwhile, typesetting can already
be done server-side (someone runs TeX/MathJax/KaTeX/etc before sending it to
the browser) or client-side (MathJax/KaTeX running in the user's browser)
instead of being done in the browser's native code.

4\. The quality of the typesetting/the algorithms used. I already mentioned
this in the second paragraph above so I won't reiterate it, but this has been
mostly underestimated/ignored by those advocating MathML. The decisions made
by TeX reflected the best journals of the early 20th century and have in turn
become the shared aesthetics of the mathematical community; “so-so”
typesetting will not do.

5\. What the result/output of all this rendering/typesetting/layout will be,
in the web page's DOM. This affects things like usability (being able to copy-
paste), scaling/zooming, styling individual parts of formulas, etc. Again,
already (La)TeX+dvisvgm supports SVG for this, and MathJax supports HTML+CSS,
MathML or whatever. Anything other than raster (PNG etc) images is probably
fine here.

The main new/useful thing I can see with MathML is with (3); the browser doing
the typesetting. But that's hard, and it has a lot of other challenges to
overcome too. And as MathJax/KaTeX/dvisvgm demonstrate, the facilities
provided by the browser for layout (HTML+CSS for example) are already
sufficient for print-quality typesetting.

~~~
aplaice
This is an interesting, thought-provoking comment!

> (though the original MathML proponents perhaps did not)

FWIW I'm pretty sure that they did. Arguments to authority are pretty
terrible, but if you look at the authors of the MathML 1.0 (earliest) or 3.0
(latest) specs[0][1], and google them, you can see that many of them have
backgrounds in science or math and have been active in the LaTeX ecosystem.

> but this [quality of the typesetting] has been mostly underestimated/ignored
> by those advocating MathML.

I don't see any evidence for this, not among its designers, implementers or
even general proponents.

Firefox's output (implemented almost(?) entirely by individual volunteers),
for instance, is acknowledged to be still considerably worse than LaTeX output
in a pdf, though it is competitive with its web alternatives (superior in some
respects, worse in others) — do be sure to install MathML fonts[2] though.

> 5\. What the result [...] will be, in the web page's DOM.

Have you seen the tag soup generated (by necessity) with MathJax or KaTeX?

[0] [https://www.w3.org/TR/REC-MathML//TR/REC-
MathML/](https://www.w3.org/TR/REC-MathML//TR/REC-MathML/)

[1] [https://www.w3.org/TR/MathML3/](https://www.w3.org/TR/MathML3/)

[2] [https://developer.mozilla.org/en-
US/docs/Mozilla/MathML_Proj...](https://developer.mozilla.org/en-
US/docs/Mozilla/MathML_Project/Fonts)

~~~
svat
I guess when I say “MathML proponents” I ought to be more careful in my
thinking to make a distinction (even if they are often the same people)
between those working on MathML as a project, and those advocating for its
actual use today under current conditions. I have no problems with the former;
I wish them good luck and look forward to trying the result when it's ready.
For the latter, I can only say that anyone advocating using MathML today
despite its problems (poor layout and browser support) clearly cares about
something else more than they do about actually communicating mathematics to
humans.

No doubt among the authors of the MathML specs there are people who care about
typesetting. Though I'll note that being active in the LaTeX ecosystem is not
a guarantee of this: the prime example is the author of LaTeX (Leslie Lamport)
himself, who makes a pitch for the LaTeX model around (mostly) not caring
about the appearance: [https://lamport.azurewebsites.net/pubs/document-
production.p...](https://lamport.azurewebsites.net/pubs/document-
production.pdf) — in contrast with Knuth who devotes the largest (despite
smaller font size) chapter of _The TeXbook_ to _Fine Points of Mathematics
Typing_. (A blog post by one of the authors of the MathML spec you linked to:
[https://blogs.msdn.microsoft.com/murrays/2011/04/30/two-
math...](https://blogs.msdn.microsoft.com/murrays/2011/04/30/two-math-
typography-niceties/)) In fact some of the worst mathematical typesetting I've
seen is by people who wrote in LaTeX and blindly trusted it to produce the
best typesetting, and sometimes even ignored the warnings about
overfull/underfull lines.

Looking at the MathML sample page in Firefox
([https://mdn.mozillademos.org/en-
US/docs/Mozilla/MathML_Proje...](https://mdn.mozillademos.org/en-
US/docs/Mozilla/MathML_Project/MathML_Torture_Test$samples/MathML_Torture_Test?revision=1449367)),
there are many that are worse and none that is better that TeX's output (which
for some reason is given on the page in low-resolution images rather than
high-dpi images or SVG) — and in any case if you feel that some are
subjectively better, it's still the case that the aesthetic most everyone
wants is “like TeX”. And personally I've seen very little by Firefox/MathML
people on their layout decisions (if they decided to do things differently
from TeX, why?), while with MathJax I've seen that if their output is found
not to match TeX's it is treated as a bug report and a fix attempted. What are
the some respects in which you say Firefox's output is visually superior to
MathJax's? Is there a page demonstrating them?

> Have you seen the tag soup generated (by necessity) with MathJax or KaTeX?

Yes, and it's not pretty. But (1) among the list of things to care about this
is the lowest of the low, as it does not affect what is visible to the user,
and (2) the tag soup of MathML, though shorter, has still all the XML ugliness
so it's not as if it will ever be readable. (In fact looking at the comparison
of different input formats
[https://en.wikipedia.org/w/index.php?title=MathML&oldid=8864...](https://en.wikipedia.org/w/index.php?title=MathML&oldid=886463711#Example_and_comparison_to_other_formats)
for sufficiently complex equations even the TeX/AsciiMath inputs become
unreadable; the well-typeset visual representation may be the only somewhat
readable one.)

~~~
aplaice
> For the latter, I can only say that anyone advocating using MathML today
> despite its problems (poor layout and browser support) clearly cares about
> something else more than they do about actually communicating mathematics to
> humans.

Much of the reason people are in favour of providing MathML output is that if
nobody did, then the likelihood of Chrome getting MathML support would have
been near zero (and the risk of Firefox removing its existing (if imperfect)
implementation, high). (A chicken and egg problem.) Since MathML is likely
(you may disagree — but you must agree that it's plausible that if a
JavaScript solution can do it, a native one can probably do it better) to lead
to better equation typesetting on the web, once it's properly implemented,
people advocating MathML today can very much care about better communicating
maths to humans, in the long run. Also, MathML is not incompatible with
MathJax — in fact, since MathJax's internal representation of equations is
similar to MathML's, converting from MathML (to SVG/HTML+CSS/whatever) is
faster than converting from TeX — so it's not as if providing MathML in the
document dooms your readers you to its "ugly" output. (And yes, MathML can be
both an input and an output for MathJax...)

> [...] (which for some reason is given on the page in low-resolution images
> rather than high-dpi images or SVG) [...]

That's because the page was made several years ago, when such images were the
norm (look at a Wikipedia page on the Archive from even 2016), and hasn't seen
significant updates since, because MathML was feared dead (due to Chrome, at
the time, explicitly rejecting support) and volunteer effort dried up.
Somebody™ should update this...

> Looking at the MathML sample page in Firefox [...], there are many that are
> worse and none that is better that TeX's output

For the little that it's worth, IMO five are worse, two are slightly better
and the rest just as good as the TeX.

> And personally I've seen very little by Firefox/MathML people on their
> layout decisions (if they decided to do things differently from TeX, why?),
> while with MathJax I've seen that if their output is found not to match
> TeX's it is treated as a bug report and a fix attempted.

Far more people work on MathJax than on MathML — MathJax has a two-member
team, plus support from AMS, plus volunteers, while MathML has only had
occasional volunteers (see above; not that it was much better previously), so
it's not a fair comparison. Also the page comparing TeX with MathML was made
by the people in favour of MathML precisely because they care about trying to
achieve parity with TeX.

> What are the some respects in which you say Firefox's output is visually
> superior to MathJax's?

For instance the speed with which the output is rendered. Several second
latency for better final appearance might be a bargain you want to take, but
it's still a visual trade-off. (You can use server-side MathJax, but then you
lose some end-user customisability.)

> the tag soup of MathML, though shorter, has still all the XML ugliness so
> it's not as if it will ever be readable.

How else would you expose the structure of an equation, to the DOM, than with
XML ugliness? It's just important that the XML ugliness makes sense (and
MathML's does).

------
est31
It's very good news that this has finally started. Wikipedia, probably the
biggest website that displays formulas, still renders them to SVG images.

Igalia had already been improving WebKit's [1] MathML renderer and they had a
fundraiser for the Chromium MathML work for a long time. Now they seem to
collected enough to start with it. It's one of the great advantages of open
source that a small company like Igalia can just go and improve multiple
rendering engines used by billions of people.

[1]: [https://webkit.org/blog/6803/improvements-in-mathml-
renderin...](https://webkit.org/blog/6803/improvements-in-mathml-rendering/)

~~~
gdy
"Wikipedia, probably the biggest website that displays formulas, still renders
them to SVG images."

Not exactly.

[https://en.m.wikipedia.org/wiki/Help:Displaying_a_formula#Na...](https://en.m.wikipedia.org/wiki/Help:Displaying_a_formula#Native_MathML)

~~~
est31
Even users on Firefox only get to see the SVG images per default.

------
notthingnill
You can also use a computer algebra system (CAS) to perform computations and
get the output in mathml, for example the free CAS maxima.

wxMaxima is something like jupyter notebook but developed with wxWindows by a
solo developer. ?? is help for command

I just copy pasted:

(%i2) ?? mathml; \-- Function: mathml_display (<form>) Produces MathML output.
(%i1) load("alt-display.mac")$ (%i2) set_alt_display(2,mathml_display); <math
xmlns="[http://www.w3.org/1998/Math/MathML">](http://www.w3.org/1998/Math/MathML">)
<mi>mlabel</mi> <mfenced separators=""><msub><mi>%o</mi> <mn>2</mn></msub>
<mo>,</mo><mi>done</mi> </mfenced> </math> (%o2) true

------
dtf
Here's an example of why MathML is attractive as a rendering layer (try
Firefox vs Chrome, and look at native MathML latency vs MathJax emulation):

[https://runarberg.github.io/ascii2mathml/](https://runarberg.github.io/ascii2mathml/)

(it helps to have the LaTeX Computer Modern fonts installed locally, which for
some reason aren't imported on this page)

~~~
runarberg
hmm, here is a project I haven’t given nearly as much love as it deserves.

ascii2mathml was the first compiler I ever wrote (and have written since). I
wrote it because I wanted authors from a non math background to be able to
write short expressions in forums or comment threads without having to know
latex. I tried to make it as intuitive as possible. Even going as far as
making `1+2 / 3+4` a different expression from `1 + 2/3 + 4`. But I know some
people started integrate the library in their notebook apps, mainly used by
math students taking notes in lectures in a markdown format (writing the
expressions in ascii2mathml). Ascii2mathml might be a better fit then then the
original asciimath for that purpose as the original is no expressive enough to
capture advanced math expressions.

I bailed on it a couple of years ago because it looked like MathML was a
dying. Chrome wasn’t going to implement it. Also I haven’t been using it for
anything either. Perhaps it is now time I revisit it and give it some love.

------
bjoli
Not in any way affiliated, but Igalia is a cool company. They pay their
employees to work on OSS projects as a part of their job. Andy Wingo
work(ed?)there and they financed quite a bit of guile development as a way to
make him develop his compiler and runtime skills.

------
sanxiyn
My personal opinion is that MathML should die. MathJax is here today and
works.

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

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

~~~
sathomasga
> garbage layout largely unsuitable

I dunno. Looking at the math rendering torture test at
[https://mdn.mozillademos.org/en-
US/docs/Mozilla/MathML_Proje...](https://mdn.mozillademos.org/en-
US/docs/Mozilla/MathML_Project/MathML_Torture_Test$samples/MathML_Torture_Test?revision=1449367)

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

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

------
mymythisisthis
I hope MathML gets more support. It is a bit unwieldy, but it seems like a
simple solution to displaying maths on a simple HTML page, here is my example.

[http://gron.ca/algebra/023.html](http://gron.ca/algebra/023.html)

------
75dvtwin
this is great news.

Does anybody know if this will translate to chromium based web toolkits (eg
QT), and MS Edge (soon to be based on chromium), and therefore, React-XP [1] ?

[1][https://github.com/Microsoft/reactxp](https://github.com/Microsoft/reactxp)

