Delay showing problem content until after MathJax content has rendered.#3003
Delay showing problem content until after MathJax content has rendered.#3003drgrice1 wants to merge 1 commit into
Conversation
|
When viewing a problem in a new window in the problem editor. The problem content flashes twice while loading. Should the 'hidden' content not be added via javascript, but just default in the templates? |
|
I guess this can be done in CSS, just make |
|
The |
|
I suppose an alternative that uses CSS would be to have a body.problem-hidden .problem-content {
visibility: hidden;
}and then have something like if (!window.MathJax) {
document.body.classList.remove('problem-hidden');
}in every page (after the startup: {
pageReady() {
return MathJax.startup.defaultPageReady().then(() => document.body.classList.remove('problem-hidden'));
}
},in the MathJax configuration. That would save having to loop through all the problems and handle them individually. |
|
Sorry, it should be |
|
At this point We have also talked about removing the image display mode entirely. It isn't accessible, and realistically no one uses it anymore. I sort of would like to keep the handling of this contained to the |
|
@drgrice1, makes sense. I was just offering ideas. Do what works best for you all. |
This was suggested by @dpvc in openwebwork/pg#1431. The point is to prevent the visual motion that occurs while the MathJax content is rendered. This doesn't use the `#problem_body` id selector since that is not on all problems (it isn't in Gateway tests), but uses the `.problem-content` class selector instead, since that is on all problems. Also, a `for of` loop and `document.querySelectorAll` is needed for tests, since there can be more than one problem. I am not entirely sold on the empty area shown in the mean time, but it does prevent the jitter for the text within the problem. Perhaps if someone wants to toy with css, a loading block could be shown with a transition that fades in the problem when the MathJax rendering is completed. Note that webwork2 renders MathJax in places outside of the problem content, and those will not be affected by this.
drgrice1
force-pushed
the
mathjax-delay-show-problem
branch
from
dc6288e to
89d67e3
Compare
|
For a problem in an assignment, this is working for me as described. But this is causing nothing to appear in the Library Browser until all the problems render, which takes a while. The current behavior that you implemented a few years ago, where we get to see problems render sequentially, is nice. You can at least start reading some of the exercises right away. Less important. When I'm in the problem editor, the Preview, Check, and Show Correct buttons still jump. Somehow that does not happen with the buttons in a problem within a set, so maybe that can be made to happen with the Problem Editor buttons as well. |
|
I am not seeing the behavior you describe. In the library browser, I see the first problems appear while problems below are still rendering. Since each problem renders in a separate iframe each with their own MathJax instance, I don't see why one problem would wait for another to show up. This will be the case for multiple problems on a page in a gateway test. There they will all show up essentially at the same time. In the problem editor I also don't see the buttons jump. @somiaj mentioned the problem content flashing twice while loading in the problem editor, and I also don't see that. For me the problem starts out hidden, and then appears. There is no perceivable initial flash of the content for me. |
|
Wonder what was causing the flash for me, I can't reproduce it anymore either. The problem did have a matrix answer array in it, but I can't recall which problem I was actually testing. But something was causing some rendering to show content before the javascript hid the |
Hmm, this is frustrating. I went to test this again. Clean restart of webwork2 on the appropriate branches. I went to my test course, to the Problem Editor, and it loaded the problem I had in there from some earlier testing. And I saw the buttons jump. I reloaded the problem, and they still jumped. Not thinking, I restored the default problem, and I can't get the buttons to jump now. I've tried other problems, including ones I think I was recently testing with, but can't get the behavior. I did not pay attention to the problem that was there when I first visited, or what about it might be special. In the Library Browser, it seems my issue is not specific to this branch. Even in WeBWorK-2.21, if I go directly to it and leave all the default OPL search settings in place. And nothing happens for 48 seconds. Then the whole page flashes and all of the exercises start loading in the usual cascading way. Actually if I go to the |
|
Could it be something with the OPL, maybe run the script that updates the OPL for the database it uses to list problems? |
|
I updated the OPL (main branch) and rand |
|
Ok, the flashing buttons in the Problem Editor are also something I see on WeBWorK-2.21, not specific to this branch. I see it with the testing problem from openwebwork/pg#1429. And I guess what is happening there is that the problem loads, and then the drag-n-drop bins are created, and in between there is a brief moment where I see the buttons high up. So it's specific to the js involved with that problem. So neither of my issues are with this PR :) The library browser thing is concerning, but perhaps we can investigate next week. |
This will happen with problems that use the draggable proof or draggable subsets macros, as well as problems that use the graphtool. This can also happen with MathJax content. For example with the following problem: DOCUMENT();
loadMacros('PGstandard.pl', 'PGML.pl');
BEGIN_PGML
[```
\begin{aligned}
\int \frac{4x^4 + 5x^3 + 110x^2 + 128x + 175}{x^3 + 25x} \,dx
&= \int 4x + 5 + \frac{7}{x} + \frac{3x+3}{x^2 + 25} \,dx \\
&= \int 4x + 5 + \frac{7}{x} + \frac{3x}{x^2 + 25} + \frac{3}{x^2 + 25} \,dx \\
&= 2x^2 + 5x + 7\ln\left(\left|x\right|\right) + \frac{3}{2}\ln\left(x^2 + 25\right) + \frac{3}{5}\tan^{-1}\left(\frac{x}{5}\right) + C.
\end{aligned}
```]
END_PGML
ENDDOCUMENT();In all of those cases the initial HTML for the page is not as tall as the HTML that results after JavaScript acts. As a result the initial height of the problem content div is less than the final rendered result. Thus you get the content below the problem content div being pushed down. Since with this pull request the problem content div is not visible, it gives the effect of the buttons jumping down. It is particularly aggravated with a problem that uses the drag and drop macros or the graphtool without much else in the problem. This is because the problem content div initially has almost no height until the drag and drop or graphtool javascript adds the content and it is all resized, giving the effect of the buttons looking like they are at the top in the problem editor and then jumping way down.
Yeah, I am not sure what is going on with this. It is worth looking into. |
4 participants
This was suggested by @dpvc in
openwebwork/pg#1431. The point is to prevent the visual motion that occurs while the MathJax content is rendered. This doesn't use the
#problem_bodyid selector since that is not on all problems (it isn't in Gateway tests), but uses the.problem-contentclass selector instead, since that is on all problems. Also, afor ofloop anddocument.querySelectorAllis needed for tests, since there can be more than one problem.I am not entirely sold on the empty area shown in the mean time, but it does prevent the jitter for the text within the problem. Perhaps if someone wants to toy with css, a loading block could be shown with a transition that fades in the problem when the MathJax rendering is completed.
Note that webwork2 renders MathJax in places outside of the problem content, and those will not be affected by this.