Live data from Hacker News

Problems with math rendering on the web (2020)

danilafe.com

71–80 of 87 posts

Re: Problems with math rendering on the web (2020)

#71
We already have two standardized ways to write math equations: MathML and TeX-like notation. The former is the formal standard, the second is what is overwhelmingly used.

It would be great if we could have both natively in the browser, and maybe support for math equations as a system level feature of editors everywhere. But the vomiting-green face-woman emoji gets more money than math equations these days

Re: Problems with math rendering on the web (2020)

#72
post #31

The "server-side rendering" aspect of KaTeX is (and always has been, as far as I'm aware) front-and-centre on their landing page [1]. It allows you to input LaTeX and output HTML ready for inclusion server-side - the only thing this HTML needs to support it is the KaTeX CSS. This is very easy to do if your web server or static site generator is running on Node, and only a bit more difficult if it's running on somethi…

Well I hope that you took efforts to avoid the other nasty side effect of client side rendering at least: page content jumping all over the place when the page reloads and the scrollbar not initializing at the right location (so cross page anchors are useless).

I personally solved that problem by stuffing the equation into a separate vue component and putting the katex compilation into the render function. Indeed, a dedicated equation HTML tag supporting latex (with what packages though?) would be nice. Getting the equation numbering to work nicely in an automatic fashion was a bit annoying though. I appreciate your comment on the page size, since I was considering moving to server side rendering via nuxt and hadn't made this consideration.

Re: Problems with math rendering on the web (2020)

#73

> ...they use client-side rendering for static content. In my opinion, this is absurd. Rendering equations client-side doesn't seem absurd to me. All of HTML and CSS and SVG is rendered client-side, why shouldn't equations be too? I'm completely unclear why the author thinks equations specifically should be rendered server-side. Do they think HTML pages should be delivered as prerendered images or SVG's too...? Becau…

You’re misunderstanding what “client-side rendering” means. It’s not about rendering to images, it’s about rendering to HTML/CSS/SVG/whatever. “Client-side rendering” means that what is served contains something not in the eventual form you desire to present it, and that it depends on some client-side scripting to convert it into the desired form. When the page loads, it will first show perhaps nothing or perhaps som…

But does this actually work well for layout? i.e. if you generate HTML/CSS output from math formulas server-side, will it correctly (from the math typography perspective) reflow if the viewport is resized etc?

Re: Problems with math rendering on the web (2020)

#74
post #8

Ha! I used to get pretty pissed-off when I was doing my online math homework, only to find that you couldn't copy/paste the equations into Google. I always thought it was a prevention mechanism, but I guess it was a matter of the technology not being ready yet.

Unicode doesn't have many math symbols so you can't copy and paste them like text because they aren't just text. There are textural representations though which can be copied. They just look ugly.

?Barbara Beeton and others have put a good deal of effort into making Unicode and math work together. http://www.unicode.org/reports/tr25/tr25-15.pdf

Re: Problems with math rendering on the web (2020)

#75
post #31

The "server-side rendering" aspect of KaTeX is (and always has been, as far as I'm aware) front-and-centre on their landing page [1]. It allows you to input LaTeX and output HTML ready for inclusion server-side - the only thing this HTML needs to support it is the KaTeX CSS. This is very easy to do if your web server or static site generator is running on Node, and only a bit more difficult if it's running on somethi…

Well I hope that you took efforts to avoid the other nasty side effect of client side rendering at least: page content jumping all over the place when the page reloads and the scrollbar not initializing at the right location (so cross page anchors are useless). I personally solved that problem by stuffing the equation into a separate vue component and putting the katex compilation into the render function. Indeed, a…

I've not used Vue, but how does this solve the problem? In most of my own sites, whatever preprocessor (eg markdown -> html) I use is instructed to replace mathematics with something like z = \frac{x}{y}, then after the page has loaded a small loop runs KaTeX on all eligible spans. This results in some small amount of jumping, but I've found anchors to still work quite well.

Re: Problems with math rendering on the web (2020)

#76

The state of maths on the web, as someone who uses a lot of maths on their website[1] is to recognise that loading times on the web shouldn't exist, and you should just turn your formulae into images that you load using `loading="lazy"`. And of course, to make sure they fit any resolution: generate SVG images. And no, MathML is irrelevant: you don't care about MathML, and your users don't care about MathML: all you c…

> Nothing is mining the web for maths, and semantic markup for maths buys you nothing. I find that rather unfortunate. A math search engine that find sites with equivalent formulae (or segments) would be quite useful to me. Of course, that can probably made to work with image alt tags containing latex code.

Semantic MathML is an absurdity, like marking up the tree diagram of all your English sentences, and linking all words to a URL with their dictionary definition. In short, the sort of think only the semweb wonks could have dreamed up.

Re: Problems with math rendering on the web (2020)

#77
post #44

> ...they use client-side rendering for static content. In my opinion, this is absurd. Rendering equations client-side doesn't seem absurd to me. All of HTML and CSS and SVG is rendered client-side, why shouldn't equations be too? I'm completely unclear why the author thinks equations specifically should be rendered server-side. Do they think HTML pages should be delivered as prerendered images or SVG's too...? Becau…

Yeah that is my take as well, and I'm rather perplexed at what the author would like server-side rendering to output given they don't like PNG and SVG either. HTML and CSS weren't designed with math in mind, and while you can force them to do the job (like KaTeX), the result is sub-optimal. It looks fine, but it requires you to transmit orders of magnitude more data, which isn't very suitable to accessibility softwar…

Its not good for users to be stuck on a blank screen while waiting for everything to load.

Re: Problems with math rendering on the web (2020)

#78
post #73

Earlier quoted context omitted.

You’re misunderstanding what “client-side rendering” means. It’s not about rendering to images, it’s about rendering to HTML/CSS/SVG/whatever. “Client-side rendering” means that what is served contains something not in the eventual form you desire to present it, and that it depends on some client-side scripting to convert it into the desired form. When the page loads, it will first show perhaps nothing or perhaps som…

But does this actually work well for layout? i.e. if you generate HTML/CSS output from math formulas server-side, will it correctly (from the math typography perspective) reflow if the viewport is resized etc?

I don’t know whether MathJax/KaTeX do anything special about wrapping. They could hard-code the lot, they could use markup and styles that will leave the browser to handle wrapping, or they could do active reflow where they adjust the DOM depending on the available space. But server-side rendering is still feasible and desirable even in that last case: you render to some baseline markup that will work in all cases but perhaps not have ideal layout, and then add a bit of optional JavaScript to reflow and optimise the layout. Ideally you separate the mathematical markup rendering from the reflow completely, so that you can ship much less JavaScript (more targeted and faster JavaScript, at that).

Re: Problems with math rendering on the web (2020)

#79

> they use client-side rendering for static content. In my opinion, this is absurd I'm not a mathematician but what's the problem with client side rendering - I just about only write equations in jupyter notebooks, the syntax isn't great but it seems to work perfectly and scales to the resolution required. Math rendering is far from the most complex thing being rendered on the front end. https://jupyter-notebook.read…

It tends to mess with anchor links, as the browser will scroll to the appropriate heading which gets pushed down as rendered content takes up vertical space.

Re: Problems with math rendering on the web (2020)

#80

> ...they use client-side rendering for static content. In my opinion, this is absurd. Rendering equations client-side doesn't seem absurd to me. All of HTML and CSS and SVG is rendered client-side, why shouldn't equations be too? I'm completely unclear why the author thinks equations specifically should be rendered server-side. Do they think HTML pages should be delivered as prerendered images or SVG's too...? Becau…

You’re misunderstanding what “client-side rendering” means. It’s not about rendering to images, it’s about rendering to HTML/CSS/SVG/whatever. “Client-side rendering” means that what is served contains something not in the eventual form you desire to present it, and that it depends on some client-side scripting to convert it into the desired form. When the page loads, it will first show perhaps nothing or perhaps som…

I know it's rendering to HTML/SVG whatever, but I still think that belongs client-side.

It's better to do it on the client because it's generally better to send less information over the wire, as well as send information in its most unprocessed form.

This applies, for example, to charts as well -- far better to send the raw data series values to the client and render it on the client-side with a charting library.

Both of these cases have the huge advantage that if you want to use the equation or data yourself, you can just "view source" or "inspect" and grab the equation or data directly to copy.

I don't think we need to be too concerned about the fact there's a slight delay in rendering equations. People are pretty used to browsers loading everything gradually, whether waiting for images to be the last thing to appear, or even lazy loading of images. There's nothing wrong with that.

Post reply on HN