MathML Core

W3C Editor's Draft

More details about this document
This version:
https://www.downtownmelody.com/_x/dzNjLmdpdGh1Yi5pbw/mathml-core/
Latest published version:
https://www.downtownmelody.com/_x/d3d3LnczLm9yZw/TR/mathml-core/
Latest editor's draft:
https://www.downtownmelody.com/_x/dzNjLmdpdGh1Yi5pbw/mathml-core/
History:
https://www.downtownmelody.com/_x/d3d3LnczLm9yZw/standards/history/mathml-core/
Commit history
Test suite:
https://www.downtownmelody.com/_x/Z2l0aHViLmNvbQ/web-platform-tests/wpt/tree/master/mathml/
Implementation report:
https://www.downtownmelody.com/_x/d3B0LmZ5aQ/results/?label=master&label=experimental&aligned&q=math%20%20not%28path%3A%2Fjs%29
Editors:
David Carlisle (NAG)
Frédéric Wang (Igalia)
Former editors:
Patrick Ion (Mathematical Reviews, American Mathematical Society)
Robert Miner (deceased) (Design Science, Inc.)
Feedback:
GitHub w3c/mathml-core (pull requests, new issue, open issues)

Abstract

This specification defines a core subset of Mathematical Markup Language, or MathML, that is suitable for browser implementation. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.

This document was published by the Math Working Group as an Editor's Draft.

Publication as an Editor's Draft does not imply endorsement by W3C and its Members.

This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 18 August 2025 W3C Process Document.

1. Introduction

This section is non-normative.

The [MATHML3] specification has several shortcomings that make it hard to implement consistently across web rendering engines or to extend with user-defined constructions, e.g.:

This MathML Core specification intends to address these issues by being as accurate as possible on the visual rendering of mathematical formulas using additional rules from the TeXBook’s Appendix G [TEXBOOK] and from the Open Font Format [OPEN-FONT-FORMAT], [OPEN-TYPE-MATH-ILLUMINATED]. It also relies on modern browser implementations and web technologies [HTML] [SVG] [CSS2] [DOM], clarifying interactions with them when needed or introducing new low-level primitives to improve the web platform layering.

Parts of MathML3 that do not fit well in this framework or are less fundamental have been omitted. Instead, they are described in a separate and larger [MATHML4] specification. The details of which math feature will be included in future versions of MathML Core or implemented as polyfills is still open. This question and other potential improvements are tracked on GitHub.

By increasing the level of implementation details, focusing on a workable subset, following a browser-driven design and relying on automated web platform tests, this specification is expected to greatly improve MathML interoperability. Moreover, effort on MathML layering will enable users to implement the rest of the MathML 4 specification, or more generally to extend MathML Core, using modern web technologies such as shadow trees, custom elements or APIs from [HOUDINI].

2. MathML Fundamentals

2.1 Elements and attributes

The term MathML element refers to any element in the MathML namespace. The MathML elements defined in this specification are called the MathML Core elements and are listed below. Any MathML element that is not listed below is called an Unknown MathML element.

  1. annotation
  2. annotation-xml
  3. maction
  4. math
  5. merror
  6. mfrac
  7. mi
  8. mmultiscripts
  9. mn
  10. mo
  11. mover
  12. mpadded
  13. mphantom
  14. mprescripts
  15. mroot
  16. mrow
  17. ms
  18. mspace
  19. msqrt
  20. mstyle
  21. msub
  22. msubsup
  23. msup
  24. mtable
  25. mtd
  26. mtext
  27. mtr
  28. munder
  29. munderover
  30. semantics

The grouping elements are maction, math, merror, mphantom, mprescripts, mrow, mstyle, semantics and unknown MathML elements.

The scripted elements are mmultiscripts, mover, msub, msubsup, msup, munder and munderover.

The radical elements are mroot and msqrt.

The attributes defined in this specification have no namespace and are called MathML attributes:

2.1.1 The Top-Level <math> Element

MathML specifies a single top-level or root math element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a <math> element.

The <math> element accepts the attributes described in 2.1.3 Global Attributes as well as the following attributes:

The display attribute, if present, must be an ASCII case-insensitive match to block or inline. The user agent stylesheet described in A. User Agent Stylesheet contains rules for this attribute that affect the default values for the display (block math or inline math) and math-style (normal or compact) properties. If the display attribute is absent or has an invalid value, the User Agent stylesheet treats it the same as inline.

