Incorrect rendering hidden formula

[scaljeri]

When a formula initially is hidden (display: none) MathJax renders the formula with an incorrect width.

DEMO: http://jsfiddle.net/1hLvdbm2/2/

This problem only seems to happen in v2.5.2. If I run the same demo agains 2.4-latest it works as expected

DEMO: http://jsfiddle.net/1hLvdbm2/3/

[smtosh]

I use MathJax to create online mathematics lectures. The content is timed with audio, and thus is initially hidden. Our department is experiencing the same problem (0 width given to math when it appears). This is an urgent issue for us, as several of our math courses use this technique, and these classes are starting Monday.

@scaljeri, I think the demo you posted in your other issue better illustrated the problem:
http://jsfiddle.net/1hLvdbm2/

[scaljeri]

I've, for now, solved it by going back to 2.4-latest

<script src="//cdn.mathjax.org/mathjax/2.4-latest/MathJax.js?delayStartupUntil=configured"></script>

Although our testers still have to verify that this actually works with our formula's it seems to work pretty wel! And, serving the code of tag 2.5.1 yourself will work as wel (but is for me more work)

[pkra]

Thanks for reporting this separately and creating the minimal samples. We're looking into it.

[siegristk]

I have a large probability/statistics site in which proofs of theorems and solutions to exercises are initially hidden, so this is an urgent issue for me also. The problem exists for content hidden via the HTML

element (supported in Chrome and Safari) and for content hidden via CSS (as noted already).

[siegristk]

In the last post, I meant the HTML 5 details-summary element.

[dpvc]

In general, using MathJax to process math inside a container that has display:none is both slower and less accurate than using other means of hiding the content (such as visibility:hidden; height:0; overflow:hidden). To deal with display:none, MathJax must move the math to another position that isn't hidden, typeset it there, and move it back. Because it can't measure the fonts at the location of the math, the sizing might not be correct, and the amount of space reserved for the math might be wrong. Because the math is moved, that causes an extra page reflow for each such equation, and that is a source if serious performance degradation. For these reasons, we don't recommend typesetting math within containers that have display:none.

That being said, some optimizations introduced in 2.5 and updated in 2.5.2 did interfere with MathJax's process for handling this situation. The issue1179 branch of my fork of MathJax includes a proposed fix for this.

[smtosh]

I downloaded that branch and tried it. I am still getting the same problem as before.

[dpvc]

@smtosh, the branch only includes the unpacked version at the moment, so make sure you insert unpacked/ before MathJax.js in the script call that loads MathJax.js. We only pack the final version just before a release.

[smtosh]

I added that in, and it looks like the fix worked from my end!

[dpvc]

Great! Thanks for the confirmation.

[dpvc]

==> Test Available.
MathMLToDisplay/issue1179.html

[smtosh]

Two quick questions:

1. I am pretty new to GitHub. How to I get to the test you just made available?
2. Approximately how long will it take until this fix is incorporated into the 'latest' version of MathJax? I understand you are working away at this, but if you feel it will not be ready before Monday, I will need to update our call to MathJax in quite a number of files.
   Thanks.

[dpvc]

The test file is in the MathJax-test repository, and is only really usable within that framework. It is not easy to set up and run, but you are welcome to do so if you want. This specific test file simply typesets the same equation in two different divs, one with display:none and one without, then compares the widths of the resulting expressions.

[dpvc]

I'm in the processes of running the test suite, and if all goes well, it is possible that the release could be made tomorrow (though Peter is the one to make that call).

[dpvc]

PS, if the problem is the unpacked, I will probably have the packed version in place tonight, so if you can use your own copy of my branch without changing files, that might be a solution.

[pkra]

@smtosh wrote

1. Approximately how long will it take until this fix is incorporated into the 'latest' version of MathJax? I understand you are working away at this, but if you feel it will not be ready before Monday, I will need to update our call to MathJax in quite a number of files.

You might want to consider switching to 2.4-latest or hosting your own copy of 2.5.1.

[pkra]

=> Fixed and merged.

[smtosh]

Thank you so much for being so efficient in getting this bug fixed! It is much appreciated.

[siegristk]

Yes, Thanks so much for the quick action!

On Fri, May 1, 2015 at 5:28 AM, smtosh notifications@github.com wrote:

Thank you so much for being so efficient in getting this bug fixed! It is
much appreciated.

—
Reply to this email directly or view it on GitHub
#1179 (comment).

Kyle Siegrist
kyle.montesano@gmail.com kyle.montesano@gmail.com

[pkra]

No problem.

Just to be sure: it's still bad practice to use display:none on content that MathJax should process -- it leads to unreliable rendering and has worse performance than using visibility:hidden; height:0; overflow:hidden.

[scaljeri]

Is there any change that this bad practice could be fixed ? In case of details / summary you don't have much options I think. Also with visibility: hidden the element will have a width (if I'm correct) which can give weird layout issues during initialisation!

[dpvc]

with visibility: hidden the element will have a width (if I'm correct) which can give weird layout issues during initialization!

You can certainly add width:0 to that, or even position:absolute; top:0, left:0 if it interrupts your display otherwise

Is there any change that this bad practice could be fixed?

There are two important factors involved here. The first is that moving the math to another relocation means that the next time MathJax takes a measurement, the browser has to reflow the page, so each equation that is in a container with display:none potentially causes a reflow. Reflows have a heavy performance penalty, and this can really slow down the processing of a page.

It turns out that I was able to resolve this issue in the 2.5.3 release by moving such math elements all at the same time (so only one reflow occurs). That was not the case prior to 2.5.3. So the performance problem is resolved.

The other factor is that MathJax needs to match the size of the font at the location in the page where the math is to be typeset, and to do so, it must determine the ex-height of the surrounding font. It does that by measuring an element with size given in units of ex at the location of the math. But if the math is in a container with display:none, MathJax can't take that measurement, so can't tell how big to make the math. Instead, when it moves the math, it uses the ex-height of that location, but that might not match the original location well. Since MathJax uses units of em as is places the math (so that it can be scaled more easily), If the font size at the original location is different from where MathJax moved the math, the results may not be laid out properly when they are moved back. Furthermore, since the CSS rules in play at the original location might not be the same as in the temporary location, that can also affect the accuracy of the layout when it is moved back. For example, if you use a character that is not in MathJax's fonts, it has to try to determine the size of that character, and the CSS in play where the math is typeset can affect that; so moving it back to its original location may produce less accurate results, as the font or font size (or weight, or other factors) may not be the same. So this is always going to be less reliable, and will depend on your setup. It might work fine for you, but not so well in other sites.

It might be possible to look up the font information from the original location and transfer that along with the math when it is moved, but some older browsers that are still supported by MathJax can't do that, so it would mean dropping support for them (or having to handle them as special cases).

The other approach would be to be less reliant on measuring the results. We are working on a new output format that is browser and platform independent, and this output does not rely on taking measurements like the current HTML-CSS output does, so can be transferred from place to place more easily. It still does need to determine the ex-height, however, so display:none is still an issue from that standpoint.

So the the short answer (after this long one) is "no" at least in the short term, but perhaps "yes" in the longer term.

[scaljeri]

thanks a lot for the detailed explanation!

[cben]

Now that CommonHTML output exists, is it less dependent on layout measurements?

[dpvc]

@cben, the CommonHTML output does not rely on measuring the subexpressions, as the HTML-CSS output did. It does, however, still need to measure the ex-height of the surrounding font, and the width available for line breaking purposes, and in the case that you use characters that aren't in the MathJax fonts, CommonHTML still needs to measure those. So yes, it is less dependent on measurements, but not completely measurement free.