You have probably seen already a link, on the Featured on Meta sidebar, to an announcement of an upcoming upgrade to the text editor on Stack Exchange, Opt-in alpha test for a new Stacks editor. As a whole, the project looks extremely useful, and it looks like it will do a lot of good for general text editing, particularly for new users who are not accustomed to writing in Markdown.

However, there are several aspects of the proposed changes (as of the initial stage) which are extremely alarming from the perspective of editing MathJax. I raised this yesterday on the Physics meta, but it's also relevant for you guys and I haven't seen you guys there, so I thought I'd nudge you in that direction.

Specifically, the design prototypes, as they currently stand, get rid of the live preview of the post rendering. As far as I'm concerned, this completely breaks typing mathematics as we know it within the SE sphere. From what I can see, the design team is open to creating solutions that will work for the mathy sites, and they are approaching the design with an open attitude, but this will only work if the community pitches in, in constructive ways, to help them find ways that make our sites better instead of breaking them.

So, with that in mind, I would like to ask you to join your voices to the debate. My answer on the MSE thread details my concerns, and they seem to be getting a reasonable reception from the design team. But it would probably still be good to have your voices there to help emphasize how important it is to get this right. If nothing else, the special relationship between MO and SE probably gives you guys more leverage than regular users.

  • 4
    $\begingroup$ Honestly, I don't enjoy the live preview. It slows down my writing, it shows errors while I type (when I'm not done typing) and I usually know how my post will look. Compiling later and correct errors then based on error messages would be totally fine with me (and I would probably find it a bit better). $\endgroup$ – Dirk Jan 29 at 16:25
  • 4
    $\begingroup$ Like @Dirk, I don't use the live preview very much, but I think needing to toggle between modes to see the preview is going to be much worse than a compile button. $\endgroup$ – Noah Snyder Jan 29 at 16:47
  • 19
    $\begingroup$ Why are they fixing something that isn't even broken anyway? This stinks of some stupid side project started by summer interns to make them feel special. This is the Tech Industry, where changes have to be made not to solve any problem in particular, but just because they can be made! $\endgroup$ – Harry Gindi Jan 29 at 16:56
  • 4
    $\begingroup$ Anyway thanks for bringing this to our attention Emilio let's kick up a big dust cloud over this!! $\endgroup$ – Harry Gindi Jan 29 at 17:01
  • 5
    $\begingroup$ @HarryGindi You can read about it over on the meta post. They assert that the codebase for the editor is getting old, with a lot of hacked-together bits and cruft, so that it's hard to maintain and update. They started over to create a rich text editor for the StackExchange Teams product, and now they want to expand that, to streamline things. For non-technical sites (the majority of them), it's very easy to imagine that a rich text editor makes more sense than a markdown editor. So it makes a lot of sense for the network as a whole, but they do need to hear from us about our needs. $\endgroup$ – Tim Campion Jan 29 at 20:44
  • 12
    $\begingroup$ @HarryGindi The only kind of software that doesn't need to get maintained or updated is software which is never used. To see this, consider the graph whose vertices are pieces of software which are used and whose edges are dependencies or interactions between those pieces of software. This graph is dominated by a giant connected component. For example, the giant connected component includes every piece of software which runs on the Internet, every piece of software which runs on Windows or Mac or Linux, and every piece of software written by StackExchange. $\endgroup$ – Tim Campion Jan 29 at 23:26
  • 7
    $\begingroup$ Any time one piece of sofware in this giant connected component is updated or a node is added, neighboring nodes will potentially require update. The update requirements propagate. Therefore, because there exists software in the giant connected component which ever requires update, it follows that every piece of software in the giant connected component potentially requires update. More concretely, every time your browser or operating system is updated, it's possible that the editor code requires a tweak. Every time MathJax is updated, the editor might need a change. $\endgroup$ – Tim Campion Jan 29 at 23:26
  • 7
    $\begingroup$ Every time StackExchange updates one piece of software they've written, this can necessitate changes to neighboring pieces of software, which can necessitate further changes, etc. and among the things that might need to change is the editor. $\endgroup$ – Tim Campion Jan 29 at 23:26
  • 4
    $\begingroup$ @TimCampion I dunno that all sounds like a bunch of excuses to try to push through something unpopular. I've done this kind of thing many times in real life so that's why I don't trust them. $\endgroup$ – Harry Gindi Jan 30 at 4:05
  • 4
    $\begingroup$ @HarryGindi I agree one should never expect that Stack Exchange's decisions are primarily motivated by our interests here at MathOverflow. We're just one of many Stack Exchange sites, we're not the overwhelmingly-most-important site Stack Overflow, and we don't directly make them money at all. So it's of paramount importance that we be vocal about how these changes would adversely affect us. $\endgroup$ – Tim Campion Jan 30 at 7:09
  • 19
    $\begingroup$ However, your theory that Stack Overflow is deciding to replace the editor across all their sites as a "make-work project", designed to be unpopular, is outlandish, ill-motivated, and evidence-free. By contrast, the theory that an application they first wrote over 10 years ago is indeed, as they claim, difficult to maintain across dozens of sites and potentially less effective for the majority of them, and that it never occurred to them to think through the difficulties of of implementing MathJax in an atlernative framework, is, by contrast, well-motivated and has supporting evidence. $\endgroup$ – Tim Campion Jan 30 at 7:09
  • 4
    $\begingroup$ @TimCampion Remember when Google claimed the same motivation for removing the API that allowed ad-blocking to work from chromium? This reminds me of that. $\endgroup$ – Harry Gindi Jan 30 at 7:14
  • 15
    $\begingroup$ There's no need to invoke conspiracy theories or impute malicious intent to be concerned about these particular changes, nor to understand why Stack Exchange's ideas don't always seem like the best ideas from our perspective -- right now or in general. Not everything is about us, and the situation is well-explained by considering the incentives at play and the known facts. I feel this is worth stressing right now because the solution to the problem requires us to communicate with Stack Exchange with the understanding that everyone is here in good faith. $\endgroup$ – Tim Campion Jan 31 at 4:59
  • 15
    $\begingroup$ @HarryGindi I applaud the goal, but please reconsider the tactics. Using conspiracy theories to manipulate people betrays a lack of good faith and is never appropriate. I for one will not tolerate it on MO. Moreover, in the long run it would only serve to undermine our cause. $\endgroup$ – Tim Campion Jan 31 at 15:08
  • 4
    $\begingroup$ @TimCampion: It starts at $6 per user per month. It’s not the kind of model that’s relevant to MO. $\endgroup$ – Noah Snyder Jan 31 at 16:13

