bootstrap code styling

[Alex-Jordan]

Here's a screenshot from an exercise we use:

A student complained that the "P" and "C" in the instructions are too small and at first they thought these were lowercase. It turns out those are coming out at 0.875 scale. It seems this is bootstrap styling for a code HTML element, which is what PGML does for [| ... |]*.

Should we make [| ... |]* doe something else? Maybe still code, but styled at 100%?

[drgrice1]

We can see what can be done about that. However, I would also say that the "P" and "C" here should really not be code. Those should be math mode typeset with MathJax.

[Alex-Jordan]

That's fine for this one, but in general this is used when trying to tell the student what to type. I have no opinion on using the HTML code element, just something that is monospace.

[Alex-Jordan]

I suppose if this comes to not using code here, it is a pg issue, not a webwork2 issue.

[drgrice1]

I was not saying that the code font size shouldn't be fixed. I was just pointing out that particular case.

[drgrice1]

I am not sure how much of a problem this really is. That particular case is a case where code shouldn't be used. If I use code with more general text then the size doesn't really seem off. Here is a screenshot:

On the top line the code text size isn't that different than the size of the other text. On the second line you can compare the sizes of math typeset via MathJax, code, and regular text.

[somiaj]

To me I have never liked the default bootstrap color for code blocks and find that harder to deal with than the size.

[drgrice1]

Yeah, the contrast is not sufficient against the problem background color.

[drgrice1]

If you want to play with the style for code tags in a problem, the best place to do this is in the pg/htdocs/js/Problem/problem.scss file. I suggest adding a rule in the .problem-content section like

	code {
		--bs-code-color: black;
	}

This will specifically override Bootstrap's color. You could also just use color, but this has the advantage of if the problem is rendered on another system where Bootstrap is not present, and that system has a better color choice for code tags, then that color will be used. If you want to force the color anywhere a problem is rendered, then just use color.

Of course you can also play with the font size if you like.

I don't use this in problems. I don't have any situation in any of my problems where I think that a code tag or more generally a monospace font is appropriate. So you should try this out with the problems where you use this.

[Alex-Jordan]

Rebooting this.

If I override the font size, removing the bootstrap application of 0.875em to an HTML code element, I do not see anything bad happen. It doesn't make the font so large that things look bad, imho. And yes the text looks bigger than surrounding regular text, but I like it that way, making it more clear that this is monospace font that is supposed to stand out from the surroundings for some reason. It does also increase the contrast between upper and lowercase letters.

Before:

After:

Perhaps the original line here should use math mode for the "S". But the line is about instructing someone how to type in the answer more than what variable to use. If the answer were on paper, a lowercase "s" would be fine. And I lean toward using monospace "S" for keyboard entry instructions.

[drgrice1]

The only reason that a lower case "s" may be accepted on paper is because of the difficulty distinguishing from an upper case "S". I deduct points when the wrong case is used for a variable in my classes. Case matters. There are numerous situations in math and the sciences where both the upper and lower case letter are used to represent different quantities.

Leaning toward using mono space for keyboard instructions is also incorrect. You should use what the typed character appears as in the answer input. With MathQuill that is not mono space.

That being said, if you want to change the style for code in problems, then I am okay with that. Put in a pull request, and we can see how it works.

[Alex-Jordan]

OK, will do. I wanted to check in if there would just be a flat veto for modifying this bootstrap setting. While I'm at it, I'll look into the text color too.

You assume MathQuill is always in use, but in practice it is not used by all the faculty using the problem that gave rise to this issue.

[Alex-Jordan]

I see there's a misunderstanding (that is not relevant to the code font). You wrote

The only reason that a lower case "s" may be accepted on paper is because...

No, there is another reason that you just can't see because I did not share the whole exercise. Nothing in this exercise suggests any particular variable should be used. On paper it could be s, S, x, or anything really, and be correct for this style of exercise. But the MathObjects context needs one specific variable to check against, and S was chosen. So these instructions (which only appear in HTML output) clarify the variable the PG problem needs you to use. Even if others should be accepted on paper.

I know this is orthogonal to presenting it as a math variable versus a keyboard character. Just wanted to offer the full context.

[drgrice1]

You assume MathQuill is always in use, but in practice it is not used by all the faculty using the problem that gave rise to this issue.

It is worth noting that even text inputs do not use mono space fonts. At least not by default in most browsers these days.

As to the upper versus lower case, that makes sense for that problem. I was generally referring to problems where the variable does have some significance. For example, I have problems where a formula is given and the question asks the student to solve for a particular variable in terms of others. Students frequently change all variables to lower case, even though the problem has mixed case for the given variables. I actually implemented the grader for those problems to give partial credit for the wrong case and a message regarding how case does matter.