Revert overflow-x: auto on .problem-content divs.#1445
Conversation
This was added in openwebwork#1432, but is causing problems. If an answer rule is contained in a `position: relative` parent, then the MathQuill toolbar ends up being positioned correctly, but is contained inside the `.problem-content` div, and so you need to scroll to the right to see it. Note that the `.ww-feedback-container` is `position: relative`. So any answer inside a div with that class will have this issue. An example problem for which the problem occurs is: ``` DOCUMENT(); loadMacros('PGstandard.pl', 'PGML.pl', 'parserMultiAnswer.pl', 'PGcourse.pl'); $ma = MultiAnswer(1, 2)->with(singleResult => 1); BEGIN_PGML [< Enter 1: [_]{$ma}{5} Enter 2: [_]{$ma}{5} >]{ [ class => 'ww-feedback-container ww-fb-align-middle' ] } END_PGML ENDDOCUMENT(); ``` Note that this is not a problem when using the problem editor, since the width of the `.problem-content` div is the same as its parent. So this will need to be tested in an actual set. For now the overflow is left for solutions and hints. Those won't have answer rules, and thus will also not have the MathQuill toolbar issue. So a different way to fix the issue with dark text overflowing into the dark region outside of the problem will need to be found. Any ideas?
Alex-Jordan
left a comment
There was a problem hiding this comment.
I saw the issue with the posted example and I see that this fixes that issue.
As for dark mode, it seems to me that we would just need to actually render the problem for dark mode. So its text (including math) would be white. And the problem background would be dark. I guess this would raise issues with image files that were never considered for dark mode use though.
|
What you are suggesting is that a dark mode be implemented for PG. That will take some effort. There are a lot of things to consider other than images. The webwork2 dark mode implementation not only honors the browser setting, but offers a user override of that. So, for instance, the browser can be set to dark mode, but the user can override that and still have the page displayed in light mode. So PG has to honor all of that. Also, the MathQuill implementation would need to be updated to honor dark mode or light mode however it is set. In general, almost all PG JavaScript and CSS that sets colors would have to be reviewed and updated. Finally, there is the problem authoring issue. A problem author can use custom JavaScript and CSS that makes color changes. That can only be fixed by the problem author. So this would add something new that problem authors need to think about when authoring a problem. This includes not using transparent background colors for images among other things. So in short, this is not so simple as just setting a dark background and light foreground color for dark mode. |
|
I assume you thought about this, but is there a way to keep the toolbar position but move it outside of the |
|
Doing that makes it difficult to maintain the tab order. With the current structure that is basically done using the native tab order, but if you move the toolbar somewhere else, then you would have to do so with JavaScript. In general that is a total pain to get to work right. |
|
Furthermore, positioning becomes much harder to work out as well. |
This was added in #1432, but is causing problems. If an answer rule is contained in a
position: relativeparent, then the MathQuill toolbar ends up being positioned correctly, but is contained inside the.problem-contentdiv, and so you need to scroll to the right to see it. Note that the.ww-feedback-containerisposition: relative. So any answer inside a div with that class will have this issue.An example problem for which the problem occurs is:
Note that this is not a problem when using the problem editor, since the width of the
.problem-contentdiv is the same as its parent. So this will need to be tested in an actual set.For now the overflow is left for solutions and hints. Those won't have answer rules, and thus will also not have the MathQuill toolbar issue.
So a different way to fix the issue with dark text overflowing into the dark region outside of the problem will need to be found. Any ideas?