Last modified: 2014-06-13 12:40:34 UTC
A fourth rendering option "PNG+MathJax" could be interesting: Output a rendered PNG but replace it by pure HTML with MathJax. This would have several advantages: * Users with incompatible browsers will see the rendered formula. (At least when MathJax is configured properly.) * Users with disabled JavaScript will see the rendered formula. * The rendered formula is visible as soon as the image is downloaded which is usually faster then MathJax' rendering for pages with many formulas. Because of the first two points this option could even be used as default. The only disadvantage I can see is the fact that both the images and the JavaScript have to be downloaded, but since the JavaScript can be cached this shouldn't be a big problem. If you decide to close this bug as WONTFIX, then remove the code to extract the TeX from an image in MathJax/extensions/wiki2jax.js.
Oppose. MathJax is supported by all modern browser and most ancient ones. There's no need to waste bandwidth sending a PNG to every new request, force the browser to render said PNG, and then re-render MathJax over it. There's already a noticeable lag in rendering MathJax, and there's no need to make it worse.
(In reply to comment #1) > MathJax is supported by all modern browser and most ancient ones. This is not true for users who disabled JavaScript. Additionally the data on http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm suggests that on WMF projects more than 2% of all page views come from users with unsupported browsers. When the PNG is included in <noscript>-tags users with enabled JS wouldn't have to download the image.
>>2% >there's lots of data on that page. I have no idea which one you refer to. And that's what I said. But your proposal described a scenario where PNG's are sent to all browsers. Images shouldn't be sent at all to capable browsers (it sounds like ~98% are). This option could better be described as "MathJax with fallback PNG support," and that should probably be the default option anyway. It's too bad MathJax is so slow, the pre-render look is so ugly.
As an observer, I would like to add a few points. First, it's very easy to test this, just modify http://stackoverflow.com/questions/14610821/apply-mathjax-to-arbitrary-elements/14631703#14631703 to look for "tex" classes. With this you could actually compare timing. A quick (unrepresentative) look tells me that equation images vary between 200byte (single characters) and 1.5kb (decently sized arrays). I'm guessing an average Wikipedia page is in the hundreds kb; an average MathJax download will also be in the hundreds kb (most of it coming in asynchronously depending on the content and the user's browser cache). I don't know what the average equation load is (10kb? 50kb?), but I suspect there's little to loose for the user: with few equations, the load won't make a blip, with many you might really want the images first since MathJax rendering (not downloading) is the real delay. Personally, I find the user experience very pleasing when images silently turn into HTML.
I suspect that, when MathJax's issue 301 is fixed and Web fonts can be used in native MathML output, many Firefox users will prefer to use the MathML output than the much slower HTML-CSS or PNG options. This is even more true if they already have the math fonts installed on their system. Hence, having the PNG fallback before the MathML output will just be a performance loss for Firefox users.
Can't disagree with you there. But isn't Wikipedia producing TeX (not MathML)? If so, the user experience would still depend on MathJax downloading, converting (though not rendering). Much harder to guess which experience would be better. And images in no-script tags would still be sensible.
I guess in an ideal world (when all browsers, accessibility tools etc support MathML), a server side conversion (like LaTeXML) would be used. For now, the following MathJax-based approach would be better: 1) make Wikipedia produce images in no-script tags. If Javascript is not available, then these images will be visible and 2) and 3) not executed. 2) the MathJax pre-processor (the fast part) will parse the TeX in the alt text into MathJax's internal math. If NativeMML is not used then move the images outside the no-scripts too. 3) the MathJax output Jax will then display each equation. For NativeMML, this will be very fast. For SVG/HTML-CSS, the user will see the PNG images until they can be rendered by MathJax. 3bis) When the Web fonts are not cached yet, the SVG/HTML-CSS will have to wait that they are available before processing, which is even more time to wait. With the NativeMML, the MathML can be displayed immediately (perhaps with other fonts or with a degraded aspect) and you only need to reflow the math elements when the Web fonts become available. This is the goal of issue 301. What does MathJax/extensions/wiki2jax.js do exactly at the moment?
Given the discussion in https://bugzilla.wikimedia.org/show_bug.cgi?id=48036 it seems that this option will be important if we want to expose the MathJax option to anonymous users. That's not ideal, but that's a first step to provide to users alternative for the PNG images. Also, given the availability of the LaTeXML mode, my comment 5 no longer holds since people who want to optimize the speed will choose that mode instead. See https://gerrit.wikimedia.org/r/#/c/83399/
We have the PNG+MathJax option now.
Is this live/scheduled to go live on WMF wikis yet?
It is already live. At least if I understood the bug message correctly. On the user preference page there is a section called Math . Below there are two options 1) Always render PNG 2) Leave it as TeX (for text browsers) (unfortunately 2) is currently broken) and there is a check box -MathJax (experimental; best for most browsers) If you enable the check box and mode 1. You see PNG images that are replaced with the MathJax rendering one the page was loaded completely.
