MathML Authoring: Notation Reference

Quick answer

MathML should describe the structure of an expression, not imitate its appearance with spaces or positioned text. Start with a <math> root, use token elements for identifiers, numbers, and operators, then combine them with layout elements such as <mfrac>, <msup>, <msub>, <msqrt>, <mrow>, and <mtable>.

A complete fraction can be written as:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mfrac>
    <mrow><mi>x</mi><mo>+</mo><mn>1</mn></mrow>
    <mrow><mi>x</mi><mo>−</mo><mn>1</mn></mrow>
  </mfrac>
</math>

The numerator and denominator are explicit child subtrees. That structure is what enables mathematical layout, conversion, selection, and assistive-technology interpretation.

Core MathML element map

Token elements are not interchangeable

Use <mi>x</mi> for an identifier, <mn>2</mn> for a number, and <mo>+</mo> for an operator. They may look similar after rendering, but their roles affect spacing, speech, line breaking, and conversion.

For example, a minus sign belongs in <mo>:

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <mi>a</mi><mo>−</mo><mi>b</mi>
</math>

Do not substitute the ASCII hyphen-minus merely because the glyph is available. Preserve the mathematical minus character and operator role so the source remains unambiguous.

Grouping and child order

MathML is an ordered tree. Child order is significant, and layout elements expect a specific number of children. <mfrac> requires a numerator followed by a denominator. <msup> requires a base followed by an exponent. A missing wrapper can change which tokens belong to an operand.

Consider the distinction between these two structures:

<!-- (a + b)^2 -->
<msup>
  <mrow><mi>a</mi><mo>+</mo><mi>b</mi></mrow>
  <mn>2</mn>
</msup>

<!-- a + b^2 -->
<mrow>
  <mi>a</mi><mo>+</mo>
  <msup><mi>b</mi><mn>2</mn></msup>
</mrow>

The rendered parentheses are not decoration; they communicate the same grouping already present in the tree.

Operators, fences, and spacing

Prefer semantic <mo> content and let the MathML renderer apply operator spacing. Avoid inserting ordinary spaces to push tokens apart. For paired delimiters, encode opening and closing fences as operators, or use authoring output produced by a trusted converter and inspect the resulting tree.

Attributes should be used only when the default operator dictionary or presentation behavior does not express the intended notation. Overriding spacing everywhere creates brittle markup and can make copied or converted expressions harder to understand.

Semantics and annotations

When an application needs to preserve the original LaTeX or another source representation, use a semantic wrapper only when the destination supports it and the annotation is accurate. A typical pattern is:

<math xmlns="http://www.w3.org/1998/Math/MathML">
  <semantics>
    <msup><mi>x</mi><mn>2</mn></msup>
    <annotation encoding="application/x-tex">x^2</annotation>
  </semantics>
</math>

The first child remains the presentation MathML expression. The annotation is supplemental source, not a substitute for a correct MathML tree.

Accessibility workflow

1. Keep the expression as real MathML in the document rather than flattening it into an image.
2. Use surrounding prose to define uncommon symbols, local conventions, and variable meanings.
3. Test keyboard navigation, selection, zoom, high-contrast presentation, and screen-reader output in the actual publishing environment.
4. When an image fallback is unavoidable, provide a text alternative that communicates the mathematical relationship, not only the visible glyphs.
5. Check that hidden fallback text is not announced together with MathML as duplicate content.

MathML alone cannot resolve ambiguous notation. The page still needs definitions such as “let μ denote the population mean” when a symbol has several accepted meanings.

Validation and browser testing

A successful visual render is not enough. Use this checklist:

• Confirm that the markup is well-formed XML-compatible MathML where required by the destination.
• Verify the namespace and root element.
• Check child counts and ordering for fractions, scripts, roots, and tables.
• Inspect the DOM to ensure a conversion pipeline did not replace MathML with an image or inaccessible canvas.
• Compare inline and block rendering.
• Test long expressions for wrapping and overflow on a narrow mobile viewport.
• Copy the expression and inspect what survives in plain text, rich text, and a second equation editor.
• Convert back to LaTeX and compare grouping, bounds, signs, and scripts.

Common MathML authoring failures

• Using <mtext> for an entire equation, which removes mathematical structure.
• Putting numbers or operators inside <mi> because the final glyph looks acceptable.
• Omitting <mrow> when a multi-token expression must act as one child.
• Drawing a fraction with a table or CSS border rather than <mfrac>.
• Adding manual spaces instead of preserving operator semantics.
• Publishing generated MathML without checking unsupported elements or attributes in the target browser.
• Assuming an annotation repairs an incorrect presentation tree.

When to use MathML, LaTeX, or Unicode

Use MathML when semantic web markup, browser-native mathematical layout, accessibility, or machine-readable structure is a requirement. Use LaTeX as an authoring and interchange source when the workflow is built around TeX syntax. Use Unicode for isolated characters in ordinary text, such as “x ≠ 0,” when a full structured expression is unnecessary.

A reliable workflow often keeps LaTeX as editable source, converts to MathML for web publication, and validates both representations. The conversion should preserve mathematical grouping rather than merely reproduce a similar picture.