Feature Request: Add Flag to allow pass-thru of LaTeX without MathJax Rendering

[falloutphil]

Add Flag to allow pass-thru of LaTeX without MathJax Rendering

Summary

Add a CLI flag (e.g. something like --no-math or --math-passthru) to disable the MathJax extension introduced in v0.7.0, allowing users to handle math rendering client-side with alternative renderers like KaTeX.

Background

First, I want to say I'm a big fan of go-grip! I've been using it successfully as the rendering engine for grip-mode in Emacs+webkit, and it's been fantastic for providing live GitHub-flavored markdown previews in my workflows.

Use-Case

I and other engineers where I work have been running v0.6.0 as part of our pipeline:

1. grip-mode (Emacs integration) uses go-grip to render markdown in a webkit browser
2. I then inject client-side KaTeX for math rendering instead of MathJax (alas I get no say in the library used!)
3. LaTeX expressions i.e. in the markdown pass through untouched (they're just considered raw text in v0.6.0)
4. Our KaTeX injection handles rendering the math expressions in the webkit browser

This gives me:

• Better integration with existing tooling
• Control over the math rendering configuration and the choice to use any library (if I chose not to use the Mathjax default)

The Problem

In v0.7.0, the addition of server-side MathJax rendering (while a very cool feature for many users!) breaks our workflow:

// v0.6.0 - math expressions pass through untouched
md := goldmark.New(
    goldmark.WithExtensions(
        extension.Linkify,
        // ... other extensions, but NO mathjax
        &mermaid.Extender{RenderMode: mermaid.RenderModeClient},
    ),
    // ...
)

// v0.7.0 - math expressions are processed server-side
md := goldmark.New(
    goldmark.WithExtensions(
        extension.Linkify,
        // ... other extensions
        mathjax.MathJax,  // ← Forces server-side rendering
        ghissue.New(),
    ),
    // ...
)

With v0.7.0, math expressions are transformed server-side by MathJax before reaching the browser, so our client-side KaTeX injection has nothing to process.

Broader Impact

This issue extends beyond just LaTeX/math rendering. The same principle applies to any content that users might want to see and chose how to render client-side:

• Graph libraries (Vega-Lite, D3.js, etc.) - we're using similar patterns for data visualization
• Diagram libraries (though mermaid already has client-side mode!)
• Custom rendering engines for domain-specific notation

The pattern of "pass markup through, let client render" I think is valuable for users building sophisticated rendering pipelines - and it's also fairly straightforward to support - as it's just the act of not applying a transformation.

Possible Solution (I'm not a go programmer - so forgive any daft ideas!)

I could have a blast at this myself - by I don't know go - so I might do a rubbish job!

Add a CLI flag to disable math processing, similar to existing flags:

// cmd/root.go
func init() {
    rootCmd.Flags().String("theme", "auto", "Select css theme [light/dark/auto]")
    rootCmd.Flags().BoolP("browser", "b", true, "Open new browser tab")
    rootCmd.Flags().StringP("host", "H", "localhost", "Host to use")
    rootCmd.Flags().IntP("port", "p", 6419, "Port to use")
    rootCmd.Flags().Bool("bounding-box", true, "Add bounding box to HTML")
    rootCmd.Flags().Bool("no-reload", false, "Disable automatic browser reload on file changes")

    // NEW FLAG:
    rootCmd.Flags().Bool("no-math", false, "Disable MathJax rendering (passthrough for client-side renderers)")
}

Then conditionally include the mathjax extension:

// internal/parser.go
type Parser struct {
    theme  string
    noMath bool  // NEW
}

func NewParser(theme string, noMath bool) *Parser {
    return &Parser{
        theme:  theme,
        noMath: noMath,
    }
}

func (m Parser) MdToHTML(input []byte) ([]byte, error) {
    extensions := []goldmark.Extender{
        extension.Linkify,
        extension.Table,
        extension.Strikethrough,
        footnote.Footnote,
        tasklist.TaskList,
        emoji.Emoji,
        &hashtag.Extender{},
        alert.New(),
        highlighting.Highlighting,
        &mermaid.Extender{RenderMode: mermaid.RenderModeClient},
    }

    // Conditionally add MathJax if not disabled
    if !m.noMath {
        extensions = append(extensions, mathjax.MathJax)
    }

    extensions = append(extensions, ghissue.New())

    md := goldmark.New(
        goldmark.WithExtensions(extensions...),
        // ... rest of config
    )
    // ...
}

Justification

This would allow users like me and my team buddies (and others with a similar use case) to:

1. Upgrade to v0.7.0+ and benefit from other improvements
2. Continue using client-side rendering for math and other content
3. Maintain existing workflows without regression
4. Future-proof our integration against similar changes

The default behavior would remain unchanged of course (MathJax enabled), preserving backward compatibility for v0.7.0 users while restoring the v0.6.0 behavior for those who need it.

Conclusion

I understand that adding MathJax was a very valuable feature for many (even most!) users, and I'm certainly not asking to remove it! More just a request to keep open the possibility to opt out when using alternative rendering approaches.

Thanks for considering this request, and thanks again for maintaining such a great tool!

---

Testing Note: I've verified this approach works by comparing v0.6.0 (no MathJax) and v0.7.0 (forced MathJax) behavior in my grip-mode integration. Happy to provide more details or help test a PR if this feature is accepted.

[chrishrb]

but whats the difference between MathJax and KaTeX? I looked at grip-mode and it looks like it also just opens go-grip? So i don't really understand the use case here. Maybe it would make more sense to just integrate go-grip even more into an emac (or for me nvim) plugin and not building around it and creating workarounds.

[falloutphil]

Thanks for the reply — I think there’s a small misunderstanding of the use case.

Re the Emacs/Nvim plugin suggestion: totally agree tighter editor integration is nice, but it doesn’t really address this specific issue -even with a dedicated plugin, go-grip is still acting as a renderer in a pipeline, and having an opt-out for server-side math transforms is what keeps that pipeline composable.

I’m not claiming KaTeX is better than MathJax. The issue is that they’re different enough that it matters: we’ve seen real documents where KaTeX and MathJax don’t behave the same, and depending on the input/config either one can be the wrong choice for a given pipeline. That’s not go-grip’s fault - it just means “always transform math with MathJax server-side” isn’t workable for everyone all of the time.

In our workflow, go-grip is one stage in a chain (editor → go-grip → embedded WebKit). In v0.6.0 math expressions passed through unchanged, so we could do client-side rendering (KaTeX today, could be something else tomorrow). In v0.7.0, enabling the MathJax extension means the server rewrites math before it reaches the browser, which breaks downstream renderers/post-processing that expect the original source.

That said, I completely get the goal of being GitHub-like — and keeping MathJax enabled by default matches GitHub (their docs say GitHub’s math rendering uses MathJax). Many users will be very happy with this (including me in other use-cases)! The request is just an opt-out for composable pipelines: a --no-math / --math-passthru flag that simply skips registering the MathJax extension. Default behavior stays exactly as-is.

If you’re open to the approach, I’m happy to submit a PR so it’s not extra work on your side.