6 ms·

Disappointing that we still need those kinds of workarounds instead of just having native MathML support in all browsers.

lifthrasiir 1y ago
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.
- holowoodman 1y ago
  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.
BlackFly 1y ago
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.
- swiftcoder 1y ago
  Katex can optionally produce MathML. By default it places individual symbols in a sea of <span> tags (due to inconsistent MathML output, I gather)
jillesvangurp 1y ago
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.
- KwanEsq 1y ago
  >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 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/Proving_the_Pythagorean_theorem https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/P... in Firefox and Edge both seem to render it correctly.
xigoi 1y ago
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.
- susam 1y ago
  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/ 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.
  - xigoi 1y ago
    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.
    - susam 1y ago
      > 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/ 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.

lifthrasiir 1y ago

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.

holowoodman 1y ago
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.

BlackFly 1y ago

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.

swiftcoder 1y ago
Katex can optionally produce MathML. By default it places individual symbols in a sea of <span> tags (due to inconsistent MathML output, I gather)

jillesvangurp 1y ago

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.

KwanEsq 1y ago
>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 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/Proving_the_Pythagorean_theorem https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/P... in Firefox and Edge both seem to render it correctly.

xigoi 1y ago

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.

susam 1y ago
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/ 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.
- xigoi 1y ago
  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.
  - susam 1y ago
    > 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/ 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.