81–87 of 87 posts
Earlier quoted context omitted.
>> I implemented a TeX engine in WebAssembly so you really can run TeX in the browser. Kinda misses the point of the blog post. The idea is to do that server side, preferably only once.
You can use the same code for server-side rendering: with dvi2html, you can run TeX on a .tex file to get .dvi and then produce a static html file. This renders not just the math but also the text using TeX's layout engine, which is often not what people want. Running it in the client means the TeX knows the width of the view.
+1 for running it server side. But knowing the width of the view was never supposed to be a thing with HTML and the web. That's what the layout engine in the browser is for. Also, knowing those metrics is a bit or two of fingerprinting information that the server should never be made aware of in the first place.
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.
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.
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…
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…
One drawback to this approach is that SVG equations have a fixed layout, so e.g. they can't automatically line-wrap. Most of the equations on your Bézier page are pretty short, but I notice that you have elected to manually wrap them in some spots when they get too long, or in other cases just let them spill off to the side. This is most apparent with a narrow viewport (e.g. a phone), but you can also see this by using the responsive design mode on a desktop browser or even simply resizing the viewport. The longer equations get cut off on the right side and you have to scroll horizontally to see the whole thing, which isn't ideal. One of the benefits HTML is supposed to have over just, say, a PDF is the ability for the same document to reflow to different viewports.
The Bézier page illustrates another common issue with SVG images of equations: they have a lot of text in them, but none of it is searchable text. That means no Ctrl-F and no search engine indexing of that text. This is fixable via SVG, though, since SVG images can provide a searchable text layer. (I don't mean to single out your website, by the way, this is an issue with math all over the web. Also, selectable text is a longstanding bug in Cairo[0], which pdf2svg relies on to generate SVGs, so it's not an easy fix on your end anyway.)
> there is simply no reason to ever use it. Nothing is mining the web for maths, and semantic markup for maths buys you nothing.
MathML supports automatic linebreaking of equations. SVG doesn't. That's one simple reason to use MathML. I'm not sure whether this fits your definition of "semantic markup" or not, but it is useful. Linebreaking even has its own section in the MathML spec.[1]
It's also not true that nothing is mining the web for MathML. SearchOnMath[2], for example, indexes pages from the NIST DLMF[3], which uses MathML extensively.
[0] https://bugs.freedesktop.org/show_bug.cgi?id=38516
[1] https://www.w3.org/Math/draft-spec/chapter3.html#presm.lineb...
Earlier quoted context omitted.
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.
Getting the client javascript to render the entire page has a variety of problems, hence my desire to server side render (during a build step) what is essentially static content. If the page size bloats up too much though I might need to reconsider the approach...
I guess web components (https://developer.mozilla.org/en-US/docs/Web/Web_Components) could allow me to combine these approaches. It is already quite close to the vue programming model.