WeBWorK: use server's MathJax config - #3172
Conversation
5b348a5 to
4b846c8
Compare
|
This was rebased after #3147 was merged. I tested, and things are still working as expected. |
|
We have had enough problems with MathJax running in different contexts (knowls, Runestone assignment builder) that it makes me nervous to cede more control to whatever configuration WW is producing -- now, or later. Yes, I know this is inside an More coming from Claude, just now. |
|
Verified the 2.19 claim from source rather than by probing paths: One change I'd ask for before this goes in. The iframe stops honouring Today that is harmless, and I confirmed it: the iframe contains no But it leaves the iframe running a different math-processing contract from every other page PreTeXt produces, and that is the part I think is worth not accepting. On an ordinary page, It also becomes a standing dependency on a third party: whether PreTeXt's own class is honoured is now decided by whatever webwork2 ships next. Keeping the server config wholesale and re-asserting just this one PreTeXt-specific option costs one line, between the config script and '<script>if (window.MathJax) (window.MathJax.options ||= {}).processHtmlClass = "process-math";</script>' +I tested that: the server's AsciiMath additions all survive, Two smaller notes. Worth saying out loud in the description, because it undersells the change: the server config is not just the old config relocated. It adds AsciiMath triggers for consistency with MathObjects — The readability pass missed one line two below the converted block, still concatenated while its neighbours are template literals: '<script src="' + ww_domain + '/webwork2_files/node_modules/iframe-resizer/js/iframeResizer.contentWindow.min.js"></script>' +Claude Opus 5, acting as a review assistant for Rob Beezer |
|
Imo Claude is just wrong here, missing some context needed to understand everything. This passage in particular:
as well as its commentary on I think there is a Monday morning drop-in session, and I'll go there. Unless anyone thinks I really should try to explain in writing here. |
|
Hmm, drop-in is Tuesday this week, not the Monday that I thought. And tomorrow (Tuesday) I have conflicts. So I will try to discuss here. Apologies in advance I can't be brief.
We put a static representation on a web page, with an Activate button. That button creates an iframe where a live exercise will render. There are two (and only two) reasons why we do not just directly let the iframe have a
So what we do is build a Worth noting: WeBWorK/PG stopped using a javascript-based knowl mechanism for solutions and answers a few versions back. Solutions and hints are just handled with native HTML
OK, so Claude is talking about So this sentence from Claude starting out as "The iframe is not foreign territory ..." is a misunderstanding. The body content of the iframe really is foreign territory coming from the webwork2 server. It won't ever "pull more PreTeXt HTML" in the way Claude is describing. And then to step back, it is right to let the math content of the exercise be governed by the webwork2 server's MathJax config. That content was born where that particular config has been curated. Back in the day, the webwork2 server did not serve a standalone MathJax config file. Rather, webwork2 wrote the config into each page, inline. So we were forced to make this MathJax config here that the PR wants to eliminate. But now that we are supporting only 2.19+, the need is gone. Meanwhile, these exercises were never using the "real" MathJax config that PTX uses. They have been using the config being deleted here. I can't explain why As far as Runestone's interests goes, that's all about intercepting the answer hash to record scores and answer attempts, not what the math looks like. All this time in RS, even in the Assignments page, the math has rendered based on the stale MathJax config being deleted here. Not a good MathJax config that PTX usually uses, or a good one that RS usually uses. The post has gotten long enough, so I'll see if there's response from anyone (be they human or Claude) about this. I'll just note that for 2.21, the drift on the WW config is going to be significant. This is where WW/PG upgraded to MJ4. And now with 2.22 under devlopment, more as WeBWorK/PG moves away from using script tags to delimit math, and simplifies to just using |
2 participants
Head up: I don't think this clashes with #3147, but all the same, it would be better to process #3147 before this one.
In the past, when we supported old versions of WeBWorK, we needed to hard code the MathJax config here in
pretext-webwork.js. Now that we only support 2.19 and 2.20, we do not need to do that, and we should use the webwork2 server's MathJax (v3) config. So that is the main change here. Most of the red in the diff here is replaced by one line of green at the new line 345.Nearby, I changed some lines to interpolate a js variable, to make the code more readable.
Tested directly with 2.20. For 2.19, I located some live 2.19 servers and just checked that the path which is used here for a MathJax config file is valid on those servers. So it should work exactly the same.
[Sometime coming up soon, we will add support for 2.21 (with MJ v4). The change here will make that project cleaner. But I want to be clear that this PR alone is not bringing support for 2.21.]