This specification does not define any observable behavior that is specific to the alttext attribute.

Note
The alttext attribute may be used as alternative text by some legacy systems that do not implement math layout.

If the <math> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise the layout algorithm of the mrow element is used to produce a math content box. That math content box is used as the content for the layout of the element, as described by CSS for display: block (if the computed value is block math) or display: inline (if the computed value is inline math). Additionally, if the computed display property is equal to block math then that math content box is rendered horizontally centered within the content box.

Note
TEX's display mode $$...$$ and inline mode $...$ correspond to display="block" and display="inline" respectively.

In the following example, a math formula is rendered in display mode on a new line and taking full width, with the math content centered within the container:

<div style="width: 15em;">
  This mathematical formula with a big summation and the number pi
  <math display="block" style="border: 1px dotted black;">
    <mrow>
      <munderover>
        <mo></mo>
        <mrow><mi>n</mi><mo>=</mo><mn>1</mn></mrow>
        <mrow><mo>+</mo><mn></mn></mrow>
      </munderover>
      <mfrac>
        <mn>1</mn>
        <msup><mi>n</mi><mn>2</mn></msup>
      </mfrac>
    </mrow>
    <mo>=</mo>
    <mfrac>
      <msup><mi>π</mi><mn>2</mn></msup>
      <mn>6</mn>
    </mfrac>
  </math>
  is easy to prove.
</div>
math example (display)

As a comparison, the same formula would look as follows in inline mode. The formula is embedded in the paragraph of text without forced line breaking. The baselines specified by the layout algorithm of the mrow are used for vertical alignment. Note that the middle of sum and equal symbols or fractions are all aligned, but not with the alphabetical baseline of the surrounding text.

math example (inline)

Because good mathematical rendering requires use of mathematical fonts, the user agent stylesheet should set the font-family to the math value on the <math> element instead of inheriting it. Additionally, several CSS properties that can be set on a parent container such as font-style, font-weight, direction or text-indent etc are not expected to apply to the math formula and so the user agent stylesheet has rules to reset them by default.

math {
  direction: ltr;
  text-indent: 0;
  letter-spacing: normal;
  line-height: normal;
  word-spacing: normal;
  font-family: math;
  font-size: inherit;
  font-style: normal;
  font-weight: normal;
  display: inline math;
  math-shift: normal;
  math-style: compact;
  math-depth: 0;
}
math[display="block" i] {
  display: block math;
  math-style: normal;
}
math[display="inline" i] {
  display: inline math;
  math-style: compact;
}

2.1.2 Types for MathML Attribute Values

In addition to CSS data types, some MathML attributes rely on the following MathML-specific types:

unsigned-integer
An <integer> value as defined in [CSS-VALUES-4], whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).
boolean
A string that is an ASCII case-insensitive match to true or false.

2.1.3 Global Attributes

The following attributes are common to and may be specified on all MathML elements:

2.1.4 Attributes common to HTML and MathML elements

The id, class, style, data-*, autofocus and nonce and tabindex attributes have the same syntax and semantics as defined for id, class, style, data-*, autofocus, nonce and tabindex attributes on HTML elements.

The dir attribute, if present, must be an ASCII case-insensitive match to ltr or rtl. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's direction property to the corresponding value. More precisely, an ASCII case-insensitive match to rtl is mapped to rtl while an ASCII case-insensitive match to ltr is mapped to ltr.

Note
The dir attribute is used to set the directionality of math formulas, which is often rtl in Arabic speaking world. However, languages written from right to left often embed math written from left to right and so the user agent stylesheet resets the direction property accordingly on the math elements.

In the following example, the dir attribute is used to render "𞸎 plus 𞸑 raised to the power of (٢ over, 𞸟 plus ١)" from right-to-left.

<math dir="rtl">
  <mrow>
    <mi>𞸎</mi>
    <mo>+</mo>
    <msup>
      <mi>𞸑</mi>
      <mfrac>
        <mn>٢</mn>
        <mrow>
          <mi>𞸟</mi>
          <mo>+</mo>
          <mn>١</mn>
        </mrow>
      </mfrac>
    </msup>
  </mrow>
</math>
dir example

All MathML elements support event handler content attributes, as described in event handler content attributes in HTML.

All event handler content attributes noted by HTML as being supported by all HTMLElements are supported by all MathML elements as well, as defined in the MathMLElement IDL.

2.1.5 Legacy MathML Style Attributes

