Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with math rendering on the web (2020)

danilafe.com

Post reply on HN
Print view View original

61–70 of 87 posts

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

#61

Post by TheRealPomax »

rhdunn wrote: post #58
TheRealPomax wrote: post #50

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…

Accessibility? Being able to copy/paste the formulae into formula editor or solver? Being able to easily style the formula (including for dark themes)? ...

When was the last time you actually wanted to do that, rather than just wanting to hypothetically raise that possibility for the sake of an argument about web technology?

Because in reality, based on my experience at least, no one actually needs that. Folks can copy a formula that they got from an image into wolfram alpha just fine. And the folks who can't don't actually benefit from MathML: they benefit from the JS Selection and Range functions, when site owners take the time to make sure that text-selection of a formula image leads to a LaTeX formula being put in the clipboard, instead.

"That's way more work" but since we're all using build systems anyway: no it's not. Write once, thousands if not hundreds of thousands of users benefit. The end.

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

#62

Post by qubyte »

I use server rendered SVG with mathjax as part of my static site generator. To try to make it as accessible as possible I add a title element with an ID to each SVG and use an aria-labelledby attribute to connect the two [1] (a sample for the interested, scroll about half way down [2]). The title content is the unrendered LaTeX source.

I'm very interested in the notion of using HTML and CSS rendering though! Many thanks to the author for pointing out this functionality.

[1]: https://github.com/qubyte/qubyte-codes/blob/main/lib/render.... [2]: https://qubyte.codes/blog/advent-of-code-2017-day-20-task-2

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

#63

Post by johneth »

TheRealPomax wrote: post #61
rhdunn wrote: post #58

Earlier quoted context omitted.

Accessibility? Being able to copy/paste the formulae into formula editor or solver? Being able to easily style the formula (including for dark themes)? ...

When was the last time you actually wanted to do that, rather than just wanting to hypothetically raise that possibility for the sake of an argument about web technology? Because in reality, based on my experience at least, no one actually needs that. Folks can copy a formula that they got from an image into wolfram alpha just fine. And the folks who can't don't actually benefit from MathML: they benefit from the JS…

Surely MathML is better than an image for users of assistive technologies (screen readers, etc.).

That alone should be enough to favour it over just images.

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

#64

Post by mfsch »

TheRealPomax wrote: post #50

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…

I’ve come to the same conclusion, especially since I often end up using the same equations for both web and LaTeX documents, so it’s nice to have the same rendering engine everywhere, especially once you start making small tweaks to spacing etc.

One issue I’ve run into is that it’s not always that easy to get the style of the SVG images right, especially when it comes to sizing & placement. Did you find a good way to e.g. ensure that inline equations have the correct baseline alignment? Or a good method to ensure that equation sizes always match the font size of the paragraph they’re in?

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

#65

Post by pronoiac »

TheRealPomax wrote: post #50

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…

I like this! It's similar to what I did when turning formulae of an ebook from gif to something prettier and more editable. The whole book only had a dozen formulae, so manual work actually covered everything. I used the codecogs editor - https://www.codecogs.com/latex/eqneditor.php - which can emit svg and png. I got it working fine, with svg fallback, in GitHub markdown and epub.

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

#66

Post by cthor »

johneth wrote: post #63
TheRealPomax wrote: post #61

Earlier quoted context omitted.

When was the last time you actually wanted to do that, rather than just wanting to hypothetically raise that possibility for the sake of an argument about web technology? Because in reality, based on my experience at least, no one actually needs that. Folks can copy a formula that they got from an image into wolfram alpha just fine. And the folks who can't don't actually benefit from MathML: they benefit from the JS…

Surely MathML is better than an image for users of assistive technologies (screen readers, etc.). That alone should be enough to favour it over just images.

Setting the alt attribute to whatever input generated the image should cover that.

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

#67

Post by magnio »

TheRealPomax wrote: post #60
mscharrer wrote: post #59

Earlier quoted context omitted.

> 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.

What would you use it for? And that's a serious question: what would you use it for, as opposed to just using wolfram alpha or some other service that can already get you all the answers, analysis, and more, without having to mine MathML from random pages on the internet?

In the past, I used a math search engine[0] to find solutions for Olympiad problems, especially inequality ones. I imagine it would be useful when you want to find the name of some formulas or expressions that you came across, though probably not much more.

[0] My typical query: https://approach0.xyz/search/?q=OR%20content%3A%24a_%7Bn%2B1...

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

#68

Post by JustFinishedBSG »

nichos wrote: post #39

I thought adding LaTeX (or similar) to the Gemini protocol was a huge missed opportunity. It could be the standard for research and universities.

Yes, the absence of inline images (and therefore SVGs) really make Gemini completely useless for many many things, including maths.

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

#70

Post by claudiawerner »

jfim wrote: post #37
daymi wrote: post #17

This article is kinda weird--it mentions MathML in passing and then spends a large amount of time on MathJax etc. The correct fix is to have MathML natively on all browsers (no JS)--and Igalia is working on that: https://mathml.igalia.com/faq/

The worst part about the MathML debacle is that it actually used to work in Chrome a decade ago or so, but then it got removed because there was no real support for maintaining it within the Chrome team.

The Chromebook team at Google also removed the Japanese-input Dvorak layout on Chromebooks. I updated one day and the option just didn't exist any more - and I know I wasn't the only user. It's very frustrating, and I had to use some X11 shim commands to get around it until I ditched the Chromebook.
Post reply on HN