wrong placement of MathML in SVG with Safari

[xworld21]

Issue Summary

On Safari, certain MathML-in-SVG is rendered in the top left corner of the image regardless of its intended position. This is definitely a Safari bug (reasonable guess is https://bugs.webkit.org/show_bug.cgi?id=23113), but I am hoping MathJax can include a workaround for the time being.

For instance: resetting the position and will-change CSS properties of <mjx-container> resolves the problem, although it probably messes up the alignment if the MathML is not the only content within <foreignObject>.

Steps to Reproduce:

Add MathML in the scope of a transform. For example:

<svg width="400" heigth="100" viewbox="0 0 400 100">
  <rect x="0" y="0" width="400" height="100" stroke="black" fill="none" />
  <foreignObject transform="matrix(1 0 0 1 300 0)" width="1" height="1" overflow="visible"><math>
      <mi>a</mi>
    </math></foreignObject>
</svg>

renders as

instead of

Technical details:

• MathJax Version: 3.2.2
• Client OS: Mac OS X 14.7
• Browser: Safari 18.0.1

I am loading MathJax via

<script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>

[dpvc]

I believe you are correct about the Safari bug that underlies this.

Version 4 removes the will-change CSS, and the position is only used when assistive MathML is being generated (off by default in v4).

For v3, you can use

<style>
foreignObject > mjx-container {
  position: unset !important;
  will-change: unset !important;
}
</style>

to reset those CSS styles, which should allow MathJax output to work in your SVGs.

[xworld21]

Thanks! That's reassuring.

only used when assistive MathML is being generated

Oh, so that's the actual reason for position: relative. I see now what happens without it (the assistive MathML has position: absolute and goes to the top of the outer container, typically the page). Since foreignObject acts as container, the assistive MathML stays inside, which is fine for the typical scenario (e.g. SVGs generated from TikZ).

Is position: absolute on the assistive MathML really necessary? Or is it just there to prevent an extra invisible pixel? It seems to me I can get the same visual result with -1px margins (and related adjustments, e.g. display: inline-block). In fact, I might just set up my CSS that way within foreignObject, and hope it doesn't blow up in my face later on.

[dpvc]

Is position: absolute on the assistive MathML really necessary?

It depends on one's goal. The reason this is used is so that the assistive MathML will be at the same location as the MathJax typeset math. Because many screen readers highlight the text being read (this helps some readers who are not visually impaired but have other disabilities follow the reading as it progresses), we want that highlighting to display at the location of the math when it is read. The easiest way to do that is by using an absolute position for the MathML container within a relatively positioned typeset math container.

It would be possible to do this in other ways, but they are more fragile, such as using a negative margin-left, a vertical-align value, and a width and height on the MathML container. This might also allow a breakpoint between the math any any following punctuation, which v4 currently has worked hard to prevent (I would have to check whether this CSS arrangement would prevent that or not). One could make a configuration that modified the assistive MathML output to work that way instead, though I haven't done that to test it.

[xworld21]

Thanks for the detailed answer.

This might also allow a breakpoint between the math any following punctuation

I hadn't thought of that!

At any rate: based on what you said, I will configure my MathJax so that for WebKit, in foreignObject, it uses negative margin-inline-start and similar for the assistive MathML. Screen reader outlines will look like small dots, but that seems like a reasonable price to pay for having the content in the right place. Bonus points if I can keep the punctuation at bay. I'll post my code here in case other people hit the same issue.

[dpvc]

OK. Good luck, and let us know how it works out.

[xworld21]

This is the current BookML workaround:

@media (-webkit-transform-2d) {
  foreignObject>mjx-container[jax="CHTML"] {
    position: initial !important;
    will-change: initial;
    &>mjx-assistive-mml {
      width: 1px !important;
      height: 1px !important;
      position: initial !important;
      margin-inline-start: -1px !important;
      vertical-align: 1px !important;
    }
  }
}

This renders correctly even in WebKit browsers.

[dpvc]

Thanks for the details!

[dpvc]

I believe this is fixed in v4.0, so closing.