The mathcolor and mathbackground attributes, if present, must have a value that is a <color>. In that case, the user agent is expected to treat these attributes as a presentational hint setting the element's color and background-color properties to the corresponding values. The mathcolor attribute describes the foreground fill color of MathML text, bars etc while the mathbackground attribute describes the background color of an element.

The mathsize attribute, if present, must have a value that is a valid <length-percentage>. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's font-size property to the corresponding value. The mathsize property indicates the desired height of glyphs in math formulas but also scales other parts (spacing, shifts, line thickness of bars etc) accordingly.

Note
The above attributes are implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.

2.1.6 The displaystyle and scriptlevel attributes

The displaystyle attribute, if present, must have a value that is a boolean. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's math-style property to the corresponding value. More precisely, an ASCII case-insensitive match to true is mapped to normal while an ASCII case-insensitive match to false is mapped to compact. This attribute indicates whether formulas should try to minimize the logical height (value is false) or not (value is true) e.g. by changing the size of content or the layout of scripts.

The scriptlevel attribute, if present, must have value +<U>, -<U> or <U> where <U> is an unsigned-integer. In that case the user agent is expected to treat the scriptlevel attribute as a presentational hint setting the element's math-depth property to the corresponding value. More precisely, +<U>, -<U> and <U> are respectively mapped to add(<U>) add(<-U>) and <U>.

displaystyle and scriptlevel values are automatically adjusted within MathML elements. To fully implement these attributes, additional CSS properties must be specified in the user agent stylesheet as described in A. User Agent Stylesheet. In particular, for all MathML elements a default font-size: math is specified to ensure that scriptlevel changes are taken into account.

In this example, an munder element is used to attach a script "A" to a base "∑". By default, the summation symbol is rendered with the font-size inherited from its parent and the A as a scaled down subscript. If displaystyle is true, the summation symbol is drawn bigger and the "A" becomes an underscript. If scriptlevel is reset to 0 on the "A", then it will use the same font-size as the top-level math root.

<math>
  <munder>
    <mo></mo>
    <mi>A</mi>
  </munder>
  <munder displaystyle="true">
    <mo></mo>
    <mi>A</mi>
  </munder>
  <munder>
    <mo></mo>
    <mi scriptlevel="0">A</mi>
  </munder>
</math>
displaystyle-scriptlevel example
Note
TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle correspond to displaystyle and scriptlevel as true and 0, false and 0, false and 1, and false and 2, respectively.

2.1.7 Attributes Reserved as Valid

The attributes intent and arg are reserved as valid attributes.

This specification does not define any observable behavior that is specific to the intent and arg attributes.

Note
These attributes are described in [MATHML4] and future versions of this specification may or may not define them. Authors should be aware that they are currently in development and subject to change.

2.2 Integration in the Web Platform

2.2.1 HTML and SVG

MathML can be mixed with HTML and SVG as described in the relevant specifications [HTML] [SVG].

When evaluating the SVG requiredExtensions attribute, user agents must claim support for the language extension identified by the MathML namespace.

In this example, inline MathML and SVG elements are used inside an HTML document. SVG elements <switch> and <foreignObject> (with proper <requiredExtensions>) are used to embed a MathML formula with a text fallback, inside a diagram. HTML input element is used within the mtext to include an interactive input field inside a mathematical formula. See also 3.7 Semantics and Presentation for an example of SVG and HTML inside an annotation-xml element.

<svg style="font-size: 20px" width="400px" height="220px" viewBox="0 0 200 110">
  <g transform="translate(10,80)">
    <path d="M 0 0 L 150 0 A 75 75 0 0 0 0 0
             M 30 0 L 30 -60 M 30 -10 L 40 -10 L 40 0"
          fill="none" stroke="black"></path>
    <text transform="translate(10,20)">1</text>
    <switch transform="translate(35,-40)">
      <foreignObject width="200" height="50"
                     requiredExtensions="https://www.downtownmelody.com/_x/d3d3LnczLm9yZw/1998/Math/MathML">
        <math>
          <msqrt>
            <mn>2</mn>
            <mi>r</mi>
            <mo></mo>
            <mn>1</mn>
          </msqrt>
        </math>
      </foreignObject>
      <text>\sqrt{2r - 1}</text>
    </switch>
  </g>
</svg>

