# MathJax support #24

Closed
opened this Issue Jun 17, 2013 · 57 comments

Projects
None yet
8 participants

### fgdorais commented Jun 17, 2013

 Please enable MathJax everywhere it makes sense!
Owner

Owner

### mqlaql commented Jun 19, 2013

 @johncarlosbaez Well, it will cause problems. What kind of problem depends on your input. Common scenarios are the following: It won't recognize the dollar sign as a currency so it will display regular text as equations. It won't compile the equation. It will remove one dollar sign. But in general this is a bit unpredictable.

### sir-deenicus commented Jun 19, 2013

 @mqlaql Users go to SelectedPapers.net The key point of the project is that it tries to make an end run round why most projects like it fail by minimizing friction of interaction. It goes where people already are. If instead, people go through it as a central location then a whole bunch of design decisions don't make sense and its unique selling point disappears We push the updates to their social network, but without the whole content, just a text snippet as a notification to let other people know that new activity exists in the site. The main social network used by technical people to talk about technical things does not allow writing/push. It has some totally not useful private moments concept.

### mqlaql commented Jun 19, 2013

 @sir-deenicus You're right! I thought the Google+ API was mature enough to allow posting, updating, etc. However, I found something called App Activities: After the user signs in using the Google+ Sign-In button, you can write app activities to Google on behalf of your user with the moments methods. App activities reflect a variety of user actions including check-ins, reviews, commenting on articles, and more. Users control the visibility of their app activities on Google using circles. Your app can use the type of activity that best reflects your content or the user's action. However, I'm not sure what it looks like. The 'review' part sounds interesting, though. Regarding your first point, yes, I know that is the original idea but it is already causing many problems. At the end, I don't think it's technically feasible to create a good integration with Google+, let alone Twitter, Wordpress, etc. In any case, minimizing friction shouldn't guide design decisions. The idea should be build something that provides value to researchers and then worry about friction. Otherwise, you end up with bad user experience such as lack of LaTeX support, an extremely minimalist text editor, no preview, synchronization issues, restrictions in the API, etc. I think the main selling point should be "Look, this is an amazing site where you can find reviews and commentary on scientific literature." No one is going to complain that they have to type another url.
Owner

### cjlee112 commented Jun 19, 2013

 @johncarlosbaez Over time I think we can protect against $problems in several ways: note first that when displaying several posts / replies on one page, we do not have to apply a single policy to all of them. For the purposes of this discussion let's say the spnet server analyzes each post separately; even if the encoding of a post is supposed to be$inlinemath$, if it contains an odd number of unescaped$, it clearly contains a user error, so we'll handle it carefully. Worst case we display that one post without converting the $expressions (we can still render the displaymath), and send the user a notification to fix their post. Note that even if we only allowed (inlinemath), we would STILL face this problem (i.e. people will forget or mistype their delimiters occasionally). Various rules can help, e.g. the pandoc rule for detecting inline math (described by @fgdorais above) requires that the closing$ be preceded by a non-whitespace character, so "it costs $5 for 5 minutes and$15 for the full half hour" won't get interpreted as inline math. as I mentioned in a previous comment, we can probably avoid most of these interpretation problems by distinguishing types of users and content. E.g. for abstracts, only arXiv content can contain latex. For users, either a user is a mathematician who uses $inlinemath$ in their posts, or they are from some other field and never use $inlinemath$. We can infer those defaults for a given user based on their activity or tags, or let them set it up front.
Owner

### cjlee112 commented Jun 19, 2013

 the unfortunate reality is that rendering LaTeX (even with just (...) ) makes our job harder, because we can no longer just let the browser deal with how to render users' content. (Because G+ only allows flat text, we can safely treat it that way, in the absence of LaTeX). Users can mistype or forget the close tags ) or ], potentially causing the entire rest of the page to get mis-rendered. Our server will therefore have to check each post for such errors. And when we detect them, we'll have to handle them gracefully. @pkra how does MathJax handle these cases? Am I right in thinking we can't just leave all these problems to MathJax to solve?

