Math on GitHub: The Good, the Bad and the Ugly

True, it's more verbose, but I'd take increased verbosity and standardization over increased ambiguity and inconsistency since every markdown parser and renderer translates things a little differently, which is why there's things like Babelmark[0]. That verbosity also provides consistent, more powerful features like multi-line table cells, table cell spanning, table nesting, sidebars, admonitions, footnotes, table of contents, image embedding, cross-doc references, latex-like includes, etc. that all follow a similar inline and block syntax and are rather clear from a glance.

It's certainly not perfect, but I much prefer it for the flexibility and consistency to the dozens of markdown implementations that all do things a little different and not needing to drop down into HTML when I need to do something just outside of markdown's capabilities.

0: https://babelmark.github.io/

This article should not be taken seriously, which has at least 2 fatal errors in its argument.

First about the choice of delimiter. It argues for the use of \(…\) and \[…\] instead of $…$ and $$…$$. They don’t even explain why, but cite an external link to, guess what, a reason why the former is better for LaTeX, not markdown.

Then they made a claim about why putting math inside code delimiters are better.

Detouring a little bit, my guess that GitHub chooses this delimiter is because they have prior collaboration with the author of pandoc to create the common mark spec. Their GFM parser is an extension of a common mark parser.

And since pandoc chooses the dollar sign delimiter as the math delimiter, it is natural for them to choose it too, just to have lesser variants.

Then why pandoc choose $ instead of \(…\) and \[…\]? And would that goes against the best practice of LaTeX?

The answer to the latter question is no, because the $ is the markdown delimiter, and when transpiled to LaTeX, it becomes the \(…\) and \[…\].

Answer to the first question is related to the fact that at least in pandoc, \[ means escaping the [. So to type \[ in markdown, it should be \\[, which is cumbersome. (There’s a special flag in pandoc that you can use bare \(…\) and \[…\] though.)

And since all this parsing is happening at the parser level, the code-delimiter argument is invalid. They are thinking more in terms of hacking an existing parser and render math as a post-processing step.

The second fatal error is comparing MathJax to KaTeX by showing the commit freq. and claim that MathJax is dead.

This is a really amateurish argument seen occasionally elsewhere in the open source community that if a software has no recent commit history it is dead.

In this particular instance, KaTeX is far behind MathJax in terms of coverage of rendering valid LaTeX math. This alone means they have a lot of catch up to do and no wonder a less mature software has more commit activity than a more mature one.

MathJax is backed by a lot of organizations/universities and they have commitment to maintain it. It is far from being dead.

KaTeX aims at being fast (MathJax 3 reclaim that territory a bit but AFAIK KaTeX is still king in that aspect.) If the math you use can be rendered by KaTeX, then use it. But it happened to me that I have to change a config to use MathJax instead of KaTeX because soon or later I’m going to use something KaTeX doesn’t support.

As GitHub doesn’t give you choice, choosing a default that has better coverage is no brainer.

Blog post author here. The kerning is probably a problem with their font config that can hopefully be fixed. I don't think -- and that's me personal estimation -- that people will write tons of `a\,=\,b` to work around the bad kerning, so that's a change I would still recommend making.

Author here.

Thanks for the hint! I had indeed overlooked that. I have updated the article accordingly.