Does anyone know why Google doesn’t adopt something like this in Google Docs / Slides? It’s amazing to me that after all these years Google Docs still has some of the worst equation editing of all word processors. I was hopeful when they added markdown support that first class equation editing was near, but it’s been a while now and still nothing.
Speculation: Google has a moderate amount of “core” applications that are clearly getting indefinite support, but all of those services also have a very conservative feature and update roadmap. New features are going to be limited to things that alphabet has in its global focus, so crap like Gemini and not much else.
I’m sure engineers working on products like the google web suite would love to implement this kind of thing but have zero authorization or resources for that.
Experimental applications, the ones that bloom rapidly and get shut down in a cycle that google has become known for, are ironically way more likely to see this kind of cool niche update.
Twisted company has a whacky way of managing their products, because advertisement drives their revenue so everything else is just freestyle jazz.
This is very obnoxious when transferring documents from Gemini to google docs (and not just math, tables/code sections are often not transferred correctly as well).
I switched from MathJax to KaTeX earlier this year for my blog. So far, it has been working out well.
The only feature I really missed was the ability to use \label and \eqref for equation referencing, since KaTeX doesn't support these commands [1]. I worked around this limitation with a small custom setup defining my own \label and a custom \eqnref (not exactly \eqref though) [2].
Another thing that bothered me a little was that the KaTeX autorender extension does not recognise \begin{align*}, \begin{alignat*}, etc. as top-level delimiters by default [3] but this was trivial to fix by customising the set of default delimiters [2].
I know KaTeX supports server-side rendering but I don't use that yet [4]. I still use client-side rendering. Despite that my maths pages [5][6] render quickly since they are usually small, with only a single reflow from the initial load to the rendered page, without the continual reflows or jitter I used to see with MathJax. Overall, I am quite happy with the switch from MathJax to KaTeX.
This is really awesome! I've been really interested in creating an interactive introduction to basic algebra where parts of the equation can be manipulated using drag-and-drop, but I couldn't really figure out the best way to do it. Maybe using Katex is the way to go?
I think the latest version of MathJax (v4) has rendering speed comparable to, if not faster than, KaTeX. It also looks (subjectively) significantly better than KaTeX, and supports a wide array of accessibility features.
I wish there was a native version of this. Every SSG seems to have the problem of having to depend on node in order to prerender html for math with katex.
I've been using katex-rs, a Rust rewrite, to implement LaTeX rendering for a Rust web app. It was easy enough to hook into pulldown_cmark, so that $ and $$ and render a decent subset of LaTeX. Since pulldown_cmark is a proper Markdown parser, you listen for Event::InlineMath and Event::DisplayMath then call KaTeX directly. No regex or HTML escaping necessary. In my web app, this is all encapsulated into a single function that I can call within Tera templates. It's as SSR as it gets; no Node.js or client-side JavaScript necessary.
The costliest asset is a minified stylesheet served through a CDN. (I do this out of laziness, and because the web app as-is needs nothing more than the standard Rust toolchain).
Do you have a reference on how to hook it into pulldown_cmark? I'd love to add math support into to my markdown rendering app but I haven't had time to investigate this myself yet.
The docs recommend setting up KaTeX CSS (which requires either a CDN link or Node), but by changing output to 'mathml,' you can have the browser render equations with zero dependencies.
Currently that feature is unsupported or I just can't figure out how to do it. With the latest compiler version 0.14 any .typ file I try to compile will incur warnings about skipping the equations (skipping the main reason I'd want to compile a Typst file to HTML...).
As per their GitHub they haven't included MathJax or KaTeX support yet as they were more focused on semantic and structural accuracy of HTML output with this release.
I wrote a library with a syntax similar to Typst (actually inspired by AsciiMath; and predates Typst by about a decade). Then there are Markdown-It plugins around it.
It may or may not be as fast, but MathJax has broader support for LaTeX features, better accessibility features, and has slightly better typography in my very subjective opinion, and that's more important to me than a bit of rendering time.
A few years ago I was evaluating options to move away from a deprecated external latex library my company relied on in Confluence, and tested Notion. I was super impressed at the rendering speed of their latex implementation (KaTex of course). As other have mentioned, not everything is there, but it was sufficiently good for our purposes. The switch was a pain, I hoped that Notion had good tools to move over from Confluence, but we had to do a custom job relying on sketchy undocumented APIs
I use KaTeX for my blog, and indeed KaTeX was faster than MathJax 2, but MathJax 3 (a complete rewrite) has significantly improved performance from the previous version and is now a bit faster than KaTeX in my experience.
It is amusing that, in my particular environment, KaTeX is slower than MathJax 3 in processing time but actually faster when font loading time is accounted for. Both loads from your domain so there should be no routing issue; KaTeX fonts turned out to be substantially smaller than MathJax 3 at least in this particular case. Is this intentional or just a lucky coincidence for KaTeX? (KaTeX is also ~70% smaller than MathJax 3 in their gzipped forms, so it might well be intentional!)
Outline (https://www.getoutline.com) includes the KaTeX renderer in it's documents if you're interested in trying a knowledge base that has great direct support.
I use this all the time when editing markdown in vscodium. It's fast enough for the side preview and supports all the LaTeX commands I need so far. When I need a PDF Pandoc handles the conversion well enough for me. I've tried using Quarto's preview but it's so slow in comparison.
The commenter says pre-rendered/server-side-rendered mathematics (via katex) is great - I’ve found the opposite. It’s probably great if you have an article with one or two equations. On the other hand, if you have an article which uses mathematics pervasively, like many pure mathematics articles, it quickly becomes far more space efficient to render the mathematics on the client side. You can quickly get 200kB+ pages by pre-rendering.
My experience with dynamically rendered math has been the opposite: if you have lots of equations to render, it inevitably takes some milliseconds to render, which makes the whole content move around and shake as rendering takes places.
Of course, if the page uses more symbols in various sizes, then a few more fonts files (.woff2) need to be pulled in which case the weight of KaTeX would increase a bit too. Each font file weighs between 4 kB and 28 kB.
Katex produces MathML. The problem katex solves is that MathML is really ungainly for authoring equations. So instead you write equations in a DSL (which most people just call latex) and Katex compiles that to HTML/MathML for you.
You can do this server side or client side and sadly too many people do it client side. If you do it server side, it is just one more step in your build next to transpiling and bundling.
We have web assembly and the power to run whatever you can manage to compile with that. There's no real need for "native" support.
The key issue is that the latex stack wasn't really designed to be packaged up like this. It just has a lot of moving parts that are vaguely dependent on running in a full blown unix like shell environment. So the resulting code would be a rather big blob. Running that in a browser isn't that hard if you can live with that having a fair bit of overhead. This has been done. But it's a bit overkill for publishing content on the web.
Browsers don't have native support for MathML any more for a good reason. Mozilla did support this for a while but dropped it because of limited adoption and high maintenance burden. Rendering formulas is a bit of a niche problem and the intended audience is just kind of picky when it comes to technology and generally not that into doing more advanced things with web browsers. Also, most people writing scientific articles would be writing those for publication and probably use Latex any way. So translating all their formulas to MathML is an extra step that they don't need or want.
At least that's my analysis of this. I'm not really part of the target audience here and I'm sure there are plenty of MathML fans who disagree with this.
In any case Katex makes an acceptable (to some) compromise by packaging this stuff up in a form where it can be run server side and is easy to integrate on a simple web page. A proper solution with buy-in from the scientific community (for e.g. MathML) is a much bigger/harder thing to solve.
IMHO, a light weight solution based on web assembly could be the way to go. But of course the devil is in the details because if the requirements are "do whatever latex does" it gets quite hard. And anything else might be too limited.
>Browsers don't have native support for MathML any more for a good reason. Mozilla did support this for a while but dropped it because of limited adoption and high maintenance burden.
AFAIK Safari was the first browser to support MathML fully, and FF also supports it. Chromium was the latest IIRC. MathML has been baseline-available since 2023 after Chromium got support.
The big issue is that MathML is designed as a target language, not something directly writable. So we still need a KaTeX equivalent, which compiles either LaTeX equations or other markup languages to MathML.
Regardless, the core issue that you have mentioned is now gone (or will be in a few years even if you want more availability).
MathML has been supported in all major browsers for several years now. I use it regularly and never had a major issue, just some subtle inconsistencies between different browser engines.
For someone used to the typesetting quality of LaTeX, MathML leaves much to be desired. For example, if you check the default demo at https://mk12.github.io/web-math-demo/ you'll notice that the contour integral sign (∮) has an unusually large circle in the MathML rendering (with most default browser fonts) which is quite inconsistent with how contour integrals appear in print. It's not the fault of MathML of course since the symbol '∮' is rendered using the available fonts. It is not surprising that a glyph designed for 'normal' text sizes doesn't look good when it's simply scaled up to serve as a large integral symbol.
Even if we address this problem using custom web fonts, there are numerous other edge cases (spacing within subscripts and superscripts, sizing within subscripts within subscripts, etc.) that look odd in MathML. At that point, we might as well use full KaTeX. Granted, many of these issues are minor. If they don't bother you, MathML could be a good alternative. Unfortunately, for me, these inconsistencies do bother me, so I've been using MathJax, and more recently KaTeX, since they get you closer to the typesetting quality of LaTeX compared to MathML.
If you want every symbol to look exactly like in Latin Modern (the default typeface in LaTeX), simply use Latin Modern as your math typeface. The size of the circle on the contour integral is a matter of personal preference, but it just depends on the typeface and is orthogonal to the choice of LaTeX/MathML.
> The size of the circle on the contour integral is a matter of personal preference, but it just depends on the typeface and is orthogonal to the choice of LaTeX/MathML.
Indeed! That was precisely the point of my previous comment.
I agree that switching to Latin Modern resolves some of the minor issues I mentioned earlier. However, it does not resolve all of them. In particular, it does not address the spacing concerns I mentioned earlier. For example compare the following on <https://mk12.github.io/web-math-demo/> with Latin Modern selected:
\sum_{q \le x/d}
Or:
\sum_{d \le \sqrt{x}}
The difference in spacing is really small but it is noticeable enough to bother me. Also, this is just one of several examples where I wasn't happy with the spacing decisions in MathML rendering. The more time I spent with MathML, the more such minor annoyances I found. Since KaTeX produces the spacing and rendering quality I am happy with, out of the box, I have continued using it.
Also, my goal isn't to replicate LaTeX's spacing behaviour faithfully. I just want the rendered formulas to look good, close to what I find in print or LaTeX output, even if it's a bit different. It so happens that I find myself often bothered by some of the spacing decisions in edge cases when using MathML, so I tend to just stick with MathJax or KaTeX.
But that's just me. All of this may seem like nitpicking (and it certainly is) but when I'm spending my leisure time maintaining my personal website and blog or archiving my mathematics notes, I want the pages to look good to me first, while still looking good to others. If MathML output looks good to others with certain fonts, that's a perfectly valid reason to use it.
The example with x/d seems to be wrong because the compiler inserts a redundant <mrow> around the slash operator. Temml seems to render it better. (There is still spacing, unlike the LaTeX version, but honestly I prefer that.)
You are right. Getting rid of the stray <mrow> around '/' does make the spacing better. Also, today I learnt about Temml. It looks very interesting and I'll be trying it out. Thanks for this nice discussion!
We will continue to have "workarounds" even after MathML because it is not an authoring-friendly markup. My ideal in this regard is a simplified eqn-like markup, which is not hard to write by hand nor hard to parse either.
Yes, but those workarounds will be author-side ones. Like how HTML isn't very friendly to write by hand for many, so CMSes use e.g. Markdown or WYSIWYG to make it friendlier. In the same way, there will always be preprocessors in authoring tools that might convert e.g. TeX notation to MathML.
My point is that "fast" in those kinds of workarounds wouldn't be a problem for visitors of a site because all the browser gets is just native MathML.
Does anyone know why Google doesn’t adopt something like this in Google Docs / Slides? It’s amazing to me that after all these years Google Docs still has some of the worst equation editing of all word processors. I was hopeful when they added markdown support that first class equation editing was near, but it’s been a while now and still nothing.
Speculation: Google has a moderate amount of “core” applications that are clearly getting indefinite support, but all of those services also have a very conservative feature and update roadmap. New features are going to be limited to things that alphabet has in its global focus, so crap like Gemini and not much else.
I’m sure engineers working on products like the google web suite would love to implement this kind of thing but have zero authorization or resources for that.
Experimental applications, the ones that bloom rapidly and get shut down in a cycle that google has become known for, are ironically way more likely to see this kind of cool niche update.
Twisted company has a whacky way of managing their products, because advertisement drives their revenue so everything else is just freestyle jazz.
"Freestyle jazz" is pretty accurate, IMO.
This is very obnoxious when transferring documents from Gemini to google docs (and not just math, tables/code sections are often not transferred correctly as well).
I have a javascript hack from the dev console where I can at least print the chat to PDF, https://andrewpwheeler.com/2025/08/28/deep-research-and-open... (that at least worked 2 months ago)
If only they'd added it in the first iteration when they had a free hand.
I switched from MathJax to KaTeX earlier this year for my blog. So far, it has been working out well.
The only feature I really missed was the ability to use \label and \eqref for equation referencing, since KaTeX doesn't support these commands [1]. I worked around this limitation with a small custom setup defining my own \label and a custom \eqnref (not exactly \eqref though) [2].
Another thing that bothered me a little was that the KaTeX autorender extension does not recognise \begin{align*}, \begin{alignat*}, etc. as top-level delimiters by default [3] but this was trivial to fix by customising the set of default delimiters [2].
I know KaTeX supports server-side rendering but I don't use that yet [4]. I still use client-side rendering. Despite that my maths pages [5][6] render quickly since they are usually small, with only a single reflow from the initial load to the rendered page, without the continual reflows or jitter I used to see with MathJax. Overall, I am quite happy with the switch from MathJax to KaTeX.
[1] https://katex.org/docs/supported.html
[2] https://github.com/susam/susam.net/blob/0.3.0/layout/include...
[3] https://katex.org/docs/autorender#api
[4] https://news.ycombinator.com/item?id=44615271
[5] https://susam.net/mutually-attacking-knights.html
[6] https://susam.net/zigzag-number-spiral.html
As a very much work-in-progress, yesterday, I started working on interactive equations https://p.migdal.pl/equations-explained-colorfully/ (it uses KaTeX under the hood).
The idea is similar to https://betterexplained.com/articles/colorized-math-equation..., but with mouseover interaction (both for further description, but also for accessibility). For a deeper dive in the topic of explorable explanations, I wrote https://p.migdal.pl/blog/2024/05/science-games-explorable-ex... (was here on the HN as well).
This is really awesome! I've been really interested in creating an interactive introduction to basic algebra where parts of the equation can be manipulated using drag-and-drop, but I couldn't really figure out the best way to do it. Maybe using Katex is the way to go?
I think the latest version of MathJax (v4) has rendering speed comparable to, if not faster than, KaTeX. It also looks (subjectively) significantly better than KaTeX, and supports a wide array of accessibility features.
I wish there was a native version of this. Every SSG seems to have the problem of having to depend on node in order to prerender html for math with katex.
I've been using katex-rs, a Rust rewrite, to implement LaTeX rendering for a Rust web app. It was easy enough to hook into pulldown_cmark, so that $ and $$ and render a decent subset of LaTeX. Since pulldown_cmark is a proper Markdown parser, you listen for Event::InlineMath and Event::DisplayMath then call KaTeX directly. No regex or HTML escaping necessary. In my web app, this is all encapsulated into a single function that I can call within Tera templates. It's as SSR as it gets; no Node.js or client-side JavaScript necessary.
The costliest asset is a minified stylesheet served through a CDN. (I do this out of laziness, and because the web app as-is needs nothing more than the standard Rust toolchain).
https://github.com/katex-rs/katex-rs
Do you have a reference on how to hook it into pulldown_cmark? I'd love to add math support into to my markdown rendering app but I haven't had time to investigate this myself yet.
https://gist.github.com/akar1ngo/7d4ea6e9dfc369526beb75092cb...
Thank you for your account and reply! Awesome stuff :)
I use it in my static site generator in Python via https://github.com/rubenvannieuwpoort/PyKaTeX.
Disclaimer: I am the author of PyKaTeX.
If your use case is generating html, MathML is supported in all modern browsers: https://developer.mozilla.org/en-US/docs/Web/MathML#browser_...
Hugo includes native KaTeX: https://gohugo.io/functions/transform/tomath/
The docs recommend setting up KaTeX CSS (which requires either a CDN link or Node), but by changing output to 'mathml,' you can have the browser render equations with zero dependencies.
That's news to me! The last time I used Hugo it didn't support that yet and I had to serve the js bundle to run in the browser.
Port it? Or maybe bundle a tiny interpreter instead of Node.
Also see Temml, a fork of KaTeX that compiles to MathML instead of styled HTML.
https://temml.org/
I am curious, if there is any library for inline formula like KaTeX, but supporting Typst syntax?
I would assume you pretty much get that out of the box given Typst compiles to HTML natively?
Currently that feature is unsupported or I just can't figure out how to do it. With the latest compiler version 0.14 any .typ file I try to compile will incur warnings about skipping the equations (skipping the main reason I'd want to compile a Typst file to HTML...).
As per their GitHub they haven't included MathJax or KaTeX support yet as they were more focused on semantic and structural accuracy of HTML output with this release.
I was more looking for things I can use with blogs with Markdown and frameworks like Astro.
But with the development of Typst, maybe the way to go is to use Typst rather than Markdown.
I wrote a library with a syntax similar to Typst (actually inspired by AsciiMath; and predates Typst by about a decade). Then there are Markdown-It plugins around it.
https://mathup.xyz/
https://github.com/runarberg/markdown-it-math
It may or may not be as fast, but MathJax has broader support for LaTeX features, better accessibility features, and has slightly better typography in my very subjective opinion, and that's more important to me than a bit of rendering time.
A few years ago I was evaluating options to move away from a deprecated external latex library my company relied on in Confluence, and tested Notion. I was super impressed at the rendering speed of their latex implementation (KaTex of course). As other have mentioned, not everything is there, but it was sufficiently good for our purposes. The switch was a pain, I hoped that Notion had good tools to move over from Confluence, but we had to do a custom job relying on sketchy undocumented APIs
I use KaTeX for my blog, and indeed KaTeX was faster than MathJax 2, but MathJax 3 (a complete rewrite) has significantly improved performance from the previous version and is now a bit faster than KaTeX in my experience.
This website has a comparison of the loading times of the same LaTeX rendered in both KaTeX and MathJax: https://www.intmath.com/cg5/katex-mathjax-comparison.php
It is amusing that, in my particular environment, KaTeX is slower than MathJax 3 in processing time but actually faster when font loading time is accounted for. Both loads from your domain so there should be no routing issue; KaTeX fonts turned out to be substantially smaller than MathJax 3 at least in this particular case. Is this intentional or just a lucky coincidence for KaTeX? (KaTeX is also ~70% smaller than MathJax 3 in their gzipped forms, so it might well be intentional!)
So if speed is comparable, which is best?
Outline (https://www.getoutline.com) includes the KaTeX renderer in it's documents if you're interested in trying a knowledge base that has great direct support.
https://docs.getoutline.com/s/guide/doc/formatting-kn6wBtxlQ...
I use this all the time when editing markdown in vscodium. It's fast enough for the side preview and supports all the LaTeX commands I need so far. When I need a PDF Pandoc handles the conversion well enough for me. I've tried using Quarto's preview but it's so slow in comparison.
A commenter left this on another HN post [0] and I thought it was worth its own.
[0] https://news.ycombinator.com/item?id=45701400
The commenter says pre-rendered/server-side-rendered mathematics (via katex) is great - I’ve found the opposite. It’s probably great if you have an article with one or two equations. On the other hand, if you have an article which uses mathematics pervasively, like many pure mathematics articles, it quickly becomes far more space efficient to render the mathematics on the client side. You can quickly get 200kB+ pages by pre-rendering.
My experience with dynamically rendered math has been the opposite: if you have lots of equations to render, it inevitably takes some milliseconds to render, which makes the whole content move around and shake as rendering takes places.
Indeed. It was hell to navigate pages that rendered MathJax on demand. That also improved a lot though.
> it inevitably takes some milliseconds to render, which makes the whole content move around and shake as rendering takes places.
What a boldly incorrect comment! It's like you didn't even read the first point in TFA!
Did you read the article? That's what the KaTeX project specifically claims to address.
The previous comment was about using KaTeX for pre-rendered equations.
It's not too late to delete this comment.
KaTeX weighs about the same if you do care about those metrics, however.
In case anyone wants to look at actual numbers about how much KaTeX weighs for a simple mathematics page: https://news.ycombinator.com/item?id=44614133
Quoting the relevant part from that link:
Of course, if the page uses more symbols in various sizes, then a few more fonts files (.woff2) need to be pulled in which case the weight of KaTeX would increase a bit too. Each font file weighs between 4 kB and 28 kB.Could you please provide an example?
Is 200kB supposed to be a lot?
Powering the math inference revolution given is used by every other LLM provider such as ………(name it).
Some earlier discussions (2022): https://news.ycombinator.com/item?id=31441979
Most critique of KaTeX over MathJax is reduced support for LaTeX features.
Disappointing that we still need those kinds of workarounds instead of just having native MathML support in all browsers.
Katex produces MathML. The problem katex solves is that MathML is really ungainly for authoring equations. So instead you write equations in a DSL (which most people just call latex) and Katex compiles that to HTML/MathML for you.
You can do this server side or client side and sadly too many people do it client side. If you do it server side, it is just one more step in your build next to transpiling and bundling.
Katex can optionally produce MathML. By default it places individual symbols in a sea of <span> tags (due to inconsistent MathML output, I gather)
We have web assembly and the power to run whatever you can manage to compile with that. There's no real need for "native" support.
The key issue is that the latex stack wasn't really designed to be packaged up like this. It just has a lot of moving parts that are vaguely dependent on running in a full blown unix like shell environment. So the resulting code would be a rather big blob. Running that in a browser isn't that hard if you can live with that having a fair bit of overhead. This has been done. But it's a bit overkill for publishing content on the web.
Browsers don't have native support for MathML any more for a good reason. Mozilla did support this for a while but dropped it because of limited adoption and high maintenance burden. Rendering formulas is a bit of a niche problem and the intended audience is just kind of picky when it comes to technology and generally not that into doing more advanced things with web browsers. Also, most people writing scientific articles would be writing those for publication and probably use Latex any way. So translating all their formulas to MathML is an extra step that they don't need or want.
At least that's my analysis of this. I'm not really part of the target audience here and I'm sure there are plenty of MathML fans who disagree with this.
In any case Katex makes an acceptable (to some) compromise by packaging this stuff up in a form where it can be run server side and is easy to integrate on a simple web page. A proper solution with buy-in from the scientific community (for e.g. MathML) is a much bigger/harder thing to solve.
IMHO, a light weight solution based on web assembly could be the way to go. But of course the devil is in the details because if the requirements are "do whatever latex does" it gets quite hard. And anything else might be too limited.
>Browsers don't have native support for MathML any more for a good reason. Mozilla did support this for a while but dropped it because of limited adoption and high maintenance burden.
This seems to just be entirely untrue? https://developer.mozilla.org/en-US/docs/Web/MathML shows wide support (For Chromium/Blink-based since version 109) and if I open the example https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/P... in Firefox and Edge both seem to render it correctly.
I assume GP just totally missed that it was added to Chromium 2-3 years ago, thanks to Igalia contributing support for it.
Indeed completely missed that. Of course, the web needs to work on safari and firefox as well. So, it doesn't quite address the core issue here.
AFAIK Safari was the first browser to support MathML fully, and FF also supports it. Chromium was the latest IIRC. MathML has been baseline-available since 2023 after Chromium got support.
The big issue is that MathML is designed as a target language, not something directly writable. So we still need a KaTeX equivalent, which compiles either LaTeX equations or other markup languages to MathML.
Regardless, the core issue that you have mentioned is now gone (or will be in a few years even if you want more availability).
The core issue that Chromium was the one major browser not supporting it? Or what core issue?
MathML has been supported in all major browsers for several years now. I use it regularly and never had a major issue, just some subtle inconsistencies between different browser engines.
For someone used to the typesetting quality of LaTeX, MathML leaves much to be desired. For example, if you check the default demo at https://mk12.github.io/web-math-demo/ you'll notice that the contour integral sign (∮) has an unusually large circle in the MathML rendering (with most default browser fonts) which is quite inconsistent with how contour integrals appear in print. It's not the fault of MathML of course since the symbol '∮' is rendered using the available fonts. It is not surprising that a glyph designed for 'normal' text sizes doesn't look good when it's simply scaled up to serve as a large integral symbol.
Even if we address this problem using custom web fonts, there are numerous other edge cases (spacing within subscripts and superscripts, sizing within subscripts within subscripts, etc.) that look odd in MathML. At that point, we might as well use full KaTeX. Granted, many of these issues are minor. If they don't bother you, MathML could be a good alternative. Unfortunately, for me, these inconsistencies do bother me, so I've been using MathJax, and more recently KaTeX, since they get you closer to the typesetting quality of LaTeX compared to MathML.
If you want every symbol to look exactly like in Latin Modern (the default typeface in LaTeX), simply use Latin Modern as your math typeface. The size of the circle on the contour integral is a matter of personal preference, but it just depends on the typeface and is orthogonal to the choice of LaTeX/MathML.
> The size of the circle on the contour integral is a matter of personal preference, but it just depends on the typeface and is orthogonal to the choice of LaTeX/MathML.
Indeed! That was precisely the point of my previous comment.
I agree that switching to Latin Modern resolves some of the minor issues I mentioned earlier. However, it does not resolve all of them. In particular, it does not address the spacing concerns I mentioned earlier. For example compare the following on <https://mk12.github.io/web-math-demo/> with Latin Modern selected:
Or: The difference in spacing is really small but it is noticeable enough to bother me. Also, this is just one of several examples where I wasn't happy with the spacing decisions in MathML rendering. The more time I spent with MathML, the more such minor annoyances I found. Since KaTeX produces the spacing and rendering quality I am happy with, out of the box, I have continued using it.Also, my goal isn't to replicate LaTeX's spacing behaviour faithfully. I just want the rendered formulas to look good, close to what I find in print or LaTeX output, even if it's a bit different. It so happens that I find myself often bothered by some of the spacing decisions in edge cases when using MathML, so I tend to just stick with MathJax or KaTeX.
But that's just me. All of this may seem like nitpicking (and it certainly is) but when I'm spending my leisure time maintaining my personal website and blog or archiving my mathematics notes, I want the pages to look good to me first, while still looking good to others. If MathML output looks good to others with certain fonts, that's a perfectly valid reason to use it.
The example with x/d seems to be wrong because the compiler inserts a redundant <mrow> around the slash operator. Temml seems to render it better. (There is still spacing, unlike the LaTeX version, but honestly I prefer that.)
You are right. Getting rid of the stray <mrow> around '/' does make the spacing better. Also, today I learnt about Temml. It looks very interesting and I'll be trying it out. Thanks for this nice discussion!
We will continue to have "workarounds" even after MathML because it is not an authoring-friendly markup. My ideal in this regard is a simplified eqn-like markup, which is not hard to write by hand nor hard to parse either.
Yes, but those workarounds will be author-side ones. Like how HTML isn't very friendly to write by hand for many, so CMSes use e.g. Markdown or WYSIWYG to make it friendlier. In the same way, there will always be preprocessors in authoring tools that might convert e.g. TeX notation to MathML.
My point is that "fast" in those kinds of workarounds wouldn't be a problem for visitors of a site because all the browser gets is just native MathML.
KaTeX is solid;
Super promising.