### pkra commented Jun 19, 2013

 Oops, so many new comments -- that's what I get for being stuck in a different time zone... re >, < etc: the sites' chosen input method escape those. MathJax works either way (it's very tolerant in general). re the proposed delimiters: imho, they make sense, especially for papers from the arXiv. re unmatched delimiters: MathJax does a pretty good job on its own. First of all, MathJax will stop parsing at HTML elements and unmatched delimiters are simply ignored. Accordingly, HTML elements within math delimiters will stop the parser -- e.g. $ will be ignored, as will $$f \circ g$$ . This can be a different problem when an input mechanism adds things like   to an array. Of course, if, for example, there are two inline math expressions within an HTML element, and the first expression is missing its closing $, then MathJax will use the opening $ of the second element and ignore the last $. a general comment: if spnet wants some independence from MathJax // javascript (e.g. in rss feeds), then you could consider converting TeX to MathML on the server. Not that this will help much right now, since only Firefox has a decent implementation and most sites sanitize it to oblivion, but philosophically, that's the right web standard to use. Most conversion tools leave the TeX as annotations (and the next MathJax version will expose those better). @mqlaql as much as I sympathize, in my experience the "$ is deprecated"-argument just doesn't work (as iPython shows -- they haven't deprecated it so far). The problem is probably that the LaTeX folks can't really enforce it. The question is: how do we get people to adopt something other than $? I think eventually a combined effort of iPython, R-studio, MO, math.SE, and spnet could change that for math on the web. (imho, we need a better delimiter -- $...$ (on a US-keyboard) is smooth to enter, $$...$$`is quite rough.)

### loopspace commented Jun 19, 2013

 I'd like to pick up on Peter's fourth comment. There is a way to get the best of both worlds on this. The server converts the TeX-like syntax to MathML (and caches the result). Anything that can cope with MathML can then get the raw MathML, anything else gets served the MathML with MathJaX as an interpreter. This is how the nLab and nForum serve up mathematics. Those sites show, I think, that people do quickly get used to how things work. Server-side conversion has a whole slew of benefits involving better error-checking and better speed. Moreover, by using MathML you make your site accessible which is no bad thing. MathML support in browsers is growing, and growing fast. But even browsers that can't cope with it natively can use MathJaX to convert MathML to HTML+CSS. That conversion is far more reliable than the TeX conversion and is far faster. (If you do go down the pure MathJaX route, I'll add my vote against dollars. The LaTeX folks can't impose the parenthesis method simply because that's not how LaTeX works. But my guess is that the people who will tend to use the selected papers network will be those who are a little more technologically savvy and find it a little easier to do "new things" rather than just cut and paste stuff from one article to the next.)

### pkra commented Jun 19, 2013

 This is getting a bit off-topic but two comments. As much as I'd like it be different, native browser MathML development is not picking up (e.g., Chrome & Opera abandoning their limited support). All direct development in Firefox and WebKit so far has been done by unpaid volunteers and there's nobody actively working on native browser support -- except one of our developers, on a small scale. (On the bright side, we're working to make that a much larger scale.) Also, MathML isn't really more accessible. There are only two actively maintained accessibility tools supporting MathML -- MathPlayer and ChromeVox -- both of which support MathJax output. (Whether MathML is actually enough for generating aural representations is another matter of debate among specialists.) Of course, I'd still suggest to consider MathML conversion; if not now, at least keep it in mind in design decisions.

### loopspace commented Jun 19, 2013

 The consistent message that I get from the blindmath mailing list is that MathML is the best technology for making mathematics as accessible as possible, whilst acknowledging that that might not be as good as it could be. Nonetheless, do you see any disadvantage to server-side MathML with client-side MathJaX where needed?

### pkra commented Jun 19, 2013

 From a MathJax-output point of view, there aren't many disadvantages; both MathML and TeX input has its disadvantages. For the spnet development, the question is probably if server-side conversion is realistic. It will add dependencies, require development time etc (re:a11y yes, that's a statement I've heard as well but recently with more and more caveats.)

### loopspace commented Jun 19, 2013

 I like that: "both MathML and TeX input has its disadvantages"! So what is the best input for MathJaX, then? I suppose that for spnet the question is as to how much is going to be slurped from elsewhere and how much is going to be "home grown". If slurped, then I don't really see how this is solvable. If I can add my website to what spnet slurps (since that's where I record all my comments, and I have no intention of changing that) then it'll have to adapt to what my website produces and given the number of possibilities around the internet that seems an impossible task. On the other hand, if spnet's content is meant to be "home grown" then it can impose its own rules, and server-side conversion is now a solved problem so there shouldn't be any real difficulty in implementing it. It is interesting to read the discussions on the blindmath mailing list. My rough impression is that the established mathematicians want raw TeX and the newcomers (students, school kids, etc) want MathML - or at least, they don't know what they want but MathML is what is generally recommended to them. I will accept that MathML is not perfect. But it is the best thing going, particularly as it is an open standard (unlike TeX!). It's acceptance is chicken-and-egg. Until it is widely adopted, browser support will lag. But until browser support increases, it is hard to get it adopted. That's where I see the great strength of MathJaX: as a way around that roadblock.
