Microsoft Considered Harmful

[VERIFIED] Last updated by Joe Schaefer on Thu, 28 May 2026    source

 

Markdown’s Origins

The point of John Gruber’s Markdown syntax spec was that his “Markdown” was intended to be easy to work with; not just from an authoring standpoint, but from an implementer’s perspective as well. $\LaTeX$, MathML, and HTML5 are not that.

GitHub Flavored Markdown (GFM)

GFM stayed true to that specification’s design goals right up until Microsoft bastardized the isolated dollar sign to conditionally convert it into a $\LaTeX$ token¹ because of some cloistered, antiquated, ugly and slow institutional crapware called MathJax that had nothing to do with Markdown, and the fact that these assholes don’t want to promote performant, pretty, utf8-compatible $\KaTeX$ without a bribe from the Khan Academy.

Embrace and Extend Redux

Of course this was entirely intentional, because award-winning, world-class engineering teams had settled on $\KaTeX$ with double-dollar token boundaries for inline math, and fenced math blocks or pairs of double-dollar-only surrounding paragraphs for block $\KaTeX$ processing in 2015 — four years before the GFM spec was published.

The point here is that a 2-character delimiter that rarely occurs in typical prose is the normal ideal for situations like this. Had Microsoft stuck to only supporting $` … `$ I would not be writing this article in 2026, because that choice meets the normal ideal conditions for faithful introduction of inline math expressions in a Markdown spec. That choice is also conducive to carpal tunnel syndrome for professional math typists, so there’s something else to consider besides boundary-token uniqueness.

If I had to guess their motives for considering that blog article’s proposed syntax insufficient for their current needs, I suspect they were more about greed and market control and “customer dissatisfaction” than good F/OSS stewardship.

Or just Laziness, Impatience, and Hubris; but that’s not conspiratorial enough for this article. YMMV.

WorldWide Blast Radius

It is now an ambiguous disaster of engineering regex defects every time an author/implementer has to guess what the parser is supposed to do with sequences of isolated dollar signs occurring within a single paragraph of markdown prose. For example, consider a situation where French Canadian financial mathematicians discuss two prices in two different currencies, say US $1.50, and 2,00$ CA (admittedly contrived, but it illustrates the complexity). How would you write an i18n compliant GFM parser that understands that the stuff between the dollar signs here is not to be processed as inline $\LaTeX$, even though it’s syntactically valid $\TeX$ and conforms to this naïve spec?

What about a pair of Ruby/Perl variables in a function signature like foo($v,$w)? Same problem with the naïve spec. Have Claude² parse it all?

Good luck with that if you are doing a bulk GFM conversion of international legacy document formats to a non-GitHub platform. Not only will it be incredibly slow and expensive, but it will only “work” when rendered in Visual Studio, if it even works at all.

It’s one thing to say you will not write stuff today that confuses the parser now; it’s quite another to say the stuff written in the past will not confuse the parser either. Not today, and not future parser releases.

Unlike standards emerging from the JCP, there will never be a compliance-certifying test suite for this mess, because it’s an evolving situation on the ground at GitHub^2,3:

GitHub has not publicly disclosed its current open-source markdown parser. However, it is known that GitHub uses a custom implementation of Markdown for its platform, which is based on the GitHub Flavored Markdown (GFM) specification. This implementation includes support for various extensions and features that enhance the Markdown syntax used by GitHub.

Again, intentional deviance from Gruber’s aims.

Most disgustingly, the embrace and extend evil empire has an army of F/OSS free labor slaves to serve as sycophantic thought police about their efforts to pilfer the labor of others for their own market gains via AI³. Just check out the responses to the flagged HackerNews post of this page in the Links section below to meet a few of them.

Fuck Microsoft

Long story short, GFM is no longer an international industry spec, but an ugly-American-only proprietary vendor format no different from the Wikimedia garbage they copied it from.

Orion does not, and will never, use newer GFM parsers that pretend to track this dirty misfeature.

Instead, we rely on an internal fork of @markedjs/marked and will continue to do so for the foreseeable future.

Footnotes

1. It’s not an “extension” of the spec when the spec’s author mandates it for everyone who uses their products. IT IS THE DE FACTO NEW SPEC.

2. For the nitwits who still believe GitHub is using F/OSS to parse markdown: I encourage you to click on the GitHub source link to this article at the top of the page, copy and paste the first two paragraphs of the WorldWide Blast Radius section into a GitHub markdown editor, remove the backticks around the dollar signs, and witness firsthand that it renders the sample cases correctly, unlike the F/OSS Rust crap it claims to use. It may also behoove you to compare the aesthetics of their MathJax renderer to the $\KaTeX$ rendering we use on this site, to clear up any confusion about the qualitative discrepancies between the two products, much less the quantitative ones as they relate to rendering speed.

   

3. The quoted prose was bing’s original AI response for the past 24 hours, until I added the additional background links to this article, from which it “learned” how to say something less idiotic in response to the query “what is github’s current open source markdown parser”. This is the AI that’s taking our jobs, folks.