search

openwebwork / webwork2

Course management front end for WeBWorK
http://webwork.maa.org/wiki/Main_Page
Other
144 stars 165 forks source link

Work on transition to MathJax v 3 #1013

Closed taniwallach closed 3 years ago

taniwallach commented 5 years ago

MathJax v 3 released, but requires configurations changes to use it. At present WW 2.15 and earlier should all work out of the box with MathJax v 2, but not with MathJax v 3. As a result, https://github.com/openwebwork/webwork2/pull/1012 forced the Docker setup to continue using MathJax v2.

We should work on making the necessary changes to transition to MathJax v 3.

taniwallach commented 5 years ago

MathJax version 3 release information:

The transition to MathJax version 3 requires configuration changes not yet made to WeBWorK - see https://docs.mathjax.org/en/latest/upgrading/v2.html

drgrice1 commented 5 years ago

We should consider upgrading some of the other javascript libraries that are utilized also. For example, the versions of jQuery (1.7.2) and jQuery UI (1.9.0) that WeBWorK uses are quite old (released in 2012).

taniwallach commented 4 years ago

Some related comments appear in:

drgrice1 commented 4 years ago

You should also note that there are branches in my forks of webwork and pg that upgrades webwork to use MathJax 3. See https://github.com/drgrice1/webwork2/tree/update-mathjax and https://github.com/drgrice1/pg/tree/update-mathjax.

However, I would recommend that we wait with this. MathJax 3 is still rather new, and there are some problems. For example, see https://github.com/mathjax/MathJax/issues/2249. That issue is fixed, but is not in the release. DPVC says that there will probably be another release soon that will bring the fix in, as well as some other little fixes.

pstaabp commented 4 years ago

I'm trying to integrate mathjax3 into webwork3 mainly because I am using a framework that does a bunch of javascript using webpack and mathjax2 does not play well with webpack. I agree that mathjax3 is new and there's no reason to push it into webwork2. I would wait another couple of release cycles.

pstaabp commented 4 years ago

I've been working on webwork3 and decided to use MathJax 3 and have a working version. I just noticed that @drgrice1 did this already in a bit of a different way. I had decided to write a new variable: $pg{specialPGEnvironmentVars}{MathJaxVersion} that could be either 2 or 3 so I could switch back and forth. I don't have everything switched over, but enough to get a demo working.

My question is should we go with a switch like I made or just switch over like @drgrice1 has?

pstaabp commented 4 years ago

Also, I should add that I am just pulling version 3.0.5 from MathJax from a CDN instead of our standard way pull in a version from git. I don't think this matters so much, but again, I was just trying to get things working.

Alex-Jordan commented 4 years ago

I would not like a situation where there is an assumption you are using version 3. Not until several things that are reportedly missing from v3 are there. So a switch sounds good.

Here is a page listing some issues: http://docs.mathjax.org/en/v3.0-latest/upgrading/v2.html

One issue of note that is mentioned there is that the AsciiMath processor has not been fully ported to version 3. That would impact problems using PGML and the [:...:] syntax. Another issue is all the accessibility extension stuff. That was not in place earlier, but now I'm not finding explicit mention of it missing, so maybe that one has caught up.

dpvc commented 4 years ago

@Alex-Jordan, the assistive-mml extension was added in 3.0.1, and the accessibility extensions are actually better in v3 than in v2 (the explorer is better in particular). As for AsciiMath, the v2 AsciiMath jax is hooked into v3, so you can use it, it just is a bit larger than it should be in the long run, and so takes a bit longer to download. But the functionality is there, and with browser caching, it should not be too bad.

Personally, I don't think there is anything that should be holding up moving WeBWorK to v3. The only thing would be that is has dropped support for older browsers (notably, IE before IE11). Everything else should be OK.

Alex-Jordan commented 4 years ago

@dpvc OK, thanks, I was working from old information and/or faulty memory. If this is your recommendation, I'm all for it, and also maybe it is time for PreTeXt to move forward as well.

dpvc commented 4 years ago

I think you will find that server-side v3 will be much faster than the current mathjax-node implementation. Let me know if you need assistance getting that up and running.

taniwallach commented 3 years ago

@pstaabp and @drgrice1 have both done some work on moving from MathJax 2 to MathJax 3.

@dpvc wrote:

Personally, I don't think there is anything that should be holding up moving WeBWorK to v3. The only thing would be that is has dropped support for older browsers (notably, IE before IE11). Everything else should be OK.