Owner

### cjlee112 commented Jun 19, 2013

 @loopspace You've stated the core issue very clearly. The spnet philosophy is "slurpy", that is, we are trying to integrate what people are saying from many sources (e.g. on your weblog) by adding a bit of tagging to identify what they are talking about. Precisely as you said, you are happy writing your posts on your site, so why should you have to change that? Since Google+ restricts posts to flat text, which is highly portable, we can display Google+ posts easily on selectedpapers.net pages. The opposite end of the spectrum would be some kind of page format that we have no way (yet) to "sanitize". In that case our worst case scenario is to just index its tags and title (and possibly its first few sentences, stripped to flat text) and display that on selectedpapers.net with a link to the original page. Sorry to go a bit off-topic, but I wanted to answer your question.
Owner

### fgdorais commented Jun 19, 2013

 @pkra I think a pandoc-style extension to MathJax would be highly desirable. It would be super handy for tools like the MathJax Bookmarklet and GmailTeX!
Owner

### cjlee112 commented Jun 19, 2013

 @mqlaql I think @loopspace writes posts on his own blog, not on Google+. RE: preview capability, I definitely agree this would be fantastic. I just noticed the G+ Web interactive post docs added a JS call for creating an interactive post button. I want to experiment to see if that will let us create posts dynamically (rather than the post content being fixed permanently at page load). If so we gain all sorts of flexibility, basically because we can offer our own interfaces for writing posts etc. and the G+ dialog just becomes a rubber-stamp "confirm and send" step. FYI here's the new call documentation: https://developers.google.com/+/web/share/interactive#gapi.interactivepost.render Note that even without this we could in principle have our own post submission form, but it would require one extra page-reload-and-click step: write your post on our form, submit it; see a preview, if you're happy, click Post button; (this is the extra step that would become unnecessary if the JS call can create interactive post button dynamically). annoying Google+ dialog comes up, you enter Public as the recipient, and click Share. RE: handling inlinemath delimiter problems, I was not thinking to handle this with regexp, more like a computationally cheap Hidden Markov Model (ie. sum integer log-odds score, for competing models)
Owner

### cjlee112 commented Jun 19, 2013

 @pkra thanks for pointing out the Safe configuration setting!
Owner

### cjlee112 commented Jun 19, 2013

 @sir-deenicus @mqlaql: I agree, App Activities seem like nonsense designed for advertisers to flog products by pushing stupid "events" ("I arrived at the wonderful hotel!") into G+ users' streams, rather than useful for G+ users themselves (i.e. us). In my brief attempt to figure out what in heck App Activities actually do, I couldn't find anything we could use.

### mqlaql commented Jun 19, 2013

 @cjlee112 Right. Wordpress is far more suitable for long-form writings. However, fetching from blogs is more complicated. It also reduces the number of active users. I don't think interactive posts allows to create interfaces for writing posts. Currently, it seems to add a "Call to action" button for different actions such as promoting something. App Activities seems to be in development but it doesn't look so promising- The 3 step process you outlined seems fairly painless to me. It's basically the same procedure that is used to share on Twitter from external sites. Never heard about a HMM's application on nested delimiters. It would be interesting although a parser is the common solution and it's not so cheap.

