# Math rendering (re-visited)

So, we’ve talked about this a while ago but wanted to re-open the topic of math rendering.

First, for a catch up see the amazing summary of the current state of play from @cben:

Things to note:

• Math is a special case. We need inline support and not just code block support like we decided to do for things like mermaid.
• MathJax is the most common client side library when it comes to parsing of LaTeX expressions
• There are a few ways that MathJax can interfere with your rendering pipeline because $ , $ , $$ , and $$ already have well defined meanings in Markdown (and CommonMark) and a single $commonly used for inline expression evaluation is also hard to disambiguate when typing things like Cheese is$10.40 + $0.20 tax What are folks latest opinions on this based on implementations in extensions to CommonMark? 2 Likes Pandoc has been handling math in markdown for 16 years, and I haven’t gotten complaints about the way we do it. It’s already in wide use. So I wouldn’t reinvent the wheel. We don’t allow $..$ or $$..$$ delimiters, because these already mean something in Markdown. Thus, display math is between $$ and $$, and inline math is between $ and $, with the restriction that the delimiters for inline math must be left- and right-flanking, respectively. (This prevents your example $10.40 + $0.20 from being parsed as math.) I’ve also added this syntax as an extension to my Haskell commonmark parser. Rough documentation with test cases here: Math is parsed before we handle emphasis or links, in the same parsing pass that handles inline code. In rendering HTML, the math can be handled in various ways. The easiest is to pass it through verbatim (or with minimal necessary HTML escaping), and let a library like MathJax or KaTeX handle it. It’s possible to speed things up by emitting the math in a specially marked span tag, so that these libraries don’t have to parse your whole document looking for math. But of course it’s also possible to do things like convert the math to MathML. These are all rendering details which don’t need to be decided here. 4 Likes My 2c: 1. Discussion of rendering process (real world demand) can be postponed, in favor of focus on syntax first. 2. Current syntax does not allows to select math dialect (it expects TeX only). There are nice user-friendly alternatives like asciimath. So: • Should we care about alternatives or push all use TeX? • If alternatives are appreciated, can we auto-detect dialect, or define it explicit? My personal opinion, it worth give a chance to asciimath. TeX is “much better than nothing”, but very complicated until someone use it every day. TeX is good default, with guarantee to express everything. But support of simplified alternative would be nice. If universal solution can not be found in reasonable time, i’ll be ok with existing TeX-only $$and (or anything else of this kind, approved by @jgm). 1 Like Thanks for this discussion! I just wanted to surface this issue as well with a sample implementation of a fork of commonmarker https://github.com/commonmark/cmark/issues/439 2 Likes Current syntax does not allows to select math dialect (it expects TeX only). There are nice user-friendly alternatives like asciimath Yeah - looking at the implementations and when I’ve spoken to most practicing mathematicians then TeX support only seems to be a feature not a bug. Therefore I’d be fine with the$$ +$ syntax assuming TeX support but that still leaves room for people to implement a renderer that would use asciimath for codeblock rendering if they wanted to support it…

asciimath

2 Likes

Codeblocks is not a big deal. Problem is with inlines. If we wish to land math right, we need to care about all cases. Or declare explicit - “we don’t like alternatives in math extension spec, and everything else is rejected, TeX is enough” (at least, that’s honest and clear for parser devs/users).

As i said before, math is special case with high demand. Primary blocker is inline syntax. I’d expect this things:

1. Decide if alternate dialects should be supported by syntax. I like support of asciimath, but may be other parties have different opinions.
$$x = y^2$$

`

in their commonmark documents, given that this would produce an
error in LaTeX (the equation environment can’t occur inside math
mode). That might seem counterintuitive to people who
know LaTeX.