<p>
  Fill the blank:
  <math>
    <msqrt>
      <mn>2</mn>
      <mtext><input onchange="..." size="2" type="text"></mtext>
      <mo></mo>
      <mn>1</mn>
    </msqrt>
    <mo>=</mo>
    <mn>3</mn>
  </math>
</p>
html-svg example

2.2.2 CSS styling

User agents must support various CSS features mentioned in this specification, including new ones described in 4. CSS Extensions for Math Layout. They must follow the computation rule for display: contents.

In this example, the MathML formula inherits the CSS color of its parent and uses the font-family specified via the style attribute.

<div style="width: 15em; color: blue">
  This mathematical formula with a big summation and the number pi
  <math display="block" style="font-family: STIX Two Math">
    <mrow>
      <munderover>
        <mo></mo>
        <mrow><mi>n</mi><mo>=</mo><mn>1</mn></mrow>
        <mrow><mo>+</mo><mn></mn></mrow>
      </munderover>
      <mfrac>
        <mn>1</mn>
        <msup><mi>n</mi><mn>2</mn></msup>
      </mfrac>
    </mrow>
    <mo>=</mo>
    <mfrac>
      <msup><mi>π</mi><mn>2</mn></msup>
      <mn>6</mn>
    </mfrac>
  </math>
  is easy to prove.
</div>
style example

All documents containing MathML Core elements must include CSS rules described in A. User Agent Stylesheet as part of user-agent level style sheet defaults. In particular, this adds !important rules to force writing mode to horizontal-lr on all MathML elements.

The float property does not create floating of elements whose parent's computed display value is block math or inline math, and does not take them out-of-flow.

The ::first-line and ::first-letter pseudo-elements do not apply to elements whose computed display value is block math or inline math, and such elements do not contribute a first formatted line or first letter to their ancestors.

The following CSS features are not supported and must be ignored:

  • Line breaking inside math formulas: white-space is treated as nowrap on all MathML elements.
  • Alignment properties: align-content, justify-content, align-self, justify-self have no effects on MathML elements.
Note
These features might be handled in future versions of this document. For now, authors are discouraged from setting a different value for these properties as that might lead to backward incompatibility issues.

2.2.3 DOM and JavaScript

User agents supporting Web application APIs must ensure that they keep the visual rendering of MathML synchronized with the [DOM] tree, in particular perform necessary updates when MathML attributes are modified dynamically.

All the nodes representing MathML elements in the DOM must implement, and expose to scripts, the following MathMLElement interface.

WebIDL[Exposed=Window]
interface MathMLElement : Element { };
MathMLElement includes GlobalEventHandlers;
MathMLElement includes HTMLOrForeignElement;

The GlobalEventHandlers and HTMLOrForeignElement interfaces are defined in [HTML].

In the following example, a MathML formula is used to render the fraction "α over 2". When clicking the red α, it is changed into a blue β.

<script>
  function ModifyMath(mi) {
      mi.style.color = 'blue';
      mi.textContent = 'β';
  }
</script>
<math>
  <mrow>
    <mfrac>
      <mi style="color: red" onclick="ModifyMath(this)">α</mi>
      <mn>2</mn>
    </mfrac>
  </mrow>
</math>
dom-idl example
Issue
Rename HTMLOrSVGElement and define MathMLElement in [HTML].

2.2.4 Text layout

Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. As a consequence, user agents must take into account the USE_TYPO_METRICS flag from the OS/2 table [OPEN-FONT-FORMAT] when performing text layout.

2.2.5 Focus

MathML provides the ability for authors to allow for interactivity in supporting interactive user agents using the same concepts, approach and guidance to Focus as described in HTML, with modifications or clarifications regarding application for MathML as described in this section.

When an element is focused, all applicable CSS focus-related pseudo-classes as defined in Selectors Level 3 apply, as defined in that specification.

The contents of embedded math elements (including HTML elements inside token elements) contribute to the sequential focus order of the containing owner HTML document (combined sequential focus order).

3. Presentation Markup

3.1 Visual formatting model

3.1.1 Box Model

The default display property is described in A. User Agent Stylesheet:

  • For the <math> root, it is equal to inline math or block math according to the value of the display attribute.
  • For Tabular MathML elements mtable, mtr, mtd it is respectively equal to inline-table, table-row and table-cell.
  • For all but the first children of the maction and semantics elements, it is equal to none.
  • For all the other MathML elements it is equal to block math.

In order to specify math layout in different writing modes, this specification uses concepts from [CSS-WRITING-MODES-4]:

