MathJax Experimental Elementary Math Extension (mml3)

[Joy Holly]

I work with math accessibility, usually high school level math, but currently have a client who has a lot of elementary math content. Since the MathML specification says to use the elementary math tags for elementary math formulations, my client wants to comply with this standard. In particular, to solve their "elementary vertical math problem" as they call it, they want to use mstack. And Wiris's MathType helpfully provides a symbol for stacked addition for educators to use, which outputs a vertical math formulation using mstack, that is unhelpfully not supported so does not display because it and the other elementary math tags are not part of MathML core. (The client's content is on a custom LMS running MathJax 4.)

I'm trying to advise them what their best options are (stable, accessible now, and as future-proof as possible.) The math content they produce for their web content  (and epub documents) needs to not only display correctly but also be accessible to screen readers.

I'm going to suggest they try loading MathJax's "Experimental mml3 Extension" to see if it will at least enable use of uncomplicated builds using mstack (no cross-outs or carries).

Does anyone know how "experimental" this experimental extension is? I'm trying to find out more about it before we try to do tests with it so I know what to expect (what might work and what might not work.)

I was hoping this extension would enable them to do what they want to do, comply with MathML specifications for elementary math (at least at the basic level) while also meeting accessibility requirements (while being well-positioned for the future, if MathML core ever does include elementary math). If the mml extension does not bridge the gap between recommended specification and support, then they will have to stick with MathML core formulations for vertical math (like mtable.)

Any feedback about elementary vertical math and the mml3 extension?

Thank you!
-Joy

[Davide Cervone]

I'm going to suggest they try loading MathJax's "Experimental mml3 Extension" to see if it will at least enable use of uncomplicated builds using mstack (no cross-outs or carries).

That was going to be my suggestion as well.

Does anyone know how "experimental" this experimental extension is? I'm trying to find out more about it before we try to do tests with it so I know what to expect (what might work and what might not work.)

It is experimental in at least two senses:  first, because it doesn't implement all the elementary math features, but more importantly, because it uses an XSLT transform to convert the elementary MathML tags into other presentation MathML that should be equivalent.  That transformation isn't perfect, and can produce ugly or incorrect results in some cases.  You will have to try it out to see if it is sufficient for your needs.

I was hoping this extension would enable them to do what they want to do, comply with MathML specifications for elementary math (at least at the basic level) while also meeting accessibility requirements

because this is an automated transformation, the resulting presentation MathML may not be the best possible representation of the original intent and so the speech-text that is produced from it might not be all that great.  In particular, the speech will be about tables and rows, so may not relate the original structure in the most meaningful way.

(while being well-positioned for the future, if MathML core ever does include elementary math).

I am not involved in the development of MathML-Core, but I would be surprised if the elementary math elements were ever included there.  I doubt that you will see native browser support for those tags any time soon.

I'm trying to advise them what their best options are (stable, accessible now, and as future-proof as possible.)

The problem with the mml3 extension is that it is XSLT based.  This technology has been deprecated recently, and it looks like most browsers will drop support for it by the end of the year.  So the current mml3 extension will cease to work when that occurs.

There are three possible solutions:

1. MathJax could include a javascript-based XSLT translator as part of the mml3 extension.  (Easiest solution, but not any kind of improvement.)
2. The translation process could be converted to javascript, say as a MathML input jax pre-processor, rather than through XSLT.  This would make it potentially possible to improve the conversion to handle more structures or attributes that are harder to do with XSLT.
3. Implement support for the elementary MathML tags in the MathJax output jax.  This is the ideal solution, but also the most difficult.

Better support for the elementary MathML tags has been on our wish list for years, but we don't have the resources to pursue all the directions we would like to, and it is not a high priority for our sponsors, who mostly need mathematics at a college level and above, so we have not been able to put much effort into this.  If anyone is interested in sponsoring the development of one of these options, that could change the calculus involved, however.

I hope this information helps you understand the situation better.

Davide

[Joy Holly]

Thank you, Davide,

This helps a lot and is exactly the kind of feedback I hoped for (even though I didn't like hearing that I shouldn't put much hope into the experimental mml3 extension as it is not only experimental but, more importantly, also about to be obsolete since it is based on XSLT. That knowledge was a thought-changer for me so thank you so much!)

I was also having a discussion in the W3c MathML-core github right now and they mention an elementary math polyfill as another option for interpreting elementary MathML elements. However, currently it is not passing the MathML to screen readers, so is not accessible. But if this accessibility problem is cleared, I might look into trying this. But since an installation of MathJax is already implemented, v. 4, do you know if a polyfill implementation could happen at the same time (like the polyfill loads first and then its input informs the MathJax implementation or something like this--I'm not a javascript programmer) or would it cause conflicts?

Below is part of my discussion with David Carlisle from the Elementary Math discussion on github. (full discussion here: https://github.com/w3c/mathml-core/issues/334) 

The grey part is what I wrote and David Carlisle's comment starts with "hmm." What are your thoughts about his last statement in this excerpt about MathJax?:

At this point in my response, I jumped over to a MathJax users forum where I had asked about the elementary math extension to see if anything there informed the discussion here. A responder informed me that the biggest issue is that the mml3 extension uses XSLT and support for XSLT will be dropped by all major browsers by the end of the year. So it appears the MathJax elementary math extension, unless reworked to not rely on XSLT, is not really an option.

hmm the original mathjax content mathml extension also was originally based on xslt and sometime (a decade or so ago) I translated that to javascript and donated it to mathjax (who reworked it a bit but basically the same) the same basic technique could be done for the elementary math (basically a few javascript helper functions have enough of a structure that you could more or less directly rewrite the xslt into javascript.
Or they could use a modified version of Neil's elementary math polyfill which similarly rewrites the elementary math into mathml that mathjax would understand (although as the browser would understand it directly as well)

I wrote all the above then something at the back of my head made me check

https://github.com/davidcarlisle/web-xslt/blob/e2d0023bd9b0e5f0538e2ec3df34a5ec5872f549/ctop/mml3mml2.js#L2

I did in fact include the elementary math elements as well as the content mathml in the javascript version of my translation, so mathjax could easily pick that up if they wanted to.

My current recommendation to my client is going to be to restrict math formulations to MathML Core for now. (But I'll keep an eye on developments that could make it practical to start using the more semantically appropriate elementary math elements.)

Thanks so much for your input!

-Joy

--
You received this message because you are subscribed to the Google Groups "MathJax Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathjax-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mathjax-users/D1DA9DF9-9023-4196-BF32-16D00240DE7F%40gmail.com.