# Is “rendered output” for an edit supposed to show markup?

I try to approve some edits. Often if the edit really improves the text depends on how the new markup will be rendered. Selecting "rendered output" I just see the markup, not the rendered output. Why? Bug? Problem with my browser (Firefox)?

• The issue seems to be that the newly added parts are highlighted in green, and some MathJax within the highlighted sections is not rendered. I tried it on my computer by suggesting an edit for one of my own posts from incognito mode. I suspect that whatever is used for the begin/end green highlighting interferes with the MathJax; so, when an entire new equation has been added, it will be rendered perfectly OK. However, when an existing equation is edited, that leads to the different behaviour. – orthocresol Feb 11 '17 at 20:55
• Note that: 1) the first section of green highlighting ends before the closing ...$$, and the MathJax does not render. 2) The entirely new additions \cp, \cv , and \endgroup ... \ln \mathrm{e} = 1 are rendered in MathJax. 3) However, since the first section was not rendered, the newly defined commands \cp and \cv, as well as \endgroup (which requires the begingroup package), throw a MathJax error. (The red-coloured text, as well as the "testing 1/2 ln e = 1", indicate that MathJax has been rendered.) – orthocresol Feb 11 '17 at 20:57 • This should probably go to the main meta as it affects all sites. – Martin - マーチン Feb 11 '17 at 22:15 ## 1 Answer I have noticed that some parts of some MathJax are rendered while other parts of MathJax are not. Thus, I usually stick to the markdown view (i.e. code) on Chemistry.SE, give or take the odd exception. I suspekt that this is due to the following workflow of the edit highlighting code: • It detects different words in both versions, highlights the old one red with strikethrough, the new ones green with highlight. This is done by putting the entire word into an appropriate box (<div>?) • Once that has happened, the MathJax renderer gets to see the page. It will only detect those sets of  signs that have been placed validly — no MathJax across paragraphs and probably not across HTML unit boundaries either. Therefore, if changes have been made within the code and the code is not a single word, the changes will cause the MathJax to be broken apart there — especially if the  sign is affected and the  signs outside now suddenly do not match. This is confirmed by ortho’s suggested testing edit: • The first modifies the ‘word’ $$C_p to the new ‘word’ $$\require{begingroup} with a lot of additional words following. Or maybe the ‘new word’ is considered to be $$\require{begingroup} \begingroup \newcommand{\cp}[0]{C_p}. It doesn’t really matter at this point. Since the edit breaks the sequence of $ signs which no longer match, it is incorrectly displayed. • The second and third bits of MathJax modify an entire word completely. Thus, the rendered output has a correct set of matching $ signs within each group — the MathJax renders.

• The command \cp has been defined in a portion of the MathJax that did not render. Therefore, it is not defined as far as MathJax is concerned.
• The final code is completely new, thus enclosed as a set of ‘new words’ in its own green highlighting code and thus renders as expected (see sub bullet point above).

Further testing may be required to see:

• what happens if changes are performed fully within the code:

$503 - 102 = 402$$503 - 101 = 402$

This could be interpreted or could not be; I don’t know which path is taken. The issue is that the ‘word’ that would cause the highlighting is completely confined within the MathJax that could render (or maybe also could not).

Of course, my assumptions could be complete crap, too.