Skip to content

Revert overflow-x: auto on .problem-content divs.#1445

Open
drgrice1 wants to merge 1 commit into
openwebwork:PG-2.21from
drgrice1:bugfix/revert-problem-content-overflow
Open

Revert overflow-x: auto on .problem-content divs.#1445
drgrice1 wants to merge 1 commit into
openwebwork:PG-2.21from
drgrice1:bugfix/revert-problem-content-overflow

Conversation

@drgrice1

Copy link
Copy Markdown
Member

This was added in #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?

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 Alex-Jordan left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@drgrice1

Copy link
Copy Markdown
Member Author

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.

@somiaj

somiaj commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

I assume you thought about this, but is there a way to keep the toolbar position but move it outside of the .problem-content div? (maybe have a container div .mq-tool-bar-container parent that the toolbar gets placed in)?

@drgrice1

Copy link
Copy Markdown
Member Author

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.

@drgrice1

Copy link
Copy Markdown
Member Author

Furthermore, positioning becomes much harder to work out as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants