beta 2.5 as-you-type rendering showing bare tex during processing

[s9w]

Even with the fast preview disabled, the new 2.5 beta behaves significantly different (worse) when you use it as a live preview. Two identical fiddles with the only difference being the linked mathJax version:

stable beta

With the beta, the original tex code is shown during processing. This seems only to affect Chrome though, Firefox is the same. And this is in react obviously, not sure how that comes into play.

[pkra]

Sorry for the slow response. This is expected behavior. Technically, this gap has always happened but may have been virtually invisible because of https://github.com/mathjax/MathJax/issues/872. (BTW, neither demo uses the beta version but the problem is reproducible)

In case you haven't seen it, there's https://github.com/mathjax/MathJax/blob/master/test/sample-dynamic.html and https://github.com/mathjax/MathJax/blob/master/test/sample-dynamic-2.html (see also the docs).

But we don't know enough about ReactJS to say if that approach clashes with reactjs design principles. We'd be happy to help with advice related to MathJax, of course, if you want to dig a little deeper. I'm sure more people would be interested in the result.

[s9w]

(apparently I forgot to save the beta link, my bad)

Yeah I've seen those and had a working implementation in my react app. Then by accident I found out that the old version just works, so this is a bit disappointing. React or not: double buffering for math rendering seems like a crude solution. I hope there's plans to integrate this "unexpected" behavior. But thanks for the clarification.

[pkra]

I hope there's plans to integrate this "unexpected" behavior.

I'm not sure what you mean by this.

IIUC, the jsfiddle code behaves roughly as follows. React destroys the old node, replaces it with a new node consisting (basically) only of a TeX string, then tells MathJax to render that node. If the TeX string is not supposed to show up in the DOM, then the order needs to be changed. As you wrote, the fact that the approach used to work was simply accidental. MathJax provides a specific API for updating an equation but if the equation node is destroyed then updating is naturally out of the quesiton.

[s9w]

You're right: That rendered Html Element is probably just staying there because React didn't notice that it got there in the first place or some other dark DOM magic.

However the whole problem only arises in the first place because MathJax is pretty unique in its "in control" behavior. It neither accepts a direct equation string input, nor does it deliver the output to a designated place (in some variable or function). So there's all kinds of elaborate tricks involved to try to influence its rendering behavior/timing, capturing/hiding the (sometimes hidden) output and try to manually display it in an appropriate way. It feels like it's working pretty anti-intuitive and against a use by a program (versus use by a human - it's very simple there!). That's why I thought/hoped this was somehow a change of that mindset.

[dpvc]

If you want to remove the delay between input and output phases that is probably the cause of the result you are seeing, you can add

<script type="text/x-mathjax-config">
MathJax.Hub.processSectionDelay = 0;
</script>

to your page before the script the loads MathJax.js. This should produce the v2.4 behavior. But as noted above, that still doesn't guarantee that you won't see the TeX code before it is rendered. That is browser dependent (as you have found), and also dependent on the actual content of the math being rendered, the state of the browser cache, the fonts available on the system and in cache, the number of equations being processed, and other factors. There have always been situations where you would have seen the TeX before it was typeset.

[pkra]

It neither accepts a direct equation string input, nor does it deliver the output to a designated place (in some variable or function). So there's all kinds of elaborate tricks involved to try to influence its rendering behavior/timing, capturing/hiding the (sometimes hidden) output and try to manually display it in an appropriate way.

Hm... this mixes a couple of things together that should probably be discussed separately. Anyway, you're right that MathJax is somewhat complicated in its behavior -- and we'd love to change that! The trouble is that this is not by preference but necessity. E.g., for various technical reasons MathJax has to work in the DOM context to do a good rendering job (especially the HTML-CSS output).

Anyway, we are interested to learn about specific issues and requirements from developers such as yourself. In the past, developers asking for "simplifications" either vanished before we got anywhere or ended up being unhappy because "simplifications" can force them to deal with the minutiae of layout on their end. I suspect a big part of this is that MathJax is a somewhat unique polyfill -- implementing an entire HTML5 rendering component and several other things along the way such as webfont loading detection, x-height matching, baseline detection etc -- and people tend to underestimate the complexity (and then we haven't even talked about browser coverage, the input side, faithfulness to TeX/LaTeX, extensibility, module loading etc.).

Long story short, we're happy to help you figure out what a good React workflow might look like. And we're also interested in discussing the big picture questions (though maybe separately on the mathjax-dev list); and finally we also understand that people are often busy and can't invest the time.

[pkra]

=> marked abandoned.