<mover> to use accent instead of using default on <mo>

[NSoiffer]

This is more of a question that a direct feature request...

I believe MathML core support will move from experimental to being in the regular version of Chrome and Edge this year. Hopefully at some point in the not to distant future after that, Firefox and Safari will also move to supporting core (they are mostly a superset now, but not completely aligned). At that point, it will likely make sense to (re)create a MathML output jax.

This feature request is related to that potential output jax. One of the features that we would like to eliminate in core that is in MathML full involves accents (vs. limits). Currently, there are two ways accents are handled in MathML:

1. <mover accent='true'> <mo>^</mo></mover>
2. <mover> <mo accent='true'>^</mo></mover>, where most of the time the value of the accent comes from an operator dictionary.

MathML core is leaning strongly towards eliminating the second option. MathJaX's TeX conversion currently generates the second option. Would it the loss of the second option be a significant problem. I.e., can MathJax generate the first option instead?

For more info and discussion, see w3c/mathml-core#52

[dpvc]

Thanks for the heads up on this. I've taken a quick look at the code, and it looks like it should not be too difficult to switch to the first format.

So I guess this means that accent="true" will have to be made explicit for operators that used to get it from the dictionary (or accent="false" for ones that didn't get true from the dictionary, depending on the default value of accent on mover). That's fine for MathML generated from TeX, but for existing MathML that expects this to come from the dictionary, that will break the output. Because MathJax doesn't include an explicit accent="true" when it would have come from the dictionary, MathJax will have generated such MathML that some folks may be using if they pre-processed their pages with MathJax. MathJax could have a backward-compatibility mode to allows this to still work, or that could move accent="true" from the mo to the parent mover, I suppose.

[NSoiffer]

Yes, it will have to be explicit. Hopefully that extra verbosity won't be a problem ;-)

As for breaking existing MathML, if you read the MathML issue, you will see this is a significant concern among many in the group especially because it will break a significant amount of existing MathML, albeit the difference is only a few pixels. We have developed "polyfills" that cover over the differences between full MathML and core, so at some point there could be two MathJax options: a faster one that only targets core and a second slightly slower one that brings in some JS (perhaps based on those polyfills or rewritten) that targets full but mostly uses core. This discussion is probably jumping the gun though.

[dpvc]

OK, thanks for the clarification.