7 ms·

Nice! A welcome addition! Too bad they're not using KaTeX [0] instead. It renders the maths server-side, so there's no runtime needed. An additional bonus is

Nice! A welcome addition! Too bad they're not using KaTeX [0] instead. It renders the maths server-side, so there's no runtime needed. An additional bonus is that the resulting math is copy-pasteable, which in the case of disply math might not be that useful (since most equations are to complex to be meaningfully copy-pasted with unicode), but it helps from inline math dissappearing when copy pasting texts. But, that being said, I'm sure they had their reasons to do so. For one, MathJax seems more well-known by quite a bit so maybe it's the safer option. 1: https://katex.org/ https://katex.org/

powersnail 4y ago
MathJax can do server side rendering too now!
joppy 4y ago
For pages with lots of mathematics markup, it is far better (in terms of download size) to send the latex markup and the katex library to the browser, and render it there. I tried rendering the mathematics server-side using katex on my own website a while ago, and the div soup generated by katex takes up loads of space. Original page (compressed): 10 kB Page with server-rendered Katex (compressed): 50 kB Katex.js (compressed): 80 kB So after two pages it’s a net win to not render the mathematics server-side.
- dllu 4y ago
  For my blog (e.g. https://daniel.lawrence.lu/blog/y2021m09d08/ https://daniel.lawrence.lu/blog/y2021m09d08/ with tons of math), I render the math serverside using MathJax and serve them as SVG images (with alt text for the visually impaired). They get cached too which is nice especially since many symbols are duplicated. Seems fast enough for me.
  - lelandfe 4y ago
    You're being modest. This is easily the most performant option... although it means losing interactivity (right clicking equations on GitHub allows copy to clipboard, A11y features, etc). Running the JS client side, like GitHub, means blocking the thread. You're either going to be 1. delaying other JS from running, or 2. rendering late, shifting the layout – which is what GitHub has chosen: https://imgur.com/a/y47haf9 https://imgur.com/a/y47haf9 (Sending the rendered div's is a non-starter. Large document sizes delay domContentLoaded, slow down browsers, aren't shared cacheable resources, etc.) Your approach, then. On your page there are 178 SVGs. Total gzipped size is 490KB. SVGO[0] gets that down to 311KB – that's 1.74KB transferred per equation. These are non-blocking, immutable, cacheable assets. Brilliant. Upgrades: - Figure out viewbox and inline height/width values on the HTML so no layout jank (aka "Cumulative Layout Shift"/CLS) occurs. Unsure if this is possible for inline math. - Add `loading="lazy"` afterwards. Users that don't scroll the entire length of the page won't suffer unneeded downloads, and the inlined sizes will prevent late CLS for those that do. - Maybe re-add interactivity? Cheap option: just support copying alt-text in a context menu. [0] https://github.com/svg/svgo https://github.com/svg/svgo
    - dllu 4y ago
      > Figure out viewbox and inline height/width values on the HTML so no layout jank (aka "Cumulative Layout Shift"/CLS) occurs. Unsure if this is possible for inline math. That's a great idea, I should do that. Right now I apply the height and offsets from the SVG file (via vertical-align and height) so that it flows nicely but I should add width too. It is trivially doable since the SVG does contain the width. e.g. <img src="//daniel.lawrence.lu/texcache/683524188b1547a2a4466541ff07f2d6f83f599bi.svg" alt="\mathbf R(\mathbf T)" style="vertical-align: -0.838ex;height:2.843ex;">
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
  - hegemon8 4y ago
    Did you open-source the source code for trie DS visualization in your Aho-Corasick string matching algorithm blog?
    - dllu 4y ago
      Feel free to right click and view source and use it for whatever. I'll release it on Github with an MIT license when I get to my computer later...
jscholes 4y ago
> I'm sure they had their reasons They do, accessibility being one of them. Rendering math in the way you describe makes it difficult, or impossible, to understand for all sorts of audiences, including those relying on screen reading software.
- j-james 4y ago
  KaTeX includes hidden MathML for screen readers. https://github.com/KaTeX/KaTeX/issues/38 https://github.com/KaTeX/KaTeX/issues/38
qumpis 4y ago
I'm so happy that I can just paste my definitions from latex preamble into a paragraph to include all the calitographic symbols and other conveniences with Mathjax. As far as I know, I can't easily do it without adapting to Katex-specific syntax.
runarberg 4y ago
The last I knew, KaTeX had issues with accessibility. But honestly it is probably just best to ship raw MathML, translated from LaTeX on the server, and use MathJax as a polyfill for Chrome and Edge users. That way you get extremely fast rendering in Safari and Firefox without any extra javascript, and eventually Chrome will catch up.
- mk12 4y ago
  I wouldn’t recommend relying on Safari MathML rendering today for anything but very basic equations. Firefox is a lot better, but still not quite at MathJax quality. I made a demo here https://mk12.github.io/web-math-demo/ https://mk12.github.io/web-math-demo/ that lets you compare them. Also if you edit the MathML markup box, it will render directly from that, just like the poly fill (sometimes the layout shifts slightly when switching from TeX -> MathJax HTML+CSS to TeX -> MathML -> MathJax HTML+CSS).
  - runarberg 4y ago
    Nice demo. I don’t have access to a mac so I can’t see this in Safari, but using Firefox I can immediately spot there are some kerning mistakes in the MathML rendering which are not present in MathJax rendering. However, isn’t that just the fact the the default math font (DejaVu Math TeX Gyre in Firefox i-on Ubuntu) is not good enough? I use Libertinus Math in my own little demo page (https://runarberg.github.io/mathup/ https://runarberg.github.io/mathup/) and it looks just fine (IMO). The only think to note is that TeX Gyre is so pervasive (as it is the default [only?] MathJax font) that it takes a bit getting used to other math fonts on the web. For example here is the Iglalia example from your demo page displayed with Libertinus Math in Firfox (https://imgur.com/q3QuJOA https://imgur.com/q3QuJOA). The same example has some issues in your demo page with DejaVu Math TeX Gyre
sytse 4y ago
Our GitLab docs state "Math written in LaTeX syntax is rendered with KaTeX" https://docs.gitlab.com/ee/user/markdown.html https://docs.gitlab.com/ee/user/markdown.html but I'm not sure it isn't just using MathJax under the hood.
mk12 4y ago
I used to think KaTeX was far superior to MathJax but now I'm not so sure. I made https://mk12.github.io/web-math-demo/ https://mk12.github.io/web-math-demo/ to compare them and other things. They're definitely superior to browser MathML rendering today, which is nonexistent in Chrome (though see https://mathml.igalia.com/ https://mathml.igalia.com/), quite bad in Safari, and OK in Firefox. It's true pre-rendering KaTeX produces a lot of markup, but it compresses very well so I don't think it's a big deal. They both have MathML for accessibility, but MathJax is more flexible in letting the user right-click and change the rendering engine, view raw TeX, etc. Rendering KaTeX on the client side is faster than MathJax, but in my experience KaTeX is slightly worse quality, e.g. https://github.com/KaTeX/KaTeX/issues/3400 https://github.com/KaTeX/KaTeX/issues/3400 has gone unfixed for a long time.
- williamstein 4y ago
  There's currently around 100 LaTeX functions listed as "Not supported" in the Katex docs at https://katex.org/docs/support_table.html https://katex.org/docs/support_table.html I've been trying hard for a while with my site (https://cocalc.com https://cocalc.com) to use only katex, but that's definitely never going to happen. Users frequently hit missing functionality, e.g., they have lots of notebooks that use "\mbox", so it's critical to support full mathjax. I currently do this by attempting to use katex, then falling back to mathjax if it fails. That said, as you point out, mathjax has massively improved over the last few years with mathjax3! Thanks for pointing out the quality issues, which I hadn't thought about.
- fastball 4y ago
  > https://github.com/KaTeX/KaTeX/issues/3400 https://github.com/KaTeX/KaTeX/issues/3400 has gone unfixed for a long time. I don't think I'd qualify an issue from the end of last year as "unfixed for a long time".
  - mk12 4y ago
    Sorry I posted the wrong issue, it’s actually a duplicate of https://github.com/KaTeX/KaTeX/issues/3168 https://github.com/KaTeX/KaTeX/issues/3168 which was filed last August. I guess it’s not that long, but it was annoying for my use of KaTeX on https://mitchellkember.com/notes4u https://mitchellkember.com/notes4u where I see it frequently. For example it affects \left\lvert\vec{b}\right\rvert which is a pretty simple piece of TeX I’d expect to render fine.
osrec 4y ago
If I was building this feature, I'd also pick client side rendering, simply because at GitHub's scale, rendering on the server side will require a bunch of servers, which will need to be managed and looked after. By offloading the rendering to the client, you make use of the spare capacity that exists on most client machines today, with no noticable slowdown for the user (it may even end up doing the "first paint" faster in the browser if GitHub are careful about their implementation). Even with my SaaS product, we try and do as much work on the client as possible to reduce our server requirements. If you're sensible about it, users don't even notice.
- Gelitio 4y ago
  I would probably pretender it. Why? Because markdown files seldom change and probably read much more often. Anyway I would not agree that it is a good idea to move everything to client just because you can. There are always up and downsides. I think your comment is too generic.
- civilized 4y ago
  Historically client-side rendering has been a big headache. Not sure if it's improved recently, but avid math bloggers and blog readers will remember the problems of the past decade.
  - selestify 4y ago
    As someone with no experience in the area, what have been the problems of the past decade?
    - civilized 4y ago
      I don't know why, but the rendering just wasn't that reliable. Equations failed to render too frequently.
- lelandfe 4y ago
  The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 https://imgur.com/a/y47haf9. Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win. You're right on the money with the server costs though.
ThinBold 4y ago
Maths don't scale up. Moore's Law will catch up and eventually rendering math will be like rendering jpg. For now the priority is to get things to work so we don't waste extra time determining if we just avoid math or we use stupid PNG.
barnabee 4y ago
Everything else on a web page is rendered client side (HTML is just text…) so client side rendering makes sense to me here too.
- xigoi 4y ago
  Rendering HTML doesn't require a huge JS library.
  - barnabee 4y ago
    HTML requires a huge browser binary though, and the JS library should be cached on first visit to a page that uses it. Seems the right trade off to me to have a one off download for this use case (i.e. potentially viewing many pages on the same site, as opposed to a small number of pre rendered pages) then only need to transfer plain text which is already in the markdown source (so is needed if you’re going to edit or view the raw MD anyway).

powersnail 4y ago

MathJax can do server side rendering too now!

joppy 4y ago

For pages with lots of mathematics markup, it is far better (in terms of download size) to send the latex markup and the katex library to the browser, and render it there. I tried rendering the mathematics server-side using katex on my own website a while ago, and the div soup generated by katex takes up loads of space. Original page (compressed): 10 kB Page with server-rendered Katex (compressed): 50 kB Katex.js (compressed): 80 kB So after two pages it’s a net win to not render the mathematics server-side.

dllu 4y ago
For my blog (e.g. https://daniel.lawrence.lu/blog/y2021m09d08/ https://daniel.lawrence.lu/blog/y2021m09d08/ with tons of math), I render the math serverside using MathJax and serve them as SVG images (with alt text for the visually impaired). They get cached too which is nice especially since many symbols are duplicated. Seems fast enough for me.
- lelandfe 4y ago
  You're being modest. This is easily the most performant option... although it means losing interactivity (right clicking equations on GitHub allows copy to clipboard, A11y features, etc). Running the JS client side, like GitHub, means blocking the thread. You're either going to be 1. delaying other JS from running, or 2. rendering late, shifting the layout – which is what GitHub has chosen: https://imgur.com/a/y47haf9 https://imgur.com/a/y47haf9 (Sending the rendered div's is a non-starter. Large document sizes delay domContentLoaded, slow down browsers, aren't shared cacheable resources, etc.) Your approach, then. On your page there are 178 SVGs. Total gzipped size is 490KB. SVGO[0] gets that down to 311KB – that's 1.74KB transferred per equation. These are non-blocking, immutable, cacheable assets. Brilliant. Upgrades: - Figure out viewbox and inline height/width values on the HTML so no layout jank (aka "Cumulative Layout Shift"/CLS) occurs. Unsure if this is possible for inline math. - Add `loading="lazy"` afterwards. Users that don't scroll the entire length of the page won't suffer unneeded downloads, and the inlined sizes will prevent late CLS for those that do. - Maybe re-add interactivity? Cheap option: just support copying alt-text in a context menu. [0] https://github.com/svg/svgo https://github.com/svg/svgo
  - dllu 4y ago
    > Figure out viewbox and inline height/width values on the HTML so no layout jank (aka "Cumulative Layout Shift"/CLS) occurs. Unsure if this is possible for inline math. That's a great idea, I should do that. Right now I apply the height and offsets from the SVG file (via vertical-align and height) so that it flows nicely but I should add width too. It is trivially doable since the SVG does contain the width. e.g. <img src="//daniel.lawrence.lu/texcache/683524188b1547a2a4466541ff07f2d6f83f599bi.svg" alt="\mathbf R(\mathbf T)" style="vertical-align: -0.838ex;height:2.843ex;">
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
- hegemon8 4y ago
  Did you open-source the source code for trie DS visualization in your Aho-Corasick string matching algorithm blog?
  - dllu 4y ago
    Feel free to right click and view source and use it for whatever. I'll release it on Github with an MIT license when I get to my computer later...

jscholes 4y ago

> I'm sure they had their reasons They do, accessibility being one of them. Rendering math in the way you describe makes it difficult, or impossible, to understand for all sorts of audiences, including those relying on screen reading software.

j-james 4y ago
KaTeX includes hidden MathML for screen readers. https://github.com/KaTeX/KaTeX/issues/38 https://github.com/KaTeX/KaTeX/issues/38

qumpis 4y ago

I'm so happy that I can just paste my definitions from latex preamble into a paragraph to include all the calitographic symbols and other conveniences with Mathjax. As far as I know, I can't easily do it without adapting to Katex-specific syntax.

runarberg 4y ago

The last I knew, KaTeX had issues with accessibility. But honestly it is probably just best to ship raw MathML, translated from LaTeX on the server, and use MathJax as a polyfill for Chrome and Edge users. That way you get extremely fast rendering in Safari and Firefox without any extra javascript, and eventually Chrome will catch up.

mk12 4y ago
I wouldn’t recommend relying on Safari MathML rendering today for anything but very basic equations. Firefox is a lot better, but still not quite at MathJax quality. I made a demo here https://mk12.github.io/web-math-demo/ https://mk12.github.io/web-math-demo/ that lets you compare them. Also if you edit the MathML markup box, it will render directly from that, just like the poly fill (sometimes the layout shifts slightly when switching from TeX -> MathJax HTML+CSS to TeX -> MathML -> MathJax HTML+CSS).
- runarberg 4y ago
  Nice demo. I don’t have access to a mac so I can’t see this in Safari, but using Firefox I can immediately spot there are some kerning mistakes in the MathML rendering which are not present in MathJax rendering. However, isn’t that just the fact the the default math font (DejaVu Math TeX Gyre in Firefox i-on Ubuntu) is not good enough? I use Libertinus Math in my own little demo page (https://runarberg.github.io/mathup/ https://runarberg.github.io/mathup/) and it looks just fine (IMO). The only think to note is that TeX Gyre is so pervasive (as it is the default [only?] MathJax font) that it takes a bit getting used to other math fonts on the web. For example here is the Iglalia example from your demo page displayed with Libertinus Math in Firfox (https://imgur.com/q3QuJOA https://imgur.com/q3QuJOA). The same example has some issues in your demo page with DejaVu Math TeX Gyre

sytse 4y ago

Our GitLab docs state "Math written in LaTeX syntax is rendered with KaTeX" https://docs.gitlab.com/ee/user/markdown.html https://docs.gitlab.com/ee/user/markdown.html but I'm not sure it isn't just using MathJax under the hood.

mk12 4y ago

I used to think KaTeX was far superior to MathJax but now I'm not so sure. I made https://mk12.github.io/web-math-demo/ https://mk12.github.io/web-math-demo/ to compare them and other things. They're definitely superior to browser MathML rendering today, which is nonexistent in Chrome (though see https://mathml.igalia.com/ https://mathml.igalia.com/), quite bad in Safari, and OK in Firefox. It's true pre-rendering KaTeX produces a lot of markup, but it compresses very well so I don't think it's a big deal. They both have MathML for accessibility, but MathJax is more flexible in letting the user right-click and change the rendering engine, view raw TeX, etc. Rendering KaTeX on the client side is faster than MathJax, but in my experience KaTeX is slightly worse quality, e.g. https://github.com/KaTeX/KaTeX/issues/3400 https://github.com/KaTeX/KaTeX/issues/3400 has gone unfixed for a long time.

williamstein 4y ago
There's currently around 100 LaTeX functions listed as "Not supported" in the Katex docs at https://katex.org/docs/support_table.html https://katex.org/docs/support_table.html I've been trying hard for a while with my site (https://cocalc.com https://cocalc.com) to use only katex, but that's definitely never going to happen. Users frequently hit missing functionality, e.g., they have lots of notebooks that use "\mbox", so it's critical to support full mathjax. I currently do this by attempting to use katex, then falling back to mathjax if it fails. That said, as you point out, mathjax has massively improved over the last few years with mathjax3! Thanks for pointing out the quality issues, which I hadn't thought about.
fastball 4y ago
> https://github.com/KaTeX/KaTeX/issues/3400 https://github.com/KaTeX/KaTeX/issues/3400 has gone unfixed for a long time. I don't think I'd qualify an issue from the end of last year as "unfixed for a long time".
- mk12 4y ago
  Sorry I posted the wrong issue, it’s actually a duplicate of https://github.com/KaTeX/KaTeX/issues/3168 https://github.com/KaTeX/KaTeX/issues/3168 which was filed last August. I guess it’s not that long, but it was annoying for my use of KaTeX on https://mitchellkember.com/notes4u https://mitchellkember.com/notes4u where I see it frequently. For example it affects \left\lvert\vec{b}\right\rvert which is a pretty simple piece of TeX I’d expect to render fine.

osrec 4y ago

If I was building this feature, I'd also pick client side rendering, simply because at GitHub's scale, rendering on the server side will require a bunch of servers, which will need to be managed and looked after. By offloading the rendering to the client, you make use of the spare capacity that exists on most client machines today, with no noticable slowdown for the user (it may even end up doing the "first paint" faster in the browser if GitHub are careful about their implementation). Even with my SaaS product, we try and do as much work on the client as possible to reduce our server requirements. If you're sensible about it, users don't even notice.

Gelitio 4y ago
I would probably pretender it. Why? Because markdown files seldom change and probably read much more often. Anyway I would not agree that it is a good idea to move everything to client just because you can. There are always up and downsides. I think your comment is too generic.
civilized 4y ago
Historically client-side rendering has been a big headache. Not sure if it's improved recently, but avid math bloggers and blog readers will remember the problems of the past decade.
- selestify 4y ago
  As someone with no experience in the area, what have been the problems of the past decade?
  - civilized 4y ago
    I don't know why, but the rendering just wasn't that reliable. Equations failed to render too frequently.
lelandfe 4y ago
The tradeoff is exactly noticeable slowdown: https://imgur.com/a/y47haf9 https://imgur.com/a/y47haf9. Browser JS engines are single threaded, so MathJax has to wait its turn behind more important scripts, and it gets worse with slower devices and networks. It's a contest of download vs execution time, which a 2KB pre-rendered image will always win. You're right on the money with the server costs though.

ThinBold 4y ago

Maths don't scale up. Moore's Law will catch up and eventually rendering math will be like rendering jpg. For now the priority is to get things to work so we don't waste extra time determining if we just avoid math or we use stupid PNG.

barnabee 4y ago

Everything else on a web page is rendered client side (HTML is just text…) so client side rendering makes sense to me here too.

xigoi 4y ago
Rendering HTML doesn't require a huge JS library.
- barnabee 4y ago
  HTML requires a huge browser binary though, and the JS library should be cached on first visit to a page that uses it. Seems the right trade off to me to have a one off download for this use case (i.e. potentially viewing many pages on the same site, as opposed to a small number of pre rendered pages) then only need to transfer plain text which is already in the markdown source (so is needed if you’re going to edit or view the raw MD anyway).