New Answer:

Upon reflection, Emilio is 100% correct: We need to sound the alarm bells. Here's a link again to Emilio's well-thought-out answer on the main meta site explaining this, which is probably the best place to start our campaign. In short:

  1. As currently envisaged, the only way to preview MathJax before publishing a post will be by toggling out of markdown mode and into the new rich text editor.

  2. This is unacceptable, because it means that instead of a real MathJax preview, we will be using whatever pale imitation of a MathJax preview the developers at Stack Exchange manage to shoehorn into their rich text editor in their spare time. For instance, it's likely there will be no way to preview the rendering of user-defined macros.


The only solution I see is to convince Stack Exchange to include some form of dedicated preview for markdown mode which is not reliant on rich text mode, and which fully supports MathJax. Given that this is a less demanding requirement than what currently exists, I pray that our overlords will find it feasible to do something like this.

To my mind, the most important thing is not whether the preview is side-by-side, stacked vertically as at present, exists as a separate view, even a third "mode" in addition to markdown and rich text, whatever. The most important thing is that it exists, is independent from the rich text editor and fully supports MathJax. But we should start thinking about details like this -- if all goes well, Stack Exchange ought to be soliciting our input on such matters as we move forward.

I've also left an answer at the main meta site discussing this in more detail. It's a chore to look through all the answers over there, but it appears that others have also raised concerns about MathJax integration. Emilio also points out there there are several sites which also rely on other formatting plugins, such as chess, go, furigana and music notation, which would suffer much like MathJax users in the currently-envisaged system. We need to band together and clearly articulate our needs. As Emilio points out, MO's unique arrangement with Stack Exchange gives us some extra leverage compared to many other sites. For this reason, and because we would among the sites most severely affected by theses changes, it is incumbent upon us to take a particularly active role in this effort.

Original Answer:

A bit long for a comment:

