An interesting take, thanks for the input! As a layman (pretty much), I had always a bit frowned upon reST since I never got used to syntax. That was probably because Markdown was already so popular when I started using it.
One little remark: You can still have highlighted math code blocks in gh's Markdown. The lang here is ```latex. Anyway, I see this might not be satisfactory.
The big advantage of using code blocks is that is guarantees that their sanitizer doesn't mess with the contents. This is a pretty big plus.
Also, you can of course still have mermaid code blocks; just don't put `mermaid` after the three backticks. The code block won't have any syntax highlighting, but in the case of `math`, this wouldn't make sense anyway.
Well, it _is_ (La)TeX syntax. With the exception that there, if you want a dollar sign, you have to type \$. But yeah, the syntax isn't made for Markdown.
In May, GitHub added native math support. Unfortunately, it left lots to be desired. Six weeks later, I'm taking another look. Have the major issues been fixed? (Spoiler: No.)
The main problems pointed out in the blog post are problems in _parsing_ the Markdown+TeX pages. The output could be MathML indeed, but this is an issue they could always fix later.
I've been a managing editor for scientific journals for a number of years, and I can tell that -- while $ is still popular -- (almost) nobody uses $$ anymore. So I wouldn't say this is "where people already are".
The difference between GitHub and pandoc with GitHub-flavored Markdown as input is that pandoc doesn't sanitize as aggressively as GitHub does. For example, pandoc doesn't remove the backslash-escapes before non-letters as in `\{`.
I don't mean to argue for \(...\) and \[...\] in Markdown; it was just a side note I had added to satisfy the LaTeX purists such as myself. :) I hope I've clarified this in the text now.
> And since all this parsing is happening at the parser level, the code-delimiter argument is invalid.
Well, you're right in that they have to modify their parser to protect the $-$$ blocks. The issue is that they don't do that yet, and the fact that they don't have that that ready at release date makes me think it's hard to do. A smart way around all these problems would be tp use codeblocks for math since you don't have to modify the parser for this at all. That's what GitLab does anyway.
Let's just hope they'll adapt the parser.
> The second fatal error is comparing MathJax to KaTeX by showing the commit freq. and claim that MathJax is dead.
Thanks also for this comment! Another user pointed it out to me as well, and I've adapted the text accordingly. Having worked extensively with both MathJax and KaTeX, I found KaTeX has many advantages still. Some of those stem from the fact that it's far younger and built upon younger design principles, leading to better modularity for example. Anyway, apart from load times this doesn't affect the user so ultimately it's GitHub's choice.
Thanks again for taking the time for such a thorough review.
You're right, the big dreams always turn out smaller in real life when they come true, right? I'm hoping that the popularity of GitHub will aid a shift of publication style though. :)
One problems is that the parser doesn't work harder yet, and it will be difficult even for GitHub to make it so.
The $-syntax is familiar to TeXies indeed, but if the cost is that math won't ever work properly, I'd rather have a markdowny syntax.
The main idea of using code blocks for math is to protect its content from being messed with. Markdown parsers do that by default, so that's how it's "natural". As you mention, the drawback is that you can't have a codeblock with syntax highlighting for a language called "math" (should there ever be one), but that seems like a small price to pay.
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.
> Did Github ever solicit feedback from the community for this feature? Was there ever a beta before they rolled it out?
There actually was a closed preview for this, but it wasn't long and the feedback I gave them (which is almost everything that's in the blog post) wasn't implemented.
> The visual font size problem seems particularly disastrous:
They made the decision to match the capital heights of the two fonts, not the x-heights. If they match the x-heights, the capitals in math mode will be too large.
Since the small letters are way to small, perhaps they'll increase math font size a little bit in the future to balance it out.