Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 24 of 24
I hope I don’t have to convince people here of the value of MathML. And I know that several people here are also on G+ so will have already read my post there about this. So I’ll keep it short here. One of the people who’s been working on MathML support in browsers has decided to spend some quality time on this and has started a crowd-funded project to try to get enough money to support the time he’d need to do this. This is not some fly-by-night programmer, this is someone who really knows the ins and outs of MathML support in browsers.
If you have any spare cash lying around, send it to this guy. The link for his project where you can read far more is http://www.ulule.com/mathematics-ebooks/.
If that is going in the direction of having more browsers display the nLab math correctly, that would be great.
I see and hear that plenty of people read the nLab with MathJax displaying its math. But that has some really bad side effects. One is that pages that are a bit longer take yet more time to display, because MathJax is chewing on them. This get’s to the point of making some nLab pages very tedious to load (such as “differential cohesion”) and for some it is such as to drive any sane user away (such as “geometry of physics”, which may take many minutes to display). Another bad effect of MathJax is that it does not display corretly for instance stacked arrows and indices on limits. Plenty of nLab pages just look broken with MathJax.
Since at the same time, it seems that MathJax is becoming the default for reading math on the web, this is really bad for the nLab.
Yes, that’s the goal.
Concerning the related thread on possible migration to gitit, also using MathML rendering, I came across the math example for gitit.
The example page, http://gitit.net/Math%20Example says
If you’re using Safari or Chrome, you may just see a jumble of symbols.
I said to myself “This is strange, MathML was working in Chrome” (it applies to Lab as well!).
Then I looked at news and indeed saw a bad news for all of us (article discussed MathJaX vs. native MathML issues!):
Google subtracts MathML from Chrome, and anger multiplies, Nov 5, 2013
Also Opera doesn’t display MathML. At least mine doesn’t.
Slightly off topic, but I recently upgraded to Safari 6.1, which various web sites claim still supports MathML, but the nLab and the Café are now displaying with MathJax for me.
Indeed, it should work in Safari according to http://caniuse.com/mathml. It seems to work for me on iOS Safari, so that’s surprising.
It turns out that MathML does work if I disable JavaScript. So it appears that Safari is inappropriately going with MathJax first.
The nLab and nForum test the browser for MathML support and send MathJaX depending on the results of the test. It may be that Safari isn’t reporting that it can handle MathML (or not in the way that the tests are expecting). I’ll look into it.
Do you happen to know if the Café works the same way? That’s where I first noticed the issue. I’ve sent a bug report to Apple as well, but it wouldn’t hurt if you can help me submit a more informative one.
@Mark You can right-click on any formula and select Math Settings > Math Renderer > MathML. This gets stored as a cookie. The first time you do this you get an alert box:
Your browser’s native MathML does not implement all the features used by MathJax, so some expressions may not render properly.
Switch the renderer anyway?
Safari 6.1+’s MathML rendering is clearly not as good as the Javascript rendering, so it may not be a bug that the latter is used as default.
@Marc: Thanks for the information. I’ve never had any problem with the MathML rendering in recent versions of Safari, whereas MathJax is painfully slow for pages with even a moderate number of formulas. Safari 6.1 seems to have introduced some new “features” that make MathML more annoying even after you know how to turn it on.
Mark, I seem to be getting the opposite behaviour. The nLab on Safari is rendering with its default MathML renderer. I can’t figure out how to “right-click” to get MathJaX turned back on (indeed, as far as I can tell, Safari isn’t requesting MathJaX).
On my MacBook, I can get the “right-click” behavior with control-click.
Ah, I had javascript disabled. Now it works. Thanks.
Incidentally, the test that the nLab performs for whether to add the MathJax header or not is:
if (!(Prototype.Browser.Gecko || navigator.userAgent.match(/MathPlayer/))) {
var s = document.createElement('script');
s.src = "http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=MML_HTMLorMML-full";
document.querySelector('head').appendChild(s);
};
I have some questions concerning this:
On that website the person asking for financial support support writes the following:
Obtaining perfect MathML support in layout engines and ensuring its integration in EPUB readers & ebooks is a very big project. In order to have something achievable in a reasonable time frame, I have selected two main goals:
Create a collection of educational & scientific documents that will serve as examples & test cases for publishers and implementers.
Improve rendering quality in WebKit and Gecko so that EPUB publishers can rely on it.
First question: is it reasonable that half of the project is devoted to “collection of documents” to have examples? Is there any lack of example documents? Should creating/collecting them be more than a small lemma in a project to increase MathML support?
Second question: this text makes the impression as if that person is about the only person on this planet planning to work on “Obtaining perfect MathML support in layout engines”. Is this right? If no, should this person not check what other teams are working on and connect to that? If yes, if there is really only one private and insecurely funded person left to counteract the general decline in MathML support, what are the hopes that this last straw, as it would then seem, will save us?
I have looked around a little bit, trying to find objective information on the prospects for math support on the web.
I suppose this text here is worth reading:
One of the recent topics mentioned there is discussed furthere in the article that Zoran already mentioned above:
The quick summary is this: all the official browser developer teams ignore and in several cases actively disfavor MathML support. Where support (still) exists it is indeed provided by low numbers of unpaid volunteers. (Krautzberger’s article recounts how the removal of the support by Chrome was triggered by the one single person supporting the project, an unpaid volunteer, having to quit to make a living elsewhere.)
Am I being dim? What did Shankland mean by this?
But MathJax, however imperfect, could ultimately help MathML’s prospects. It provides a way to use MathML on the Web, and ultimately such usage is a major factor in whether browser makers support it. In other words, it could help solve the chicken-and-egg problem where browser makers don’t support a technology because it’s not used on the Web, but developers don’t use it on the Web because it’s not supported in browsers.
I guess it means that currently on all those browsers that don’t support MathML, it is MathJax that at least keeps the MathML content visible, for instance without MathJax many people wouldn’t be able to read the nLab unless they changed their preferred system setup.
I understand that MathML is intended to be the optimal solution for math on the web, and probably in principle indeed it would be, but the evidence seems clear that something about MathML makes browsers not want to support it. Even if private volunteers like the one above write code, it seems increasingly unlikely, from what I read in the above links, that browsers are going to include this code. Chrome and IE are examples of browsers where the developer teams actively pushed away the MathML support that third parties did provide. If a small company like DesignScience is being rejected, I suppose single private persons will have a hard time.
At the same time, it seems to me that all this discussion is at the wrong level for us, in that it concerns technology that should be behind the scences and not in the forefront. Because here what we as humans actually interact with is 1. we enter a LaTeX dialact, and 2. we see math formulas on the screen. I don’t really care what the process is called that takes us from 1. to 2. as long as it works for the generic user.
In any case, I suppose we have to live with the prospect that by and large the nLab will be viewed with that intermediate technology being MathJax.
Now, I notice that many math formulas on the nLab don’t come out right with MathJax, or at least they don’t come out the way that they used to come out by other means. Examples that I see include
a)
When stacking arrows as in then the right pointing arrows come out much too short unless one explicitly uses “longrightarrow”. This is not the case for many pages on the lab, and they all look bad in MathJax.
b)
When typesetting limits, I am used to code such as
\underset{\rightarrow}{\lim}_{n} X_n
But with MathJax the subscript “” here overlaps completely with the arrow and becomes unreadable, contrary to how it used to come out. I need to experiment with this to find a way to make such code come out readable.
c)
The biggest problem with MathJax is that it makes pages that are a bit longer increasingly awkward, since the MathJax compiler takes so long to process it. The evident question here is: is it necessary that MathJax compiles the code anew every single time? Can a page not call MathJax on its content once and then store the output?
For a) you can use \rightleftarrows to produce .
For b), normally I use the macros \varinjlim/\varprojlim for this (e.g. \varinjlim_n X_n should work). However this requires the amsmath package which seems not be loaded on the nLab.
For a): I should have said that this appears a lot in discussion of adjoint triples and quadruples, where rightleftarrows is not sufficient.
I suppose this text here is worth reading:
- Peter Krautzberger, MathML Forges On, November 1, 2013 (http://programming.oreilly.com/2013/11/mathml-forges-on.html)
That post links to polyfil which gets bandied about in discussions of MathJax like solutions. I had assumed it had something to do with translating math into SVG polygons, but now I know that it refers to a UK spackling paste and means a browser patch or extension achieved through loading 3rd party JavaScript files, that makes the browser conform to the standards it doesn’t support.
Yes, I would really like to see (c) implemented.
1 to 24 of 24