# Wrong alternative invocation of MathJax

It is commonly known that MathJax can be invoked with $...$ for inline mode and $$...$$ for display mode.

The more latex-like invocation would be $$...$$ for inline mode and $...$ for display mode. This does not work as backslashes and brackets have a special meaning on stack exchange and often need to be escaped.

According to the site's config, there are other invocations allowed:

tex2jax: { inlineMath: [ ["$", "$"], ["\\$","\$/extract_itex]"] ], displayMath: [ ["",""], ["\\[", "\$"] ],
processEscapes: true, ignoreClass: "tex2jax_ignore|dno" }


This literally means that \\$....\$/extract_itex] and \\[...\$ will also invoke MathJax. I think the first definition is faulty and should rather be $...$.

P.S.: All of the posts using this construct (4; cleaned now) are false positives, therefore these alternative invocations are not used at all. Is there any reason to keep them? Alternatively (or additionally), one could add \\ce{...} (or better \ce{...}, like \ref{...} see below)[1] to invoke MathJax - that would probably make more sense.

Additional notes:

1. processRefs: true is the default, so \eqref{label} or \ref{label} works automatically (see sandbox).
Setting up direct rendering of \ce{...} can probably not be handled in the configuration file in this style, this has to be treated directly by the pre-processor. Therefore this would be a feature-request that needs to be relegated to the MathJax team. However, while \ref only processes a label, which should only be a string, and therefore the regular expression \(eq)?ref{[^}]*} is completely sufficient, that cannot be said for all of the code that mhchem's \ce{...} may be able to process.
2. processEnvironments: true is the default, so something like \begin{align}...\end{align} will also invoke maths mode. (\begin{align}...\end{align} is possible in MathJax, but would be an error in latex. It also is really terrible, as it sets a display style environment in inline mode.)
• Right. They should be swapped\\\\\\\\replaced. – M.A.R. ಠ_ಠ Feb 13 '18 at 6:54
• \\ce{H2O} --> $\ce{H2O}$ would be awesome! It doesn't work currently, but it'd be great if it did :D – Gaurang Tandon Feb 13 '18 at 9:22
• As far as readability goes while typing or editing, or searching for a specific line, I think  is superior to \( analogues and bare commands. Not sure why \\$ has been used though. Does indeed seem inconsistent at first glance. – Linear Christmas Feb 13 '18 at 12:42 • @LinearChristmas I find \( increases readability and avoids misinterpretation, since the beginning of maths mode is clearly marked. You have a lot of ambiguity with  (which is usually disabled in default mode for that reason). I guess the "bug" is due to the fact that the forward slash needs to be escaped on SE, because it is used to escape. It is a simple typo, I believe. – Martin - マーチン Feb 13 '18 at 12:51 • Currently, there preview editor only looks for  and  (or \ on some sites) for math delimiters, so if you use \\( or \\[, the contents of the math is not protected from the Markdown processing, and may prevent the math from displaying, or require additional backslashes to be escape Markdown syntax. So the preview code would need to be modified to support \\( and \\[. Similarly for \ce. – Davide Cervone Feb 13 '18 at 13:43 • I assume the reason that dollar signs were used in preference to \( and \[ is the interaction between Markdown's use of  with that of MathJax. For example, since [ is used in Markdown to create links, if you wanted an explicit [ in your output, you are supposed to use \[. That conflicts with using \[ as the display-math delimiter. – Davide Cervone Feb 13 '18 at 13:47 • @Davide If the editor only looks for  and , then wouldn't it be better to completely remove the alternate stuff. It wouldn't really make a difference in the usage (at least not here). The way it is now is just very confusing and I don't see any benefit. the \ce might be better implemented in the MathJax source analogous to \ref; it wouldn't be much of a gain if you had to write \\\\ce... – Martin - マーチン Feb 13 '18 at 14:24 • @Martin-マーチン, I agree, the configuration is inappropriate. I'm only saying that more has to be done to allow \\( and \\[ than just changing the configuration parameter. I am in favor of removing those from the configuration entirely. Yes, it would be possible to handle \ce as \ref currently is, but again, there need to be other changes that support that (this time changes to MathJax itself). If those changes were done, you would only need \ce not \\\\ce. – Davide Cervone Feb 13 '18 at 14:43 • @Davide I have tested \\[ and \\\\( and they do work as they are expected on our site, see sandbox demo. Whatever is going on under the hood, I don't know. However, while removing them on this site is no problem, if that is a network wide configuration, then more care must be applied. The thing about \ce is unfortunately not as easy as \ref as the former takes code, the latter only a string (the preprocessor uses a regex that would break at }), and an implementation must be handled in the source there, so I'm cutting this here. – Martin - マーチン Feb 14 '18 at 3:58 • @Martin-マーチン, yes, if you use them, they will "work", in the sense that MathJax will process them (both in the page and in the preview), but the system goes to special lengths to protect the contents of math delimited by dollar signs from being modified by Markdown, whereas it doesn't do that for these other delimiters. For example, if you enter \\\\(x _1 + x_ 2\\$ you will get \$x 1 + x 2\$, (italic 1 + x with math not processed). Or if you do something like \\$x[1](lost)\\$, you will get no brackets or parens and without "lost". – Davide Cervone Feb 14 '18 at 10:34 • So you have to be careful about the math you type within those delimiters in ways that you don't with dollar delimiters. – Davide Cervone Feb 14 '18 at 10:38 • @Davide Thank yo so much for clearing that up. I think I understand it better now. I'm not a programmer, so that helps a lot. – Martin - マーチン Feb 14 '18 at 10:54 • @Martin-マーチン Are the current mathjax site settings the reason why \begin{align}...\end{align} works just as well with or without the \$ signs? – Gaurang Tandon Mar 12 '18 at 14:44
• @GaurangTandon the current settings allow environments to be escaped; I think the developers did consider this option when they enabled it. See 2 in additional notes – Martin - マーチン Mar 12 '18 at 15:35