Thanks, Emilio, for bringing this up here! I already flew off the handle in the comments to Emilio's answer at the main meta question under the impression (which I now believe to be mistaken) that the proposed changes would force one to use rich text with no option to revert to markdown. I now understand what they're proposing would include the option to revert to markdown, but that there would be no live preview in the markdown mode.

This is not as catastrophic as I first thought, but it would mean you're tying a hand behind your back. In order to catch minor errors you'd have to either publish and see the render and then make a series of public edits, or else toggle to rich text and cross your fingers that the rich text representation is adequate to catch stuff.

As pointed out over there, the preview is actually in some sense an upgrade over many latex editors because of the automatic and constant refresh. I suppose I don't need the refresh to be so frequent, and I don't need it to be automatic, but it sure is nice. If it's not going to be there, I would prefer to have a "compile" button rather than "toggling to rich text mode". The latter feels more clunky -- every time I toggle, the refresh is going to be loading all sorts of rich text functionality which is irrelevant to me, in addition to rendering the mathjax that I actually need to see.

  • 4
    $\begingroup$ After considering this a bit more and opting in to the alpha test (which only seems to be available on the main meta site and not on mathoverflow, and which doesn't at this point have any mathjax support at all), I'm back to being increasingly concerned. I've written an answer to the main meta question discussing this. In brief: if the only way to preview your mathjax is in the rich text editor, then the preview is never going to be good enough for our needs, because they'll be shoehorning the mathjax preview into an entirely different beast. $\endgroup$ – Tim Campion Jan 30 at 4:25
  • 4
    $\begingroup$ Glad you've come around to being suspicious of this stuff Tim! $\endgroup$ – Harry Gindi Jan 30 at 7:13
  • 13
    $\begingroup$ So, typing math in a question or an answer will become as difficult as typing math in a comment is now? $\endgroup$ – Gerald Edgar Jan 30 at 16:18
  • 3
    $\begingroup$ @GeraldEdgar I fear that might be exactly right. $\endgroup$ – Tim Campion Jan 30 at 16:19
  • 7
    $\begingroup$ To spell out the obvious: it's acceptable for comments to have no mathjax preview because they are constrained in length. More complex expressions which benefit the most from previewing are less likely to come up. And of course, the total amount of math written is limited. So it's generally feasible to catch any errors after publishing the comment, diagnose them, and fix them in the the alotted 5 minutes. The situation in questions and answers is completely different, and so the setup which is adequate for comments is inadequate for questions and answers. $\endgroup$ – Tim Campion Jan 31 at 4:39
  • $\begingroup$ @TimCampion Thank you for your kind comments over on the MSE thread. $\endgroup$ – Emilio Pisanty Feb 1 at 17:35
  • 6
    $\begingroup$ @EmilioPisanty 100%. Your work here has been exemplary. You've taken the time to digest large complex changes, you've identified serious issues buried in them, you've carefully and clearly articulated these problems to the rest of us, you've recognized the need to thread the needle between raising the alarm and going overboard, you've managed to do that, and you've been proactive in spreading the word. I really appreciate it. From my occasional foray in to Physics SE, I'd expect no less. $\endgroup$ – Tim Campion Feb 1 at 17:48
  • 6
    $\begingroup$ Also editing comments doesn’t bump the front page like editing a posted question or answer does. So there’s no harm in using “post” as preview for comments. $\endgroup$ – Noah Snyder Feb 1 at 20:56

Here is one option put forward by the SE developers: switching from MathJax to prosemirror-math. For a quick look at how it works, I'll just pull this from their readme:


Unlike other editors, this plugin treats math as part of the text itself, rather than as an "atom" that can only be edited through a dialog box. For example, inline math nodes can be edited directly by bringing the cursor inside of them:

edit inline math

Display math supports multiline editing, as shown below:

edit display math

The inner workings of the text editing are based on prosemirror, which is the software base for the new Stacks editor, so that's good for SE.

The mathematics rendering is done using KaTeX, which is an alternative to MathJax. KaTeX was discussed in the physics meta in 2017 (and even earlier here on meta.MO in 2014) and the conclusion then was that it was not mature enough, but the software has moved on since then, and it's probably due for a re-evaluation.

  • Many of the deal-breakers mentioned back then (say, the lack of support for \newcommand) have since been fixed.
  • On the other hand, at the very least, KaTeX is not fully interoperable with MathJax. At the very least, the align environment needs to be replaced by aligned, which entails editing 7.5k posts on physics, 1.8k on MO and 50k+ on math.se. For fancier behaviour we would need to have a very detailed look.
  • Independently of the maturity of KaTeX, it's unclear to me how mature the prosemirror-math software is. Their To Do list includes "Test in FireFox, Safari, Edge" and their last commit was four months ago, and that's not a good sign.
  • It's unclear to me how fast the preview would be on prosemirror-math, and how it would be affected by a slow connection speed. If there is a danger that the preview slows down on lower bandwidths, then that is exclusionary and unacceptable -- but it isn't detected unless specifically tested for, so it needs to be explicitly checked.

In any case, independently of those technical hiccups, we as users should answer the question: is the style of editing offered by this solution something we can work with? I for one find it intriguing, but I don't want to say 'yes' without trying it out (and it's unclear whether there are any solutions that can do that at the moment).

  • 12
    $\begingroup$ The basic workflow looks fine. The incompatibility of KaTeX with MathJax is a serious problem; I notice the TODO also includes “Support a render callback function, allowing use of MathJax / MathLive instead of KaTeX”, but it is quite low on the list. On the other hand, these worries may be premature. The SE developer didn’t write “we can use prosemirror-math”; they only suggested that it is an “interesting approach”, which to me reads as saying that they might implement something similar, or perhaps use an adaptation of prosemirror-math, not that they would just use the package out of the box. $\endgroup$ – Emil Jeřábek Feb 1 at 12:49
  • 2
    $\begingroup$ There is also a post about KaTeX on Meta Stack Exchange: Next math renderer MathJax v3 versus KaTeX? Is it clear from the discussion that it would be necessary to switch from MathJax to KaTeX to have something similar to those examples? $\endgroup$ – Martin Sleziak Feb 1 at 12:54
  • 1
    $\begingroup$ I wouldn’t be happy about it, but I’m pretty sure I could live with it (assuming it works on safari and the major backwards compatibility issues were solved). $\endgroup$ – Noah Snyder Feb 1 at 13:39
  • 4
    $\begingroup$ My immediate reaction, when considering yet another framework where some developer is making choices about mimicking some subset of the capabilities of Latex is extreme skepticism. For instance, commutative diagrams in MathJax are limited to the amscd package which nobody uses in latex and which is quite limited compared to tikz or xymatrix. But it always seemed like a lucky break that they were supported at all. Will we get another lucky break and have commutative diagram support in this new framework? I'm sure you could say the same about Latex essentials in other areas of math. $\endgroup$ – Tim Campion Feb 1 at 15:38
  • 2
    $\begingroup$ In the particular case of commutative diagrams, tikz support has been suggested and dismissed -- I don't know if just tikzcd would be more feasible. xymatrix has been suggested and I think it says somewhere in there that amscd is supported. So maybe it would not be a further downgrade from mathjax. I'm still concerned that there are probably all sorts of similar things that others need and would have to fight to get implemented that I don't know about. $\endgroup$ – Tim Campion Feb 1 at 15:45
  • $\begingroup$ If we're seriously discussing any approach which doesn't start from the premise that MathJax will be fully supported, then we probably need to start compiling an explicit list of what Latex features we need to have supported. (grumble grumble does SE even appreciate what they're putting us through...) $\endgroup$ – Tim Campion Feb 1 at 17:39
  • 1
    $\begingroup$ Accordingly, I've started this question to start doing just that. $\endgroup$ – Tim Campion Feb 1 at 18:40
  • $\begingroup$ @TimCampion For what it's worth reading the bug report you linked it seems that AMScd support has been added to KaTeX (although maybe still only to the development version). While I'd love to have full TikZ, this seems like an acceptable fallback (or, at least, not worsen the current situation). $\endgroup$ – Denis Nardin Feb 4 at 17:03
  • $\begingroup$ @DenisNardin That was my impression too but I haven’t checked carefully and others like Willie Wong on the other thread seem to have indicated that amscd is not supported. It’s probably a good idea to get to the bottom of this. $\endgroup$ – Tim Campion Feb 4 at 18:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .