Browser Status

[ronkok]

I have created a Browser Rendering Status Report, a single document with descriptions and examples of MathML rendering issues in all three of the major browser rendering engines.

By collecting all this information in one place, I aim to clarify the existing situation. Hopefully, it will enable discussion and perhaps even motivate some work to clear up these issues.

I welcome comments on the document and I think this thread would a good place for the discussion.

[dginev]

I don't mean to impose (and maybe others can help) but since this looks like a great start the obvious direction is to suggest "more work".

Namely, it would be extra helpful if someone walks the open issues in each of the major web browsers labeled "mathml" and extract tiny samples that get added to this status report. I can even think of one way to automate that... If it sounds like a good direction?

[ronkok]

I also can think of no way to automate any contributions to this document. If people will use this thread to describe a problem or point me to a link, I'll do my best to keep the document up to date. Keep in mind that this document tracks rendering issues, not all issues. If an issue has no visible effect, I will not add it to the document.

[dginev]

I was saying I know of one way to automate this (AI can prepare a distilled report). And you are correct that there needs to be a careful manual review that they are rendering issues before contributing back. Contributing to your report is a simple PR against ronkok/Temml I imagine? It is mostly a question if you welcome something in this direction.

[tmke8]

Row 31 is just a font issue, no? The unicode selector has been working fine for me with, e.g., NewComputer Modern Math, which defines these code points correctly.

Regarding row 34, I think it's a spec issue, because the infix form of U+007C is not set to stretchy in the operator dictionary.

[tmke8]

Some other small things I've noticed:

Safari keeps the operator spacing around superscripts:

for comparison on Chrome:

though this might be a spec issue, because I can't actually find anything about the correct behavior here.

<math display="block">
    <msup>
        <mi>x</mi>
        <mo>∗</mo>
    </msup>
</math>

Chrome struggles with subscripting a "sized" fence:

<math display="block">
    <mo stretchy="true" symmetric="true" lspace="0" rspace="0" minsize="1.623em" maxsize="1.623em">‖</mo>
    <mi>x</mi>
    <msub>
        <mo stretchy="true" symmetric="true" lspace="0" rspace="0" minsize="1.623em" maxsize="1.623em">‖</mo>
        <mn>2</mn>
    </msub>
</math>

Spacing with Chrome in table row with empty elements

I also found this rendering result strange, though again, it might actually be spec-compliant:

<math display="block">
    <mtable displaystyle="true" scriptlevel="0" style="width: 100%">
        <mtr>
            <mtd style="text-align: right;justify-items: end;padding-right: 0;">
                <mo lspace="0">=</mo>
                <mrow></mrow>
            </mtd>
            <mtd style="text-align: left;justify-items: start;padding-left: 0;">
                <mi>x</mi>
            </mtd>
        </mtr>
    </mtable>
</math>

Why is there no space between the "=" and the "x"? Shouldn't the "=" have its normal rspace before <mrow>?

[ronkok]

@tmke8, I have added your new issues to the status report in rows 48, 49, and 50. You make a good point about row 34 and I have revised that row as per your comment.

Regarding row 31, you are probably correct, but I'd like to test it before I revise the report. Can you point me to a woff2 version of New Computer Modern Math?

[tmke8]

Here a woff2 of New Computer Modern Math: https://tmke8.github.io/calligraphic-math/NewCMMath-Book.woff2 (I just called woff2_compress on the .otf file).

And here a small test page to go with it: https://tmke8.github.io/calligraphic-math/

[ronkok]

Thank you. I've confirmed that the roundhand glyph issue can be resolved purely with font updates and I've revised the Status Report accordingly.

[tmke8]

I found another issue in Safari: math-depth seems to be completely ignored for <mfrac>. Consider the following:

<math display="block">
  <mrow>
    <mfrac>
      <mi>a</mi>
      <mi>b</mi>
    </mfrac>
    <mo>+</mo>
    <mstyle scriptlevel="1" displaystyle="false">
      <mfrac>
        <mi>c</mi>
        <mi>d</mi>
      </mfrac>
    </mstyle>
  </mrow>
</math>

MDN playground link

The second fraction should be smaller (\scriptsize) than the first one, and it is on Chrome and Firefox, but not Safari.

[ronkok]

@tmke8 I cannot reproduce your issue. When I point my iPad Safari at your playground link, it renders properly. You might check your system version. I believe that Apple got this working properly only very recently. I think it was iOS version 26.2 when it started to work properly for me.

[tmke8]

Yup, sorry, after updating macOS from 26.3 to 26.5, it looks correct.

[davidcarlisle]

@ronkok we discussed this issue again at today's meeting.

In its current form it's not easy to have any action that would enable us to close it.

I am going to convert it to a discussion (which is a general github feature, although not previously enabled for mathml-core).
This allows the thread to remain open for comments without having it showing up in the open issues.

It would be good if many of the specific problems shown could be made into individual web platform tests and then issues raised at the appropriate place (either the browser bug reporting sites, or as issues against the mathml-core spec if the spec needs clarifying)

[ronkok]

A MathML-Core discussion forum is an excellent place for this. Good call.

I also agree that some of the individual issues would benefit from an individual issue written at the appropriate place. It is, however, discouraging to write those issues when years go by without action. I intend to keep the Status Report page up as a one-stop demonstration of the scale of the problem.