Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
MathML and the math tag - MathJax without JavaScript
What is MathJax?
Some Codidact communities have MathJax enabled, which allows displaying mathematical notation within a post. This is not enabled for all communities, partly because displaying it involves downloading additional JavaScript, and also a small delay while that JavaScript runs. The page is not displayed correctly until both of those steps have completed, which can be particularly noticeable on a slow connection or a slow device.
What is MathML?
Another way of displaying mathematical notation is with the <math> HTML tag, which allows including MathML which tells the browser what to display directly, requiring no JavaScript to be downloaded or run. As this is built in to all modern browsers, the mathematical notation can be viewed by anyone, even if they have JavaScript disabled.
Currently this is blocked for Codidact, but only because all HTML tags are blocked by default until added to the list of allowed tags.
Does MathML work on my device?
I've made a simple example using the <math> tag which you can use to find out whether it displays correctly on your browser/device. If you want to see the best your device can show, view the third link in the example.
I'll relegate my testing results to a footnote[1], but the summary is that including mathfonts (still no JavaScript) makes a significant improvement to appearance across all browsers and devices I tested (second link in the example), and Firefox seems ready (desktop and mobile) and Chromium based browsers seem almost ready (based on the small sample of mathematical notation I tried). Further reading suggests the only problem I found (Chromium browsers don't display blackboard bold) is a MathJax problem rather than a Chromium problem[2], so it should be possible to produce MathML that works for all browsers (third link in the example).
Let's keep MathJax
I'm not suggesting that we stop using MathJax. Many people are already familiar with its syntax (which is significantly less verbose than the MathML used in a <math> tag). MathJax is also necessary in order to display all of the past MathJax based posts.
Uses for the <math> tag
This post is to start a discussion about whether the <math> tag might have a place alongside MathJax. Should we give users both options, in the same way that we currently allow both Markdown and HTML in posts?
There might also be the possibility of a compromise approach that could give us some of the benefits of each. MathJax supports conversion to MathML[3], so I wonder if it would be possible to use MathJax to display mathematical notation in the preview during editing, but store a second copy as MathML in a <math> tag when it is saved. This way editing would be easy for people familiar with MathJax, but there would be no delay in displaying it for anyone reading rather than editing, and it would display even with JavaScript disabled.
Posts are already stored in duplicate on the server, as both Markdown (for editing) and HTML (for display), which means there is no rendering delay when reading a (non-MathJax) post. This would simply be applying the same approach to mathematical notation, so there would be no rendering delay even for MathJax posts.
What are your thoughts?
The <math> tag and MathML are new to me, so these are just my initial thoughts. I'd like to hear from people who have a better idea of how it could work, and any concerns from people who currently use MathJax (or even from people who don't want mathematical notation to be possible in their Codidact community - should this be a community level option like MathJax currently is?).
-
I've tested on the following:
- Firefox on Fedora Linux: displays clearly and scales correctly.
- Chromium on Fedora Linux: displays clearly, scales correctly, missing double-struck section on the black board bold N, slightly oversized start and end values on the product (upper case pi), and the double height parentheses are displayed as single height, but still readable.
- Firefox on Android: displays clearly, scales correctly, but the upper case pi is using a sans serif font which looks unusual but is still readable.
- Chrome on Android: displays the individual symbols clearly, but does not align them correctly so they overlap and are difficult to read, and the alignment is different for the 2 different display sizes in the example. Same sans serif pi as Firefox on Android. Missing double-struck section on the black board bold N and the double height parentheses are displayed as single height, both similar to Chromium on Fedora Linux.
- Edge on Windows 11: Same missing double-struck section on the black board bold N, presumably due to being Chromium based, but everything else looks good. The pi is large and has serifs and the double height parentheses are displayed correctly.
The sans serif pi is due to the lack of a suitable font already installed on the phone. If Codidact used MathML, a suitable font could be included. This would only slow down loading on the first visit, and the fall back would still be readable mathematical notation, rather than the current fall back during a slow load, which is raw MathJax markup.
Testing the same browsers with the same page except including mathfonts (the second link in the example):
- Firefox on Fedora Linux: looks very similar.
- Chromium on Fedora Linux: looks much better. The pi is bigger, making the start and end values look less out of place, and the double height parentheses are now displayed at the correct height. Still missing the double-struck section on the black board bold N.
- Firefox on Android: the upper case pi is now using a serif font which looks much more recognisable and is also bigger so it fits better with the double height parentheses.
- Chrome on Android: now much easier to read, with no overlap between symbols. The pi is now serif and is much larger and double height parentheses are now displayed at the correct height. Still missing the double-struck section on the black board bold N.
- Edge on Windows 11: looks very similar. The missing double-struck section on the black board bold N does not appear to be a font problem but a Chromium bug (since it continues even when a font is supplied).
I haven't tested on any MacOS or iOS browsers. I'd be interested to hear from anyone who does. ↩︎
-
The failure to display blackboard bold in Chromium based browsers was raised as a bug and closed as WONTFIX because there is a more recently specified way to markup blackboard bold, and this does work in Chromium. The third link in my example shows how this looks, which works in all Chromium based browsers. If a later or future version of MathJax outputs MathML compatible with the latest MathML Core specification then Chromium based browsers will work fine. Otherwise we could use an alternative library to produce MathML, so this doesn't seem like an obstacle to saving a copy of the post as MathML to avoid the delay in displaying a post. ↩︎
-
Try right clicking on any of the mathematical notation in a MathJax enabled Codidact post such as my Prime factor pattern in numbers one less than a power of 2 to see it automatically converted to MathML. That's how I got the MathML for the example page. ↩︎
Allow use of the `` tag directly Whether we convert MathJax to MathML behind the scenes or not, users should be able to …
20d ago
Render MathJax faster Whether we decide to allow direct use of the `` tag in posts or not, we should use MathML behind …
23d ago
Yes, the <math> tag should be enabled across all Codidact. I didn't know such a tag existed until now, but that …
26d ago
3 answers
Allow use of the <math> tag directly
Whether we convert MathJax to MathML behind the scenes or not, users should be able to directly add <math> tags to their posts.
We currently allow both Markdown and HTML in posts. Markdown has the advantages of being quicker to write and easier to read when not rendered (such as during editing). HTML has the advantage of allowing some things that are not possible in Markdown, such as collapsible hidden sections using a <details> tag.
Similarly, I'd like to see both MathJax and MathML allowed in posts. MathJax has the advantages of being quicker to write and easier to read when not rendered. MathML has the advantages of rendering faster and not requiring JavaScript to be enabled.
Communities that do not have MathJax enabled
- For communities that already have MathJax, I'd like to see MathML available too.
- For communities that do not have MathJax, I'd still like to see MathML available.
Unlike MathJax, which slows down page loading and increases data usage due to the extra JavaScript that must be loaded, MathML is built into the browser so enabling it will have no effect on loading time or data usage. I see no reason to have a community-specific switch for MathML. We can simply stop blocking it for all communities, and let the browser handle it automatically.
MathML is straightforward to enable
No code change is required to allow the use of a <math> tag in a post. All that is required is to add 'math' to the list of allowed tags[1]. I've tested this in my local development environment. Here's a comparison of MathML then MathJax in a post:
The first of each pair is MathML, the second is MathJax. In this screenshot they look identical. They look this this in both the editor preview and the saved post. In the live post that I'm viewing locally, the only difference is that if I press refresh the MathJax versions momentarily turn back to raw MathJax, whereas the MathML stays as mathematical notation. The raw MathML never shows, even on a slow connection, in the same way that raw HTML never shows, even on a slow connection.
The MathML and MathJax used to produce this screenshot
A fraction inline in the middle of a sentence <math>
<mfrac>
<mrow>
<mn>1</mn>
<mo>+</mo>
<mn>4</mn>
</mrow>
<mn>23</mn>
</mfrac>
</math> as an example.
A fraction inline in the middle of a sentence $\frac{1+4}{23}$ as an example.
A fraction on its own line:
<math display="block">
<mfrac>
<mrow>
<mn>1</mn>
<mo>+</mo>
<mn>4</mn>
</mrow>
<mn>23</mn>
</mfrac>
</math>
A fraction on its own line:
$$\frac{1+4}{23}$$
On a community that does not have MathJax enabled (or for a user who has JavaScript disabled), that same post looks like this:
The MathJax versions are not rendered, showing instead as raw MathJax, but the MathML versions are correctly rendered as mathematical notation. Notice that the MathML is rendered in a slightly different font when MathJax is not enabled, but it is still in the correct format. If we wanted perfect replication of the look that MathJax gives, we could include the relevant font in Codidact pages. This would only need to be loaded the first time a Codidact page is viewed, and during that brief loading time the MathML would already be correctly displayed, just in a slightly different font - no raw markup.
-
To be useful, we'd also need the tags that are used inside a
<math>tag, such as<mn>,<mo>,<mfrac>,<mrow>, but this is still just a matter of adding them to the list of allowed tags. To allow mathematical notation on its own line (rather than inline in a sentence) we'd also need to add 'display' to the list of allowed attributes, to allow<math display="block">, but that's the full extent of the changes I needed to make to get this working in my local development environment - simply adding names to 2 lists. ↩︎
0 comment threads
Render MathJax faster
Whether we decide to allow direct use of the <math> tag in posts or not, we should use MathML behind the scenes so that posts containing MathJax render quickly even on a slow connection, rather than having to wait for JavaScript to load and run. This will also allow users with JavaScript disabled to view posts containing MathJax.
No difference for authors and editors
The user experience when writing MathJax will be the same as currently. Editing an existing post containing MathJax (whether written before or after we start using MathML in the background) will still involve writing MathJax rather than MathML. Users who want to continue writing and editing MathJax will see no difference during editing. The only difference visible to users will be the faster rendering[1].
No need to see or even know about MathML
Users writing MathJax will never need to see the MathML that is used in the background, in the same way that users writing Markdown never need to see the HTML that is used in the background.
-
All posts created or edited after the introduction of MathML will render faster and be visible even to users with JavaScript disabled. Posts last edited before the introduction of MathML will still render more slowly (the current speed), until they are next edited. We could optionally also discuss running an automated update of all old MathJax posts to use the new faster rendering (they would look identical other than rendering faster) but I'd like to see this change whether it includes old posts or not. ↩︎
0 comment threads
Yes, the <math> tag should be enabled across all Codidact.
I didn't know such a tag existed until now, but that is clearly the "right" way to show equations when writing in HTML.
The reasons to enable it across all of Codidact are:
- Unlike MathJax, it doesn't get in the way of ordinary text or HTML. There is no downside for sites that don't think they will ever use mathematical equations.
- It's the standard. MathJax served its purpose when there was no alternative. Now there is an official standard one. Codidact should be embracing and encouraging the use of such standards, especially when it doesn't get in the way unless explicitly envoked.
- It's built into the browser. There is no need to load some third party code.
- It's more future-proof. Some years from now when the world has converged to use the built-in HTML for math equations, MathJax will be a footnote in history. The ability to render MathJax will likely still be there for a while yet to come, but eventually it will fade away.
1 comment thread