# When will we get latex mathematics support (i.e., MathJax)?

UPDATE: As of April 26th, we now have MathJax Support on this site.

Hopefully, if this going to be a scientific site, answers will often require presentation of mathematical equations. I think it would be good if the site supported latex mathematics in the same way that maths.se and stats.se support mathematics. For example, in this answer I wanted to present a mathematical equation for the learning curve. On Stats.se, I'd just write $a + b = c$ and it would be rendered as a mathematical equation.

I found this discussion on meta.stats.se where stats.se seemed to organise math support.

I realise that the MathJax plugin is considered "heavy", but I think in the case of a site on cognitive science, the benefits are worth it.

### Questions

• Do others desire math support for the site?
• How do we arrange support for it?

### Incomplete list of questions that could benefit from MathJax Support

-
thank you for editing this question back to the top. Should we make another question not seeing if we need the feature, but specifically saying "we want, please give"? I feel like this question makes a good case for why we need MathJax and I can't think of an argument AGAINST having MathJax. –  Artem Kaznatcheev Mar 28 '12 at 15:51
@ArtemKaznatcheev That might be an idea. I've put in a request once by email to a contact at Stack Exchange, and they said they'd see what they could do. But I'll send a reminder. –  Jeromy Anglim Apr 2 '12 at 5:08

Mathjax has been enabled on cogsci. If you find any issues please report them here on meta.

-
Thanks Geoff! I'll keep a close eye out for anyone complaining of issues. –  Josh Gitlin Apr 25 '12 at 20:58
That's fantastic. I'll be sure to go over some old questions and answers and add some mathematics. –  Jeromy Anglim Apr 26 '12 at 0:11

I have seen this question asked on a number of StackExchange sites, and the answer is invariably that it would impose too high a burden on the pages that don't use MathJax. I think this response may be based on a misunderstanding of how MathJax works, and stems from an early comment from Jeff Atwood where he incorrectly stated that MathJax would require downloads of more than 500KB, which is off by an order of magnitude, as I show below.

One thing that contributes to this misunderstanding is that MathJax loads components only when needed, and so there is a big difference between what is loaded on a page without mathematics from one that does include mathematics. The size of that difference depends on how MathJax is configured (and so on how many components are pre-loaded versus loaded on demand).