Note
Unless specified otherwise, the figures in this specification use a writing mode of horizontal-lr and ltr. See Figure 4, Figure 5 and Figure 6 for examples of other writing modes that are sometimes used for math layout.

Boxes used for MathML elements rely on several parameters in order to perform layout in a way that is compatible with CSS but also to take into account very accurate positions and spacing within math formulas:

  1. Inline metrics. min-content inline size, max-content inline size and inline size from CSS. See Figure 1.
    Figure 1 Generic Box Model for MathML elements
  2. Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:

    1. The alphabetic baseline which typically aligns with the bottom of uppercase Latin glyphs. The algebraic distance from the alphabetic baseline to the line-over edge of the box is called the line-ascent. The algebraic distance from the line-under edge to the alphabetic baseline of the box is called the line-descent.
    2. The mathematical baseline, also called math axis, which typically aligns with the fraction bar, middle of fences and binary operators. It is shifted away from the alphabetic baseline by AxisHeight towards the line-over.
    3. The ink-over baseline, indicating the line-over theorical limit of the math content drawn, excluding any extra space. If not specified, it is aligned with the line-over edge. The algebraic distance from the alphabetic baseline to the ink-over baseline is called the ink line-ascent.
    4. The ink-under baseline, indicating the line-under theorical limit of the math content drawn, excluding any extra space. If not specified, it is aligned with the line-under edge. The algebraic distance from the ink-under baseline to the alphabetic baseline is called the ink line-descent.
    Note
    For math layout, it is very important to rely on the ink extent when positioning text. This is not the case for more complex notations (e.g. square root). Although ink-ascent and ink-descent are defined for all MathML elements they are really only used for the token elements. In other cases, they just match normal ascent and descent.
    Unless specified otherwise, the last baseline set is equal to the first baseline set for MathML boxes.
  3. An optional italic correction which provides a measure of how much the text of a box is slanted along the inline axis. See Figure 2.
    Figure 2 Examples of italic correction for italic f and large integral
    If it is requested during calculation of min-content inline size and max-content inline size or during layout then 0 is used as a fallback value.
  4. An optional top accent attachment which provides a reference offset on the inline axis of a box that should be used when positioning that box as an accent. See Figure 3.
    Figure 3 Example of top accent attachment for a circumflex accent
    If it is requested during calculation of min-content inline size (respectively max-content inline size) then half the min-content inline size (respectively max-content inline size) is used as a fallback value. If it is requested during layout then half the inline size of the box is used as a fallback value.

Given a MathML box, the following offsets are defined:

  • The inline offset of a child box is the offset between the inline-start edge of the parent box and the inline-start edge of the child box.
  • The block offset of a child box is the offset between the block-start edge of the parent box and the block-start edge of the child box.
  • The line-left offset of a child box is the offset between the line-left edge of the parent box and the line-left edge of the child box.
Figure 4 Box model for writing mode horizontal-tb and rtl that may be used in e.g. Arabic math.
Figure 5 Box model for writing mode vertical-lr and ltr that may be used in e.g. Mongolian math.
Figure 6 Box model for writing mode vertical-rl and ltr that may be used in e.g. Japanese math.
Note
The position of child boxes and graphical items inside a MathML box are expressed using the inline offset and block offset. For convenience, the layout algorithms may describe offsets using flow-relative directions, line-relative directions or the alphabetic baseline. It is always possible to pass from one description to the other because position of child boxes is always performed after the metrics of the box and of its child boxes are calculated.

Here are examples of offsets obtained from line-relative metrics:

Issue 78: Ink ascent/descent opentype/texneeds-tests
Improve definition of ink ascent/descent?

3.1.2 Layout Algorithms

Each MathML element has an associated math content box, which is calculated as described in this chapter's layout algorithms using the following structure:

  1. Calculation of min-content inline size and max-content inline size of the math content.
  2. Box layout:
    1. Layout of in-flow child boxes.
    2. Calculation of inline size, ink line-ascent, ink line-descent, line-ascent and line-ascent of the math content.
    3. Calculation of offsets of child boxes within the math content box as well as sizes and offsets of extra graphical items (bars, radical symbol, etc).
    4. Layout and positioning of absolutely-positioned and fixed-positioned boxes, as described in [CSS-POSITION-3].

The following extra steps must be performed:

Note
Per the description above, margin-collapsing does not apply to MathML elements.

During box layout, optional inline stretch size constraint and block stretch size constraint parameters may be used on embellished operators