The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
astro-erudite	Ready	Preview	Comment	Sep 4, 2025 3:53am

Hi @dennexequiel - Will you able to attach a screengrab of math with and without katex css after removing rehypeDocument? Will be helpful in case someone can't run it locally.

Hi @dennexequiel - Will you able to attach a screengrab of math with and without katex css after removing rehypeDocument? Will be helpful in case someone can't run it locally.

Hi @Ankitz007,

Sure! I've added the with/without KaTeX CSS screenshots to the PR description.

Awesome! How about just using math or katex instead of usingKatex? Rest of it looks good to me. 👍🏻

Awesome! How about just using math or katex instead of usingKatex? Rest of it looks good to me. 👍🏻

I originally had katex, but before opening the PR I changed it to usingKatex for clarity. Since the flag's purpose right now is just to conditionally include KaTeX's CSS, either works. math would make more sense once we make it library-agnostic. I'll defer to @jktrn .

Is there any way that we can automatically detect katex usage rather than hard coding it into frontmatter? I think it'd be more elegant

Or any other way to just not necessitate a flag, it feels contrived

Or any other way to just not necessitate a flag, it feels contrived

I'll look into it and see if we can avoid using a flag.

How about using a regex based inference?

/**
 * Detects if content contains mathematical expressions that require KaTeX
 * @param content Raw markdown/MDX content string
 * @returns true if math expressions are found
 */
export function containsMathExpressions(content: string): boolean {
  // Check for inline math: $...$ (but not $$...$$)
  const inlineMathRegex = /(?<!\$)\$(?!\$)[^$\n]+?\$(?!\$)/g

  // Check for display math: $$...$$ (can span multiple lines)
  const displayMathRegex = /\$\$[\s\S]*?\$\$/g

  // Check for LaTeX-style delimiters: \(...\) for inline, \[...\] for display
  const latexInlineRegex = /\\\([^)]*\\\)/g
  const latexDisplayRegex = /\\\[[\s\S]*?\\\]/g

  return (
    inlineMathRegex.test(content) ||
    displayMathRegex.test(content) ||
    latexInlineRegex.test(content) ||
    latexDisplayRegex.test(content)
  )
}

Is there any way that we can automatically detect katex usage rather than hard coding it into frontmatter? I think it'd be more elegant

Hi @jktrn,

I've updated my commits and the PR description. Now, the KaTeX CSS is injected only when the .katex class name is present. It's a simple, lightweight approach that works the same. Let me know if this looks good.

How about using a regex based inference?

/**
 * Detects if content contains mathematical expressions that require KaTeX
 * @param content Raw markdown/MDX content string
 * @returns true if math expressions are found
 */
export function containsMathExpressions(content: string): boolean {
  // Check for inline math: $...$ (but not $$...$$)
  const inlineMathRegex = /(?<!\$)\$(?!\$)[^$\n]+?\$(?!\$)/g

  // Check for display math: $$...$$ (can span multiple lines)
  const displayMathRegex = /\$\$[\s\S]*?\$\$/g

  // Check for LaTeX-style delimiters: \(...\) for inline, \[...\] for display
  const latexInlineRegex = /\\\([^)]*\\\)/g
  const latexDisplayRegex = /\\\[[\s\S]*?\\\]/g

  return (
    inlineMathRegex.test(content) ||
    displayMathRegex.test(content) ||
    latexInlineRegex.test(content) ||
    latexDisplayRegex.test(content)
  )
}

Hey @Ankitz007, thanks for the suggestion! A regex-based check on the raw Markdown/MDX content could work, but it has a few drawbacks:

• It adds extra processing at build or runtime since the entire content must be scanned.
• It's easy to miss edge cases, like escaped $ signs or multiline LaTeX expressions, which can lead to false positives or negatives.
• Our current approach checks for the .katex class in the rendered HTML. It's lightweight and works seamlessly with SSG or Islands architecture.

For this reason, I'm sticking with runtime .katex detection. It's simple, safe, and avoids unnecessary parsing while achieving the same result.