On a page with no mathematics where MathJax is loaded, MathJax requires two files: MathJax.js itself and a configuration file. If taken from the MathJax CDN, the file will be shipped in compressed form, and the actual data transfered for MathJax.js will be about 14.4KB. For comparison, the background image for this site (http://cdn.sstatic.net/betameta/img/bg-noise.png) is 12.3KB, and the sprite image (http://cdn.sstatic.net/betameta/img/sprites.png?v=3) that holds the various button imagery is 16.5KB. So MathJax.js can be included in a page with little more cost than the background image, and less then the other button images.

The configuration file can vary greatly in size depending on what is included. For example, the configuration used at math.stackexchange.com (which includes most of the components that MathJax will load for processing TeX commands) comes in at about 40.5KB, for a grand total of 55KB for every page on MSE. Note that that is about a tenth of Jeff's claim.

Now the configuration file used at MSE contains more of the MathJax code than you might want to preload on a site that doesn't have that much math. Another reasonable configuration would come in at 25KB (leaving out the code that actually processes TeX commands to be loaded on demand when math actually appears). This still includes much of MathJax's code that is needed common to all its input and output processors. Leaving that out and having a truly minimal configuration that just has enough to define the input and output processors and search for TeX code on the page, you could get a configuration file that is only 3.7KB.

So it is possible to include MathJax on every page with as little as 18KB, or just over the size of the button images on this page. That can range up to 55KB, with the decision about how much to include being based on how much math you expect to have on your site.

Just as a comparison, here are some other scripts that are included on this page already (these are the compressed numbers, so are actual network transfer amounts; the uncompressed files are larger):

• jQuery 32.7KB (a javascript library for interacting with the DOM)
• wmd.js 48.7KB (the markdown editor for creating answers)
• full.js 78.9KB (I presume this is the main code for running the site)
• stubs.js 19.0KB (not sure what this one is)
• all.css 109.3KB (the CSS controlling the look of the site)

In total, along with the two image files I already mentioned, these are over 330KB of data. It seems a little disingenuous to call MathJax the "great white whale", as Jeff did, when it is possible to bring it in at 18KB, while the CSS file for this site is over 100KB all by itself. Even at 55KB for a reasonably fully preloaded version of MathJax, that is comparable to the editor that is part of SE already, and much less than "full.js", whatever that is.

Of course, this is for pages without mathematics, but I'm making this distinction because the claim has always been that the MathJax dependency is too great for pages that don't include math. I don't think you can really say that about 18KB (or even 55KB).

For a page that does include mathematics, MathJax would need to load more code, so pages with math do have a heavier footprint. For a typical page in math.stackechange.com that does include mathematics, MathJax has to load about 48KB more (it depends on what the math actually is). That is about 100KB total (and had they used the 18KB configuration instead, that would have translated into about 80KB needed extra for a page with mathematics). For users who don't have the STIX fonts, the web fonts would be used, and that is additional download on pages that have mathematics (again, dependent on what the mathematics includes, but usually around 80KB). So it is true that pages with math are heavy, by even at 200KB total for MathJax and its fonts, it is still not the 500KB that were claimed.

For pages without math, 18KB to 55KB seems perfectly doable, especially when the page is already at over 330KB. This is one myth about MathJax that seems to be prevalent in the StackExchange community, and I hope that we are able to finally put it to rest. Since StackExchange is a MathJax partner, I'd be happy to help put together the proper configuration file (or files) to make MathJax more readily available on SE sites.

-
Not to be argumentative, but the comment was from over a year ago, from version 1.0 of MathJax which was much heavier. Painting that comment as a lie rather than out of date (which it is) is disingenuous - that answer simply needs updating. Also, it's a matter of perceived performance, keep in mind that we defer JS loading so of all the items listed, only all.css is actually needed to affect the page looking fully loaded. In the view of "what needs loading before the page is fully rendered correctly?", it's a much larger percentage (and HTTP connection count). –  Nick Craver Apr 5 '12 at 2:03
To be clear: I'm not saying we shouldn't use MathJax, quite the contrary - it greatly enhances all the sites that benefit from it. Also, I'm not saying it's as heavy as most perceive; it certainly isn't and you've made huge improvements there as well. My only point is a simple size % isn't the only number that matters, load, rendering, and reflow order come into play here and there is a perceivable cost on that front (more so in the fresh-from-google cold-cache case). Because of that, we have to weigh that cost vs. benefit to the community for any JavaScript we add. –  Nick Craver Apr 5 '12 at 2:21
I'm sorry if I was offensive; I didn't mean to come off that way, and I didn't mean to call Jeff's comment a lie, I mean to call it a misunderstanding (not an intentional misleading). It's true that it was about v1.0, but that worked essentially the same way (though it involved more files, but smaller ones), so it also could have worked with small downloads on pages without MathJax, and there was never a requirement that every page loads 500KB. Again, the distinction between pages with math and those without math is important, here. –  Davide Cervone Apr 5 '12 at 11:12
In terms of reflow, load order and so on, I agree with you the the perception is what really counts. For a site with little math on it, MathJax can be configured to wait until the rest of the page is loaded before it loads its configuration or other files, and so the up-front cost would be 14.4KB (the size of the background image). For pages without math, there would be no reflow issues, and no rerendering. So the impact would be that of an additional image being loaded. Not completely negligible, but not as disruptive as seems to be the claim. –  Davide Cervone Apr 5 '12 at 11:19
that's the tradeoff we have to weigh, if it benefits the community greatly, that reflow delay/jump cost (the most perceivable) is absolutely worth it for the math content benefits. It's a matter of the performance loss (whatever the size/cost) for any library vs. the better content the community can generate with it. If it'll be used in cases where it adds value to the question/answer, it's worth it...if it's often used not in those cases, then we're paying a performance cost with little content benefit which isn't a better experience...I think that's the discussion. –  Nick Craver Apr 5 '12 at 11:26
Of course, pages with math are a different story, and there reflow and re-rendering will occur for those, along with loading of more javascript. So that will have a much larger hit both in load times and wait before the page is fully viewable. And reducing the effect on pages without math is paid for by an increased effect on those with math. That certainly is something to consider and you are right to do so. My main point was that the effect on non-math pages could be small (whereas the argument usually is that it is prohibitive). –  Davide Cervone Apr 5 '12 at 11:27
I guess the real question then is will it be used often where is doesn't add value (i.e., will it will be abused)? I guess I'm not competent to answer that, and it would depend on the community involved. But that seems to me to be different from the question of whether there are places it does add value. What I mostly am reacting to is statements like "the MathJax scripts will be included [on every page], and they are not small". –  Davide Cervone Apr 5 '12 at 11:38
I don't mean to come off sounding like I am complaining about SE. I love the sites, and think you have a very interesting model that seems remarkably effective. The quality of the sites, both in terms of the experience, and in the information that you can obtain, is very high, and I am very impressed with what you have done. Keep up the good work! –  Davide Cervone Apr 5 '12 at 11:40
oh I agree, on non-math pages it's not even worth discussing, absolutely worth it. I think though that since the home page falls under the "has math" category now, it's usually the users first experience to the site that's affected. For example on stats.stackexchange.com homepage (quick test), a cold cache finish it at 836ms, then jax.js, then fontdata.js, then the fonts, finishing at 1390ms...it's the sequential nature of those requests having the biggest effect...any chance that can be improved? We load the same fonts every time, anything we can do to optimize there? –  Nick Craver Apr 5 '12 at 11:41
Good point about the home page. I usually end up at SE by way of a google search for something, so don't usually see the home page, but your regular followers will. In terms of the sequence, jax.js is the output processor (which can be set by the user) and only the HTML-CSS output jax needs fontdata.js. You are currently configured to look for local STIX fonts and then use MathJax web fonts, and the fontdata.js file is different depending on which of those is found. Let's talk off-line about those details (dpvc at union dot edu). It can probably be improved. –  Davide Cervone Apr 5 '12 at 12:06
–  moose Mar 18 '14 at 17:07

Keep an eye on the questions that need MathJax support or that attract answers that do. If you can compile a list of examples, we can see about getting MathJax support enabled for this site.

-
Okay. great. I've started a list in the question above, and will add others as they are required; I also encourage others to do the same. –  Jeromy Anglim Jan 23 '12 at 3:11

I can't edit the question to add it to the list being built, but I would have said much more about VC dimension in my answer if I could have written math.

I see no reason why we should not have MathJax, especially if we want to attract more technical questions and answers. There is no harm from having MathJax.

-
Agreed. Thanks for posting here in meta; I've added your question to the list. –  Jeromy Anglim Feb 3 '12 at 3:20
I made the question Community Wiki so anyone can edit it now. –  Josh Gitlin Feb 15 '12 at 22:12

I strongly support the introduction of MathJax to cogsci.se. If you look at any academic work that involves cognitive modelling, psychometrics, mathematical psychology, and so on, there is heavy use of equations.

Already a number of questions have been identified that could benefit from equation support. Furthermore, as the saying goes, "if you build it, they will come".

This site is striving to be a serious scientific site that supports academic discourse in the cognitive sciences. Enabling support for mathematical equations sends the right message to the academic community. It provides another compelling argument for the superiority of the site over existing discussion forum. And when an expert sees that questions are being answered with mathematical rigour, this reflects positively on the whole site.

-

Enabling MathJax supports means that on every single page on this site, the MathJax scripts will be included, and they are not small. Due to this, we want to see that MathJax is being used significantly on the site - otherwise, we are just needlessly slowing down the user experience on the site.

In the list of questions included here, I see stuff that would use MathJax in only a couple of the posts. Poking around the rest of the site, I'm seeing it used extremely minimally.

Given the extremely small use I see on the site in the current questions, I'm not sure I see the benefit in enabling MathJax.

-
I can see your concern about load times. I don't understand the technical details about load times, but this comment suggests that the additional load is not a big deal. Also, how can users demonstrate use of MathJax when MathJax is not enabled? Am I correct in assuming that we should start writing questions and answers as if MathJax was supported even though they will not be rendered correctly? –  Jeromy Anglim Apr 4 '12 at 23:23
I've added another post on meta seeking clarification on this decision. I appreciate your concern with the user experience, but I would like to better understand whether you understand the importance of mathematics support. Obviously, there's a trade-off. Would you or someone else on the StackExchange team be able to elaborate? –  Jeromy Anglim Apr 5 '12 at 7:10
–  Josh Gitlin Apr 5 '12 at 12:58
-1: You are causing a chicken-and-the-egg problem by requiring us to have math content before we have MathJax support. –  Artem Kaznatcheev Apr 5 '12 at 13:38
and if you want some eggs: look at this answer. There are probably other examples, too. –  Artem Kaznatcheev Apr 14 '12 at 22:02