Are we ready to move develop (and the future WW 2.16) to MathJax 3?

@pstaabp mentioned:

Also, I should add that I am just pulling version 3.0.5 from MathJax from a CDN instead of our standard way pull in a version from git. I don't think this matters so much, but again, I was just trying to get things working.

I personally think it makes lots of sense to pull in whatever is possible from CDNs and not to keep static versions of such things inside webwork2's Git repository. The old approach just makes more work in maintaining WW.

@pstaabp asked:

I've been working on webwork3 and decided to use MathJax 3 and have a working version. I just noticed that @drgrice1 did this already in a bit of a different way. I had decided to write a new variable: $pg{specialPGEnvironmentVars}{MathJaxVersion} that could be either 2 or 3 so I could switch back and forth. I don't have everything switched over, but enough to get a demo working.

My question is should we go with a switch like I made or just switch over like @drgrice1 has?

@mgage @drgrice1 @drdrew42 - Do any you have an opinion on whether there is a good reason to make the MathJax version something which can be modified by such a control variable. I suspect that very few sites are likely to change the default, so unless we encounter serious problems with MathJax v3 in WW - in which case the transition should be delayed, it is probably cleaner and simple to make a total replacement as @drgrice1 proposed.

drgrice1 commented 3 years ago

I think we should go with a total switch to MathJax v3. I don't see any reason that anyone should really need to stay with v2.

It may be nice to allow an option to have MathJax served locally versus using a CDN. In many cases CDN's are slow to load, and the local server can do this quicker. Particularly in the case of a local server that doesn't have a particularly heavy load. Another advantage is for development purposes. Frequently having JavaScript files locally served makes it easier to do debugging and test certain changes.

drgrice1 commented 3 years ago

I also don't think that we should keep static versions of javaScript libraries in the git repository. These should be managed via a JavaScript package manager like npm or Yarn. If set up correctly, this would add a minor step to the installation of webwork.

dlglin commented 3 years ago

I agree with @drgrice1 that we should not keep static versions of external libraries in the WW git repositories. If WW requires an external package such as MathJax, then it should be listed as a dependency and not rolled into the WW code (which is the case for MathJax 2 in the current release of WW). As for local install vs. CDN, my vote is that this be made a configuration option. I think forcing people to use a CDN is unadvisable for the reasons that Glenn mentioned, as well as the fact that it introduces another point of failure for the system. The WW installation instructions/scripts will have to cover at least one option of how to install these JS libraries.

taniwallach commented 3 years ago

I think the consensus is:

  1. That there is no need to try to make it possible to switch back to MathJax 2 in future versions of WW.
  2. That use of CDN loading should be an option, and not the default.
  3. That the current develop branch (and thus WW 2.16) should move to MathJax 3.
    • Is there someone who feels that for some reason this should be pushed this off to WW 2.17 and not WW 2.16?
    • The biggest downside is probably that this and the planned major JavaScript library revisions will mean that the testing and release process will take significantly longer, so WW 2.16 will not be ready for the general public for longer.
    • The benefit is that these significant changes will be dealt with in the near future and not deferred.

About the option to load MathJax from a CDN, there is already a setting available for this, but it is hard to find it without looking for it. There are commented out sample lines in conf/localOverrides.conf.dist:

#$webworkURLs{MathJax} = "https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js?config=TeX-MML-AM_HTMLorMML-full";
#$webworkURLs{MathJax} = "https://cdn.rawgit.com/mathjax/MathJax/2.7.1/MathJax.js?config=TeX-AMS_CHTML-full";

Thus, the main CDN related task during an upgrade to MathJax 3 is to also update those lines.

It would help to put a suitable note in the installation instructions (and future release notes) about how to enable/disable use of the CDN source for MathJax.

@apizer - Would you maybe add something to the installation instructions about the CDN option.

I copies some of the comments above about CDN and what is in the webwork2 repository to https://github.com/openwebwork/webwork2/issues/1015 where I think are more relevant.

apizer commented 3 years ago

I agree we should definitely move to MathJax 3 in WW2.16

I'll add something to the install instructions for WW 2.15 about the option of running MathJax remotely by using the setting: $webworkURLs{MathJax} = "https://cdn.jsdelivr.net/npm/mathjax@2/MathJax.js?config=TeX-MML-AM_HTMLorMML-full"; which uses the latest version of MathJax 2, currently 2.7.9

Alex-Jordan commented 3 years ago

MathJax3 was activated with #1215.