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
Problems with math rendering on the web (2020)
71–80 of 87 posts
Re: Problems with math rendering on the web (2020)
#72The "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…
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…
Re: Problems with math rendering on the web (2020)
#74Ha! 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.
Re: Problems with math rendering on the web (2020)
#75The "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…
Re: Problems with math rendering on the web (2020)
#76The 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.
Re: Problems with math rendering on the web (2020)
#77> ...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…
Re: Problems with math rendering on the web (2020)
#78Earlier 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?
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…
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…
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.