### loopspace commented Jun 19, 2013

 Yes, I post on my own ... well, actually it's a wiki. I currently have 304 papers listed there. Most just have basic bibliographic data and a few categories (sort of like tags) but every now and then I'll make some more comments. A quick look at file sizes shows that the one I've made the most comments on is: http://ncatlab.org/lspace/show/A%20convenient%20setting%20for%20differential%20geometry%20and%20global%20analysis. I'd be quite happy to add some link to that page to the SPN and allow that content to appear on the SPN. But I'd rather not have to paste it into a G+ post, or really I'd rather not have to paste it anywhere else. If you could figure a way that I could add a link to that page whereupon I (or anyone else) could click it and post it to SPN then I'd add it in an instant.
Owner

### cjlee112 commented Jun 19, 2013

 @loopspace We want the indexing to be automatic, i.e. just give it an RSS URL and it will scan for paper IDs. In principle, for old posts this could be just looking for an arXiv ID of the form arXiv:1234.5678 (or old-style arXiv ID), so you would not have to retag posts "spnetwork". That is issue #17.

Open

Owner

### cjlee112 commented Jun 20, 2013

 I implemented the proposal (default MathJax plus $inlinemath$ allowed, Safe mode) and was immediately disappointed: arXiv abstracts are totally inconsistent: some use $, others strip them out (so there is no delimiter marking the inlinemath at all)! the second arXiv paper I looked at (arXiv:1305.6100) had an error that made it look awful: the author left out the starting$ on one of his equations, then MathJax got out of sync and interpreted much of the remaining text as inline math (forcing it into a single line running right off the edge of the window, so you lose much of the abstract). The horror, the horror. I thought user comments would be the main source of trouble but it turns out that arXiv content is worse! I am tempted to deploy this with a big message on the homepage (linked to this example) saying this is why $inlinemath$ must die: people make mistakes; computers must be able to detect and handle those mistakes sanely. $inlinemath$ makes that impossible, for the same reason that you wouldn't replace all the parentheses (...) in your equations with $...$ (you wouldn't be able to tell whether $means open or close; similarly, a computer can't tell whether$ means start-inlinemath or stop-inlinemath, because it can't tell the difference between math vs. text -- that's why it needed a delimiter in the first place!)
Owner

### cjlee112 commented Jun 20, 2013

 In the face of inconsistent usage of $inlinemath$, it seems to me we should give people fine-grained control: we would recommend the MathJax default, i.e. (inlinemath) [displaymath]. Those delimiters will work everywhere. for arXiv abstracts, give people a checkbox "show $inlinemath$". $would only be treated as inlinemath if the box is checked. Furthermore, we can "crowdsource" the default by keeping a count (in the database) of how many times people clicked to turn this ON vs. OFF (then set the default based on which count is bigger). for user comments, give each user a checkbox "treat$ as inlinemath in my posts". Give them a "big red warning label" saying they really should use (...) and that if they screw up their $, their post will look like crap. The way this would be actually implemented would be by using the default MathJax settings, and if requested convert an individual piece of content (e.g. an abstract or post) to replace$foo$with (foo) so that MathJax will treat it as inlinemath. We can also try to follow the pandoc rule mentioned in previous comments. If the count of unescaped$ in that text is odd, don't do the conversion at all, and stick in a warning message.
Contributor

Collaborator

### nilesjohnson commented Jun 21, 2013

 I tried this on a local install of spnet, and Chrome does render the math there. Checking the Chrome console, I read the following error: The page at https://selectedpapers.net/arxiv/0809.0838 ran insecure content from http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML,Safe The difference must be that the local site is served over http, while the live site is served over https. Googling around, I discovered the following in MathJax FAQ: http://www.mathjax.org/resources/faqs/#problem-https It says that getting content from the CDN over https is not available from the default address, but is available from the less-memorable but equally-functional alternate https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js
Owner

### cjlee112 commented Jun 25, 2013

 Great catch, Niles! I guess I'll switch to the https CDN address.
Owner

### cjlee112 commented Jun 26, 2013

 switched to https CDN. Please test that this fixes the Chrome problem you observed. Thanks!
Collaborator

### nilesjohnson commented Jun 26, 2013

 Indeed the problem I observed is resolved; Chrome console shows no errors.

Closed