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 at
https://www.w3.org/TR/.
Publication as a Candidate Recommendation does not
imply endorsement by W3C and its Members. A Candidate Recommendation Snapshot has received
wide review, is intended to
gather
implementation experience,
and has commitments from Working Group members to
royalty-free licensing
for implementations.
This Candidate Recommendation is not expected to advance to Proposed
Recommendation any earlier than 30 September 2025.
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 which the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
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.:
It is a huge and standalone specification.
It does not contain any detailed rendering rules.
It is not driven by browser-implementation.
It lacks automated testing.
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.
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:
<divstyle="width: 15em;">
This mathematical formula with a big summation and the number pi
<mathdisplay="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>
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.
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.
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.
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.
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.
<svgstyle="font-size: 20px"width="400px"height="220px"viewBox="0 0 200 110"><gtransform="translate(10,80)"><pathd="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><texttransform="translate(10,20)">1</text><switchtransform="translate(35,-40)"><foreignObjectwidth="200"height="50"requiredExtensions="https://www.w3.org/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><inputonchange="..."size="2"type="text"></mtext><mo>−</mo><mn>1</mn></msqrt><mo>=</mo><mn>3</mn></math></p>
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.
<divstyle="width: 15em; color: blue">
This mathematical formula with a big summation and the number pi
<mathdisplay="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>
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.
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).
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:
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.
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.
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.
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.
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 2Examples 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.
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 3Example 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 4Box model for writing mode horizontal-tb and rtl that may be used in e.g. Arabic math.Figure 5Box model for writing mode vertical-lr and ltr that may be used in e.g. Mongolian math.Figure 6Box 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:
Each MathML element has an associated math content box, which is
calculated as described in this chapter's layout algorithms using the following
structure:
The box metrics and offsets of the
padding box
are obtained from the
content box
by taking into account the corresponding
padding
properties as described in CSS.
The box metrics and offsets of the
border box
are obtained from the
padding box
by taking into account the corresponding
border-width
property as described in CSS.
The box metrics and offsets of the
margin box
are obtained from the
border box
by taking into account the corresponding
margin
properties as described in CSS.
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. The former indicates
a target size that a core operator stretched along
the inline axis should cover.
The latter indicates an ink line-ascent and ink line-descent
that a core operator stretched along the block axis
should cover.
Unless specified otherwise, these parameters are ignored during
box layout and child boxes are laid out without
any stretch size constraint.
An anonymous box is a box without any associated
element in the DOM tree and which is generated for layout purpose
only. The properties of anonymous boxes are inherited from the
enclosing non-anonymous box while non-inherited properties have
their initial value.
An anonymous <mrow> box is
an anonymous box with display equal to
block math and which is laid out as
described in section 3.3.1.2 Layout of <mrow>.
If a MathML element
generates an anonymous <mrow> box then it wraps
its children in an anonymous <mrow> box. I.e.,
its subtree in the visual formatting model is made of an
anonymous <mrow> box
which itself contains the boxes associated to the children of this
MathML element.
In the following example, the math and
mrow elements are laid out as described in section
3.3.1.2 Layout of <mrow>. In particular, the
<math> element adds proper spacing around its
<mo>≠</mo> child and the
<mrow> element stretches its
<mo>|</mo> children vertically.
The mtd element has
display: table-cell and the
msqrt element displays a radical symbol around its
children. However, they also place their children in a way that
is similar to what is described in section
3.3.1.2 Layout of <mrow>: the
<msqrt> element adds proper spacing around its
<mo>+</mo> child while the
<mtd> element stretches its
<mo> children vertically.
In order to make this possible,
each of these two elements
generates an anonymous <mrow> box.
MathML elements can overlap due to various spacing rules. They
can as well contain extra graphical items
(bars, radical symbol, etc).
A MathML element with computed style
display: block math
or display: inline math generates a new stacking
context. The painting order
of in-flow children of such a MathML element
is exactly the same as block elements. The extra graphical
items are painted after text and background (right after
step 7.2.4 for display: inline math and right after
step 7.2 for display: block math).
3.2 Token Elements
Token elements in presentation markup are broadly intended to
represent the smallest units of mathematical notation which carry
meaning. Tokens are roughly analogous to words in text. However,
because of the precise, symbolic nature of mathematical notation, the
various categories and properties of token elements figure
prominently in MathML markup. By contrast, in textual data,
individual words rarely need to be marked up or styled specially.
Note
In practice, most MathML token elements just contain simple text
for variables, numbers, operators etc and don't need sophisticated
layout. However, it can contain text with line breaks or
arbitrary HTML5 phrasing elements.
3.2.1 Text <mtext>
The
mtext
element is used to represent arbitrary text
that should be rendered as itself. In general, the
<mtext> element is intended to denote
commentary text.
If the 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 below is performed.
If the <mtext> element contains only text
content without
forced line break
or
soft wrap opportunity
then, the anonymous child node generated for that text is
laid out as defined in the relevant CSS specification and:
If the text content is made of a single glyph and this glyph
has an entry in the
MathItalicsCorrectionInfo table then the specified
value is used as the italic correction.
If the text content is made of a single glyph and this glyph
has an entry in the MathTopAccentAttachment table
then the specified value is used as the top accent attachment of
the <mtext> element.
The
mi
element represents a symbolic name or
arbitrary text
that should be rendered as an identifier. Identifiers can include
variables, function names, and symbolic constants.
The <mi> element accepts the attributes described
in 2.1.3 Global Attributes as well as the following attribute:
The layout algorithm is the same as the mtext element. The
user agent stylesheet
must contain the following property in order to implement automatic
italic via the text-transform value introduced in 4.2 The math-auto transform:
mi {
text-transform: math-auto;
}
The
mathvariant
attribute,
if present, must be an
ASCII case-insensitive
match of normal.
In that case, the user agent is expected to treat the attribute as a
presentational hint setting the element's
text-transform
property to none. Otherwise it has no effects.
Note
In [MathML3], the mathvariant attribute was used
to define logical classes of token elements, each class providing
a collection of typographically-related symbolic tokens with
specific meaning within a given mathematical expression.
In MathML Core, this attribute is only used to cancel automatic
italic of the mi element. For other use cases, the proper
Mathematical Alphanumeric Symbols [UNICODE] should be used
instead. See also section C. Mathematical Alphanumeric Symbols.
In the following example, mi is used to render
variables and function names. Note that per
4.2 The math-auto transform the default
style text-transform: math-auto has
no effect on the first <mi> ("cos" is made of three characters),
makes the second <mi> render as math italic ("c" is made of a single
character U+0063 Latin Small Letter C which is
mapped to
U+1D450 Mathematical Italic Small C per the
italic table), has no effect
on the third <mi> (overridden by
mathvariant="normal", setting
text-transform to none) or on the fourth
<mi> (no mapping defined for U+221E Infinity
in the italic table).
The
mn
element represents a "numeric literal" or
other data that should be rendered as a numeric literal. Generally
speaking, a numeric literal is a sequence of digits, perhaps including a
decimal point, representing an unsigned integer or real number.
The <mn> element accepts the attributes described
in 2.1.3 Global Attributes. Its layout algorithm is
the same as the
mtext element.
In the following example, mn is used to
write a decimal number.
<math><mn>3.141592653589793</mn></math>
3.2.4 Operator, Fence, Separator or Accent <mo>
The
mo
element represents an
operator or anything that should be rendered as an operator.
In general, the notational conventions for mathematical operators
are quite complicated, and therefore MathML provides a relatively
sophisticated mechanism for specifying the rendering behavior of an
<mo> element.
As a consequence, in MathML the
list of things that should "render as an operator" includes a
number of notations that are not mathematical operators in the
ordinary sense. Besides ordinary operators with infix, prefix, or
postfix forms, these include fence characters such as braces,
parentheses, and "absolute value" bars; separators such as comma
and semicolon; and mathematical accents such as a bar or tilde over
a symbol. This chapter uses the term "operator" to refer to
operators in this broad sense.
The <mo> element accepts the attributes described
in 2.1.3 Global Attributes as well as the following
attributes:
In the following example, the mo element
is used for the binary operator +. Default spacing is symmetric
around that operator. A tighter spacing is used if you rely
on the form attribute to force it to be
treated as a prefix operator.
Spacing can also be specified explicitly using the
lspace and
rspace attributes.
Another use case is for big operators such as summation.
When displaystyle is true, such an operator is drawn
larger but one can change that with the largeop attribute.
When displaystyle is false, underscripts are actually
rendered as subscripts but one can change that with the
movablelimits attribute.
Operators are also used for stretchy symbols such as fences,
accents, arrows etc. In the following example, the vertical arrow
stretches to the height of the mspace element.
One can override default stretch behavior with the
stretchy attribute e.g. to force an unstretched arrow.
The symmetric attribute allows to indicate whether
the operator
should stretch symmetrically above and below the math axis
(fraction bar).
Finally the minsize and maxsize attributes add
additional constraints over the stretch size.
Note that the default properties of operators are
dictionary-based, as explained in
3.2.4.2 Dictionary-based attributes. For example a binary
operator typically has default symmetric spacing around it while a
fence is generally stretchy by default.
The form
property of an embellished operator is either
infix, prefix or
postfix.
The corresponding form attribute on the
mo element, if present, must be an
ASCII case-insensitive
match to one of these values.
The algorithm for determining the form of an embellished operator is as follows:
Or, if the embellished operator is an in-flow child of a
scripted element, other than the first in-flow
child, then it has form postfix.
Otherwise, the embellished operator has form
infix.
The
stretchy,
symmetric,
largeop,
movablelimits
properties of an embellished operator are
either false or true. In the latter
case, it
is said that the embellished operatorhas the
property.
The corresponding stretchy, symmetric, largeop, movablelimits attributes on the
mo element, if present, must be a
boolean.
The algorithm for determining the properties of
an embellished operator is as follows:
If the corresponding
stretchy,
symmetric,
largeop,
movablelimits,
lspace,
rspace,
maxsize or
minsize
attribute is present and valid
on the core operator, then the
ASCII lowercased value
of this property is used.
Font-relative lengths for
lspace, rspace,
minsize and maxsize rely on the
font style of the core operator, not the one of the
embellished operator.
3.2.4.3 Layout of operators
If the <mo> 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 below is performed.
The text of the operator must only be painted if the
visibility of
the <mo> element is visible.
In that case, it must be painted with the
color
of the <mo> element.
Operators are laid out as follows:
If the content of the <mo> element is not
made
of a single character c then fall back to the
layout algorithm of 3.2.1.1 Layout of <mtext>.
The painting of the operator is performed by the
algorithm
to shape a stretchy glyph
stretched to inline dimensionTinline and
at position determined by the previous box metrics.
Otherwise, the stretch axis of the operator is
block. The following steps are performed:
Otherwise set them to
Uascent and
Udescent respectively.
Note
The property Tascent − AxisHeight = Tdescent + AxisHeight means that
an operator stretching exactly
Tascent above the baseline
and Tdescent below the
baseline would actually stretch symmetrically above
and below the math axis.
Sascent and
Sdescent are the minimal
values, that are respectively not less than
Uascent and
Udescent, which satisfy
this property.
Let minsize and maxsize
be the minsize and maxsize properties on the
operator. Percentage values are interpreted relative
to the height of the glyph for c.
Let T =
Tascent +
Tdescent be the target size.
If minsize < 0 then set minsize
to 0.
If maxsize < minsize then
set maxsize to minsize.
With 0 ≤ minsize ≤ maxsize:
If T ≤ 0 then set
Tascent to
minsize / 2 + AxisHeight and
then set Tdescent
to minsize −
Tascent.
Otherwise, if
0 < T < minsize
then set Tascent to
max(0, (Tascent − AxisHeight) × minsize / T + AxisHeight) and
Tdescent
to minsize −
Tascent.
Otherwise, if maxsize < T
then set Tascent to
max(0, (Tascent − AxisHeight) × maxsize / T + AxisHeight) and
Tdescent
to maxsize −
Tascent.
Note
The default maxsize is value ∞ is
interpreted above as being larger than any other size,
i.e.
minsize ≤ maxsize is always true while
maxsize < minsize and
maxsize < T are always false.
Note
This step ensures that the condition minsize ≤ T ≤ maxsize holds.
Additionnally, if the target values correspond to symmetric stretching with respect to the math axis then property
Tascent − AxisHeight = Tdescent + AxisHeight is preserved.
The inline size,
ink line-ascent,
ink line-descent,
line-ascent and
line-descent
of the math content
are obtained by the algorithm to
shape a stretchy glyph
to block dimensionTascent +
Tdescent.
The inline size of the math content is the width of
the stretchy glyph. The stretchy glyph is shifted
towards the line-under by a value Δ so that its
center aligns with the center of the target:
the ink ascent of the math content is
the ascent of the stretchy glyph − Δ
and the ink descent of the math content is
the descent of the stretchy glyph + Δ.
These centers have coordinates "½(ascent − descent)"
so Δ = [(ascent of stretchy glyph − descent of stretchy glyph) − (Tascent − Tdescent)] / 2.
The painting of the operator is performed by the
algorithm to shape a stretchy glyph
stretched to block dimensionTascent +
Tdescent
and at position determined by the previous box metrics
shifted by Δ towards the line-over.
Figure 7Base size, size variants and glyph assembly
for
the left brace
If the operator has the largeop property and
if math-style on
the <mo> element is normal,
then:
Use the
MathVariants
table to try and find a glyph of height at least
DisplayOperatorMinHeight.
If none is found, fall back to the
largest non-base glyph. If none is found, fall back to
the layout algorithm of 3.2.1.1 Layout of <mtext>.
If the algorithm to shape a stretchy glyph has been
used for one of the step above, then the italic correction
of the math content is set to the value returned by that algorithm.
3.2.5 Space <mspace>
The
mspace
empty element represents a blank space of any
desired size, as set by its attributes.
The <mspace> element accepts the attributes described
in 2.1.3 Global Attributes as well as the following
attributes:
The
width,
height,
depth, if present, must
have a value that is a valid <length-percentage>.
If the width
attribute is present, valid and not a percentage then
that attribute is used as a
presentational hint
setting the element's
width
property to the corresponding value.
If the height
attribute is absent, invalid or a percentage then the requested
line-ascent is 0.
Otherwise the requested line-ascent is the resolved
value of the height attribute, clamping
negative values to 0.
If both the height and depth attributes
are present, valid and not a percentage then they are used as a
presentational hint
setting the element's
height
property to the concatenation of the strings
"calc(", the height attribute value,
" + ", the depth attribute value,
and ")".
If only one of these attributes is
present, valid and not a percentage then it is treated as a
presentational hint
setting the element's
height
property to the corresponding value.
In the following example, mspace is used to
force spacing within the formula (a 1px blue border is
added to easily visualize the space):
If the <mspace> 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 <mspace> element is laid out as shown on
Figure 9.
The min-content inline size,
max-content inline size and inline size of the math
content are equal to the resolved value of the
width property.
The block size of the math content is equal to the resolved
value of the height property.
The line-ascent of the math content is equal to the
requested line-ascent determined above.
The terminology height/depth comes from [MATHML3], itself inspired
from [TEXBOOK].
3.2.5.1 Definition of space-like elements
A number of MathML presentation elements are "space-like" in the
sense that they typically render as whitespace, and do not affect
the mathematical meaning of the expressions in which they appear.
As a consequence, these elements often function in somewhat
exceptional ways in other MathML expressions.
Note that an mphantom is not
automatically defined to be space-like, unless its content is
space-like. This is because operator spacing is affected by
whether adjacent elements are space-like.
Since the <mphantom> element is
primarily intended as an aid in aligning expressions, operators
adjacent to an <mphantom> should behave
as if they were adjacent to the contents of the
<mphantom>, rather than to an equivalently
sized area of whitespace.
3.2.6 String Literal <ms>
ms
element is used to represent
"string literals" in expressions meant to be interpreted by computer
algebra systems or other systems containing "programming languages".
The <ms> element accepts the attributes described
in 2.1.3 Global Attributes. Its layout algorithm is
the same as the mtext element.
In the following example, ms is used to
write a literal string of characters:
In MathML3, it was possible to use the lquote and
rquote attributes to respectively specify the strings
to use as opening and closing quotes. These are no longer supported
and the quotes must instead be specified as part of the text of the
<ms> element. One can add CSS rules to legacy
documents in order to preserve visual rendering. For example,
in left-to-right direction:
Besides tokens there are several families of MathML presentation
elements. One family of elements deals with various "scripting"
notations, such as subscript and superscript. Another family is
concerned with matrices and tables. The remainder of the elements,
discussed in this section, describe other basic notations such as
fractions and radicals, or deal with general functions such as
setting style properties and error handling.
3.3.1 Group Sub-Expressions <mrow>
The
mrow
element is used to group together any number of sub-expressions, usually
consisting of one or more <mo> elements acting as
"operators" on one or more other expressions that are their "operands".
In the following example, mrow is used to
group a sum "1 + 2/3" as a fraction numerator (first child
of mfrac) and to construct a fenced expression
(first child of msup) that is raised to the power of 5.
Note that mrow alone does not add visual fences
around its grouped content, one has to explicitly specify them
using the mo element.
Within the mrow elements, one can see that
vertical alignment of children (according to the
alphabetic baseline or the mathematical baseline)
is properly performed, fences are vertically stretched and
spacing around the binary + operator automatically calculated.
The <mrow> element accepts the attributes described
in 2.1.3 Global Attributes. An <mrow>
element with in-flow children
child1, child2, …, childN
is laid out as shown on Figure 10. The child boxes
are put in a row one after the other with all their
alphabetic baselines
aligned.
Because the box model ensures alignment of alphabetic baselines,
fraction bars or symmetric stretchy operators
will also be aligned along the math axis in the typical case when
AxisHeight is the same for all in-flow children.
3.3.1.1 Algorithm for stretching operators along the block axis
Figure 11Symmetric and non-symmetric stretching of
operators along the block axis
The algorithm for stretching operators along the block axis
consists in the following steps:
Perform layout without any stretch size constraint on
all the items of LNotToStretch.
If LToStretch is empty then stop.
If LNotToStretch is empty, perform
layout with block stretch size constraint(0, 0) for
all the items of LToStretch.
Calculate the unconstrained target sizes
Uascent
and Udescent as respectively the maximum
ink ascent and maximum ink descent of the margin boxes of
in-flow children that
have been laid out in the previous step.
If the box is not an anonymous <mrow> box
and the associated 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 below is performed.
Large operators may have nonzero italic correction but that one
is used when attaching scripts.
More generally, all embellished operators
are treated as non-slanted since the spacing around them is
calculated as specified by lspace and
rspace.
If the child is slanted then
set previous-italic-correction to
its italic correction. Otherwise set it to 0.
If the child is an embellished operator
and add-space is true then
increment inline-offset by
its rspace property.
The italic correction of the math content is set to the italic
correction of the last in-flow child, which is
the final value of previous-italic-correction.
3.3.2 Fractions <mfrac>
The
mfrac
element is used for fractions. It can also be used to mark up
fraction-like objects such as binomial coefficients and Legendre symbols.
If the <mfrac> 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 below is performed.
The <mfrac> element accepts the attributes described
in 2.1.3 Global Attributes as well as the
following attribute:
The
linethickness
attribute indicates the fraction line thickness
to use for the fraction bar.
If present, it must
have a value that is a valid <length-percentage>.
If the attribute is absent or has an invalid value,
FractionRuleThickness is used as the default
value. A percentage is interpreted relative to that default value.
A negative value is interpreted as 0.
The following example contains four fractions
with different linethickness values. The bars are always
aligned with the middle of plus and minus signs.
The numerator and denominator are horizontally centered.
The fractions that are not in displaystyle
use smaller gaps and font-size.
The <mfrac> element sets
displaystyle to false,
or if it was already false increments
scriptlevel by 1, within its children.
It sets math-shift to
compact within its second child.
To avoid visual confusion between the fraction bar and another
adjacent items (e.g. minus sign or another fraction's bar),
a default 1-pixel space is added around the element.
The user agent stylesheet
must contain the following rules:
If the <mfrac> element
has less or more than two in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called
numerator, the second in-flow child is called
denominator and the layout algorithm is explained below.
If the fraction line thickness is nonzero, the
<mfrac>
element is laid out as shown on Figure 12.
The fraction bar must only be painted if the
visibility of
the <mfrac> element is visible.
In that case, the fraction bar must be painted with the
color
of the <mfrac> element.
The math content box is placed within the
content box so that their block-start edges
are aligned and the middles of these edges are at the same
position.
The math content box is placed within the
content box so that their block-start edges
are aligned and the middles of these edges are at the same
position.
3.3.3 Radicals <msqrt>, <mroot>
The radical elements construct an expression with a
root symbol √ with a line over the content.
The msqrt element is
used for square roots, while the mroot element is
used to draw radicals with indices, e.g. a cube root.
The <msqrt> and <mroot>
elements accept the attributes described
in 2.1.3 Global Attributes.
The following example contains a square root
written with msqrt and a cube root written
with mroot.
Note that msqrt has several children and the
square root applies to all of them.
mroot has exactly two children: it is a
root of index the second child (the number 3), applied to the
first child (the square root).
Also note these elements only change the font-size within the
mroot index, but it is scaled down more than
within the numerator and denumerator of the fraction.
The <msqrt> and <mroot>
elements sets math-shift to
compact.
The <mroot> element
increments scriptlevel by 2, and sets displaystyle to "false" in all
but its first child.
The user agent stylesheet
must contain the following rule in order to implement that behavior:
If the <msqrt> or <mroot>
element do not have their computed
display property equal to block math
or inline math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
If the <mroot> has less or more than two
in-flow children,
its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called
mroot base and
the second in-flow child is called
mroot index
and its layout algorithm is explained below.
Note
In practice, an <mroot> element has two children
that are in-flow. Hence the CSS rules basically perform
scriptlevel and displaystyle changes for the index.
The radical symbol must only be painted if the
visibility of
the <msqrt> or <mroot>
element is visible.
In that case, the radical symbol must be painted with the
color
of that element.
The radical glyph is the glyph obtained for the
character U+221A SQUARE ROOT.
The radical target size for the stretchy radical glyph is
the sum of RadicalRuleThickness,
radical gap and the ink height of the base.
The box metrics of the radical glyph
and painting of the surd are given by the algorithm to
shape a stretchy glyph to block dimension the
target size for the radical glyph.
3.3.3.2 Square root
The <msqrt> element is laid out as shown on
Figure 14.
The <mroot> element is laid out as shown on
Figure 15.
The mroot index is first ignored and the mroot base
and
radical glyph are laid out as
shown on figure Figure 14
using the same algorithm as in
3.3.3.2 Square root
in order to produce a margin box B (represented in green).
In general, the kerning before the root index is positive while
the kerning after it is negative, which means that the root
element will have some inline-start space and that the root index
will overlap the surd.
3.3.4 Style Change <mstyle>
Historically, the
mstyle
element was introduced to make
style changes that affect the rendering of its contents.
The <mstyle> element accepts the attributes described in
2.1.3 Global Attributes. Its layout algorithm is the
same as the mrow element.
Note
<mstyle> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
In the following example,
mstyle is used to set the scriptlevel
and displaystyle.
Observe this is respectively affecting the
font-size and placement of subscripts of their
descendants. In MathML Core, one could just have used
mrow elements instead.
The
merror
element displays its contents as an
”error message”. The intent of this element is to provide a standard way
for programs that generate MathML from other input to report syntax errors
in their input.
In the following example,
merror is used to indicate a parsing error
for some LaTeX-like input:
The <merror> element accepts the attributes described in
2.1.3 Global Attributes. Its layout algorithm is the
same as the mrow element.
The user agent stylesheet
must contain the following rule in order to visually highlight the error
message:
The
mpadded
element renders the same as its in-flow child content, but with the
size and relative positioning point of its
content modified according to <mpadded>’s attributes.
The <mpadded> element accepts the attributes described
in 2.1.3 Global Attributes as well as the following
attributes:
The
width,
height,
depth,
lspace
and
voffset
if present, must
have a value that is a valid <length-percentage>.
In the following example, mpadded is used to
tweak spacing around a fraction
(a blue background is used to visualize it).
Without attributes, it behaves like an mrow but
the attributes allow to specify the size of the box
(width, height, depth) and position of the fraction within that
box (lspace and voffset).
The requested <mpadded>
parameters are determined as follows:
The requested width
is the resolved value of the
width property.
If the width
attribute is present, valid and not a percentage then
that attribute is used as a
presentational hint
setting the element's
width
property to the corresponding value.
If the height
attribute is absent, invalid or a percentage then the requested
height is the inner line-ascent.
Otherwise the requested height is the resolved
value of the height attribute, clamping
negative values to 0.
If the depth
attribute is absent, invalid or a percentage then the requested
depth is the inner line-ascent.
Otherwise the requested depth is the resolved
value of the depth attribute, clamping
negative values to 0.
If the lspace
attribute is absent, invalid or a percentage then the requested
lspace is 0. Otherwise the requested lspace is the resolved
value of the lspace attribute, clamping
negative values to 0.
If the voffset
attribute is absent, invalid or a percentage then the requested
voffset is 0. Otherwise the requested voffset is the resolved
value of the voffset attribute.
Note
Negative voffset values are not clamped to
0.
3.3.6.2 Layout of <mpadded>
If the <mpadded> 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, it is laid out as shown on
Figure 16.
Historically, the
mphantom
element was introduced to render
its content invisibly, but with the same metrics size and other dimensions,
including alphabetic baseline position that its contents would have if they were
rendered normally.
In the following example,
mphantom is used to ensure alignment of
corresponding parts of the numerator and denominator of a
fraction:
The <mphantom> element accepts the attributes described
in 2.1.3 Global Attributes. Its layout algorithm is
the same as the mrow element.
The user agent stylesheet
must contain the following rule in order to hide the content:
mphantom {
visibility: hidden;
}
Note
<mphantom> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
3.4 Script and Limit Schemata
The elements described in this section position one or more scripts
around a base. Attaching various kinds of scripts and embellishments
to symbols is a very common notational device in mathematics. For
purely visual layout, a single general-purpose element could suffice
for positioning scripts and embellishments in any of the traditional
script locations around a given base. However, in order to capture
the abstract structure of common notation better, MathML provides
several more specialized scripting elements.
In addition to sub-/superscript elements, MathML has overscript and
underscript elements that place scripts above and below the base.
These elements can be used to place limits on large operators, or for
placing accents and lines above or below the base.
3.4.1 Subscripts and Superscripts <msub>, <msup>, <msubsup>
The msub,
msup and
msubsup elements are used to attach
subscript and superscript to a MathML expression.
They accept the attributes described in
2.1.3 Global Attributes.
The following example shows basic use of subscripts and
superscripts. The font-size is automatically scaled down
within the scripts.
If the
<msub>,
<msup> or
<msubsup> elements do not have their
computed
display property equal to block math
or inline math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
3.4.1.1 Children of <msub>,
<msup>, <msubsup>
If the <msub> element
has less or more than two in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
msub base, the second in-flow child is called the
msub subscript and the layout algorithm is explained
in 3.4.1.2 Base with subscript.
If the <msup> element
has less or more than two in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
msup base, the second in-flow child is called the
msup superscript and the layout algorithm is explained
in 3.4.1.3 Base with superscript.
If the <msubsup> element
has less or more than three in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
msubsup base, the second in-flow child
is called the msubsup subscript,
its third in-flow child is called
the msubsup superscript and the layout algorithm is explained
in 3.4.1.4 Base with subscript and superscript.
If there is an
inline stretch size constraint
or a block stretch size constraint
then the msub base is also laid out with the same stretch size
constraint and otherwise it is laid out without any stretch
size constraint. The scripts are always laid out without
any stretch size constraint.
If there is an
inline stretch size constraint
or a block stretch size constraint
then the msup base is also laid out with the same stretch size
constraint and otherwise it is laid out without any stretch
size constraint. The scripts are always laid out without
any stretch size constraint.
If there is an
inline stretch size constraint
or a block stretch size constraint
then the msubsup base is also laid out with the same stretch size
constraint and otherwise it is laid out without any stretch
size constraint. The scripts are always laid out without
any stretch size constraint.
If there is an
inline stretch size constraint
or a block stretch size constraint
then the msubsup base is also laid out with the same stretch size
constraint and otherwise it is laid out without any stretch
size constraint. The scripts are always laid out without
any stretch size constraint.
Similarly, the <mover> element
(respectively <munder> element) accepts the
attribute described in 2.1.3 Global Attributes
as well as the accent
attribute (respectively the
accentunder attribute).
accent,
accentunder
attributes, if present, must have values that are booleans.
If these attributes are absent or invalid, they are treated as
equal to false.
User agents must implement them as described in
3.4.4 Displaystyle, scriptlevel and math-shift in scripts.
The following example shows basic use of under- and overscripts.
The font-size is automatically scaled down within the scripts,
unless they are meant to be accents.
If the
<munder>,
<mover> or
<munderover> elements do not have their
computed
display property equal to block math
or inline math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
3.4.2.1 Children of <munder>,
<mover>, <munderover>
If the <munder> element
has less or more than two in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
munder base and the second in-flow child is called the
munder underscript.
If the <mover> element
has less or more than two in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
mover base and the second in-flow child is called the
mover overscript.
If the <munderover> element
has less or more than three in-flow children, its layout algorithm
is the same as the mrow element.
Otherwise, the first in-flow child is called the
munderover base, the second in-flow child
is called the munderover underscript
and its third in-flow child is called
the munderover overscript.
Split the list of in-flow children that have not been
laid out yet into a first list
LToStretch containing
embellished operators with
a stretchy property and inline stretch axis;
and a second list LNotToStretch.
Perform layout without any stretch size constraint on
all the items of LNotToStretch.
If LToStretch is empty then stop.
If LNotToStretch is empty, perform
layout with inline stretch size constraint 0 for
all the items of LToStretch.
Calculate the target size T to
the maximum inline size of the
margin boxes of child boxes that have been laid out in the
previous step.
The math content box is placed within the
content box so that their block-start edges
are aligned and the middles of these edges are at the same
position.
For accent overscripts and bases with line-ascents that are at
most
AccentBaseHeight, the rule from
[OPEN-FONT-FORMAT] [TEXBOOK] is actually to align the
alphabetic baselines of the overscripts and of the bases. This assumes that
accent glyphs are designed in such a way that their ink bottoms
are
more or less AccentBaseHeight above their alphabetic baselines. Hence,
the previous rule will guarantee that all the overscript bottoms
are aligned while still avoiding collision with the bases.
However, MathML can have arbitrary accent overscripts, so
a more general and simpler rule is provided above: Ensure
that the bottom of overscript is at least
AccentBaseHeight above the alphabetic baseline of the base.
The line-ascent of the math content is the maximum between:
The math content box is placed within the
content box so that their block-start edges
are aligned and the middles of these edges are at the same
position.
The math content box is placed within the
content box so that their block-start edges
are aligned and the middles of these edges are at the same
position.
Note
When the underscript (respectively overscript) is an empty
box, the base and overscript (respectively underscript) are laid
out similarly to
3.4.2.4 Base with overscript
(respectively 3.4.2.3 Base with underscript)
but the position of the empty underscript (respectively
overscript) may add extra space.
In order to keep the algorithm simple, no attempt is made to
handle empty scripts in a special way.
3.4.3 Prescripts and Tensor Indices <mmultiscripts>
Presubscripts and tensor notations are represented by
the mmultiscripts element.
The mprescripts element is
used as a separator between the postscripts and prescripts.
These two elements accept the attributes described in
2.1.3 Global Attributes.
The following example shows basic use of prescripts
and postscripts, involving a mprescripts.
Empty mrow elements are used at positions where
no scripts are rendered.
The font-size is automatically scaled down within the scripts.
If the
<mmultiscripts> or
<mprescripts>
elements do not have their
computed
display property equal to block math
or inline math
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The
<mprescripts>
element is laid out as an mrow
element.
A valid <mmultiscripts> element contains the
following in-flow children:
A first in-flow child, called the
mmultiscripts base, that is not an
mprescripts element.
Followed by an even number of in-flow children called
mmultiscripts postscripts, none of them being a
mprescripts element.
These scripts form a (possibly empty) list
subscript, superscript, subscript, superscript,
subscript, superscript, etc.
Each consecutive couple of children subscript, superscript
is called a
subscript/superscript pair.
Optionally followed by
an mprescripts element and
an even number of in-flow children called
mmultiscripts prescripts, none of them being a
mprescripts element.
These scripts form a (possibly empty) list of
subscript/superscript pair.
An <mmultiscripts> with only one
subscript/superscript pair of
mmultiscripts postscripts is laid out the same as a
<msubsup> with the same in-flow children.
However, as
noticed for
<msubsup>,
if additionally the subscript (respectively superscript) is an
empty box then it is not necessarily laid out the same as an
<msub>
(respectively <msup>) element.
In order to keep the algorithm simple, no attempt is made to
handle empty scripts in a special
way.
3.4.4 Displaystyle, scriptlevel and math-shift in scripts
For all scripted elements, the rule of thumb is to set
displaystyle to false and
to increment scriptlevel in all child
elements but the first one.
However, an mover (respectively
munderover)
element with an accent
attribute that is an
ASCII case-insensitive
match to true does not increment scriptlevel within
its second child (respectively third child). Similarly,
mover and
munderover elements
with an accentunder
attribute that is an
ASCII case-insensitive
match to true do not increment scriptlevel within
their second child.
<mmultiscripts> sets
math-shift to
compact on its children at even position if they are
before an mprescripts, and on those at odd position
if they are after
an mprescripts.
The <msub> and <msubsup>
elements set math-shift to
compact on their second child.
mover and
munderover
elements with an accent
attribute that is an
ASCII case-insensitive
match to true also set math-shift to
compact within their first child.
The
A. User Agent Stylesheet must contain the following
style in order to implement this behavior:
In practice, all the children of the MathML elements described in
this section are in-flow and the
<mprescripts> is empty.
Hence the CSS rules essentially perform automatic displaystyle and
scriptlevel changes for the scripts; and
math-shift changes for
subscripts and sometimes the base.
3.5 Tabular Math
Matrices, arrays and other table-like mathematical notation are marked up
using
mtablemtrmtd
elements. These elements are similar to the
table,
tr
and
td
elements of [HTML].
The following example shows how tabular layout allows to write a
matrix. Note that it is vertically centered with the fraction
bar and the middle of the equal sign.
The mtable is laid out as an
inline-table and sets
displaystyle to false. The
user agent stylesheet must contain
the following rules in order to implement these properties:
The mtd is laid out as
a table-cell with content centered in the cell and
a default padding. The
user agent stylesheet must contain
the following rules:
mtd {
display: table-cell;
/* Centering inside table cells should rely on box alignment properties.
See https://github.com/w3c/mathml-core/issues/156 */text-align: center;
padding: 0.5ex0.4em;
}
The <mtd> accepts the attributes described
in 2.1.3 Global Attributes as well as the following attributes:
The columnspan (respectively
rowspan) attribute has the same
syntax and semantics as the
colspan
(respectively
rowspan)
attribute on the <td> element from [HTML].
In particular, the parsing of these attributes is handled as
described in the
algorithm for processing rows, always reading "colspan" as
"columnspan".
Note
The name of the column spanning attribute in [MathML3] and earlier
versions is columnspan and is preserved for backward
compatibility reasons.
This specification does not define any observable behavior
that is specific to the actiontype and selection
attributes.
The following example shows the "toggle" action type from
[MathML3]
where the renderer alternately displays the selected subexpression,
starting from "one third" and cycling through them when there is a
click on the selected subexpression ("one quarter", "one half",
"one third", etc). This is not part of MathML Core but can be
implemented using JavaScript and CSS polyfills. The default behavior
is just to render the first child.
The layout algorithm of the <maction> element
is the same as the <mrow> element.
The user agent stylesheet
must contain the following rules in order to hide all but
its first child element,
which is the default behavior for the legacy actiontype
values:
maction > :not(:first-child) {
display: none;
}
Note
<maction> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use other HTML, CSS and JavaScript mechanisms to implement custom actions. They may
rely on maction attributes defined in [MathML3].
3.7 Semantics and Presentation
The
semantics
element is the container element that associates
annotations with a MathML expression. Typically, the
<semantics> element has as its first child element
a MathML expression to be annotated while subsequent child elements
represent
text annotations within an annotation
element, or more complex markup annotations within
an annotation-xml element.
The following example shows how the fraction "one half" can be
annotated with a textual annotation (LaTeX) or an XML annotation
(content MathML), which are not intended to be rendered
by the user agent. This fraction is also annotated with equivalent
SVG and HTML markup.
The <semantics> element accepts the attributes
described in 2.1.3 Global Attributes. Its layout algorithm
is the same as the mrow element.
The user agent stylesheet
must contain the following rule in order to only render the annotated
MathML expression:
semantics > :not(:first-child) {
display: none;
}
The <annotation-xml> and
<annotation> element accepts the attributes
described in 2.1.3 Global Attributes as well as the
following attribute:
This specification does not define any observable behavior that is
specific to the encoding attribute.
The layout algorithm of the <annotation-xml>
and <annotation>
element is the same as the mtext element.
Note
Authors can use the encoding attribute to distinguish
annotations
for HTML integration point,
clipboard copy, alternative rendering, etc.
In particular, CSS can be used to render alternative annotations, e.g.
/* Hide the annotated child. */
semantics > :first-child { display: none; }
/* Show all text annotations. */
semantics > annotation { display: inline; }
/* Show all HTML annotations. */
semantics > annotation-xml[encoding="text/html" i],
semantics > annotation-xml[encoding="application/xhtml+xml" i] {
display: inline-block;
}
4. CSS Extensions for Math Layout
4.1 The display: block math
and display: inline math value
For elements that are not MathML elements, if the specified
value of display is block math or
inline math then the computed value is
block flow and inline flow respectively.
For the mtable element
the computed value is block table and
inline table respectively.
For the mtr element, the computed value
is table-row.
For the mtd element, the computed value
is table-cell.
MathML elements with a
computed display value equal to
block math or inline math
control box generation and layout according to their tag name, as
described in the relevant sections.
Unknown MathML elements
behave the same as the mrow element.
Note
The display: block math and
display: inline math values provide a default
layout for MathML elements while at the same time allowing
to override it with either native display values or
custom values.
This allows authors or polyfills to define their own custom notations
to tweak or extend MathML Core.
In the following example, the default layout of the
MathML mrow element is overridden to render its
content as a grid.
The text-transform property
from CSS Text Module Level 4
has a new value math-auto.
On text nodes containing a single character, if the computed value
is math-auto and the character is present in the
"Original" column of C.1 italic mappings
then it is converted to the corresponding character from the "italic"
column.
A common style convention is to render
identifiers with multiple letters (e.g. the function name "exp")
with normal style and identifiers with a single letter
(e.g. the variable "n") with italic style. The
math-auto property is intended to implement this
default behavior, which can be overridden by authors if necessary.
Note that mathematical fonts are designed with a special kind
of italic glyphs located at the
Unicode positions of
C.1 italic mappings, which differ from the shaping
obtained via italic font style. Compare this
mathematical formula
rendered with the Latin Modern Math font using
font-style: italic (left) and
text-transform: math-auto (right):
The following example shows a
mathematical formula rendered with
its math root styled with
math-style: compact (left) and
math-style: normal (right).
In the former case, the font-size is automatically scaled down
within the fractions and the summation limits are rendered as
subscript and superscript of the ∑. In the latter case, the ∑ is
drawn bigger than normal text and
vertical gaps within fractions (even relative to current
font-size) are larger.
These two math-style values typically correspond to
mathematical expressions in inline and display
mode respectively [TeXBook].
A mathematical formula in display mode
may automatically switch to inline mode within some subformulas
(e.g. scripts, matrix elements, numerators and denominators, etc)
and it is sometimes desirable to override this default behavior.
The math-style property allows to easily implement these
features for MathML in the
user agent stylesheet
and with the displaystyle attribute; and also exposes
them to polyfills.
If the value of math-shift is compact, the math layout on descendants will use the
superscriptShiftUpCramped parameter to place superscript.
If the value of math-shift is normal, the math
will use the superscriptShiftUp parameter instead.
In the following example, the two "x squared" are rendered with
compact math-style and the same font-size.
However, the one within the square root is rendered with
compact math-shift while
the other one is rendered with
normal math-shift, leading
to subtle different shift of the superscript "2".
Per [TeXBook], a
mathematical formula uses normal style by default but may
switch to compact style ("cramped" in TeX's terminology)
within some subformulas
(e.g. radicals, fraction denominators, etc).
The math-shift property allows to easily
implement these rules for MathML in the
user agent stylesheet.
Page authors or developers of polyfills may also benefit from
having access to this property to tweak or refine the default
implementation.
4.5 The math-depth property
A new math-depth property is introduced to describe a notion
of "depth" for each element of a mathematical formula, with respect to
the top-level container of that formula. Concretely, this is used to
determine the computed value of the
font-size
property when its specified value is math.
The computed value of the math-depth value is
determined as follows:
If the specified value of math-depth is
auto-add and
the inherited value of math-style
is compact then the computed value of
math-depth of the element is its inherited value plus one.
If the specified value of math-depth is of
the form add(<integer>) then the computed value
of math-depth of the element is its inherited value plus
the specified integer.
If the specified value of math-depth is of the form
<integer> then the computed value
of math-depth of the element is the specified integer.
Otherwise, the computed value
of math-depth of the element is the inherited one.
If the specified value of
font-size
is math then the
computed value of
font-size
is obtained by multiplying the inherited value of
font-size
by a nonzero scale factor calculated by the
following procedure:
Let A be the inherited math-depth value,
B the computed math-depth value,
C be 0.71 and S be 1.0
If A = B then return S.
If B < A, swap A and B and set InvertScaleFactor to true.
Otherwise B > A and set InvertScaleFactor to false.
Return S if InvertScaleFactor is false and 1/S otherwise.
The following example shows a mathematical formula
with normal math-style
rendered with the Latin Modern Math font.
When entering subexpressions like scripts or fractions,
the font-size is automatically scaled down according to the
values of MATH table contained in that font.
Note that font-size is scaled down when
entering the superscripts but even faster when entering a
root's prescript. Also it is scaled down when entering the inner
fraction but not when entering the outer one, due to automatic
change of math-style in fractions.
These rules from [TeXBook] are subtle and it's worth having a
separate math-depth mechanism to express and
handle them. They can be implemented in MathML using the
user agent stylesheet.
Page authors or developers of polyfills may also benefit from
having access to this property to tweak or refine the default
implementation. In particular, the scriptlevel attribute
from MathML provides a way to perform math-depth
changes.
5. OpenType MATH table
This chapter describes features provided by MATH table
of an OpenType font [OPEN-FONT-FORMAT]. Throughout this chapter,
a C-like notation
Table.Subtable1[index].Subtable2.Parameter is used to
denote OpenType parameters.
Such parameters may not be available (e.g. if the font lacks one of the
subtable, has an invalid offset, etc) and so fallback options are
provided.
Note
It is strongly encouraged to render MathML with a math font with
the proper OpenType features. There is no guarantee that the fallback
options provided will provide good enough rendering.
OpenType values expressed in design units (perhaps indirectly via a
MathValueRecord entry) are scaled to appropriate values
for layout purpose, taking into account
head.unitsPerEm, CSS
font-size
or zoom level.
The subtable
MATH.MathGlyphInfo.MathItalicsCorrectionInfo
of italics correction values. Use the corresponding value in
MATH.MathGlyphInfo.MathItalicsCorrectionInfo.italicsCorrection
if there is one for the requested glyph or
0 otherwise.
MathTopAccentAttachment
The subtable
MATH.MathGlyphInfo.MathTopAccentAttachment
of positioning top math accents along the inline axis.
Use the corresponding value in
MATH.MathGlyphInfo.MathTopAccentAttachment.topAccentAttachment
if there is one for the requested glyph or
half the advance width of the glyph otherwise.
5.3 Size variants for operators (MathVariants)
This section describes how to handle stretchy glyphs of arbitrary
size using the MATH.MathVariants table.
5.3.1 The GlyphAssembly table
This section is based on [OPEN-TYPE-MATH-IN-HARFBUZZ].
For convenience, the following definitions are used:
omin is
MATH.MathVariant.minConnectorOverlap.
A GlyphPartRecord is an extender
if and only if
GlyphPartRecord.partFlags has the
fExtender flag set.
A GlyphAssembly is horizontal
if it is obtained from
MathVariant.horizGlyphConstructionOffsets.
Otherwise it is vertical (and obtained from
MathVariant.vertGlyphConstructionOffsets).
For a given GlyphAssembly table,
NExt (respectively
NNonExt) is the number of extenders
(respectively non-extenders) in
GlyphAssembly.partRecords.
For a given GlyphAssembly table,
SExt (respectively
SNonExt) is the sum of
GlyphPartRecord.fullAdvance
for all extenders (respectively non-extenders) in
GlyphAssembly.partRecords.
SExt,NonOverlapping = SExt − ominNExt
is the sum of maximum non overlapping parts of extenders.
User agents must treat the GlyphAssembly as invalid
if the following conditions are not satisfied:
NExt > 0. Otherwise, the assembly cannot
be grown by repeating extenders.
SExt,NonOverlapping > 0.
Otherwise, the assembly does not grow when joining extenders.
For each GlyphPartRecord
in GlyphAssembly.partRecords,
the values of
GlyphPartRecord.startConnectorLength and
GlyphPartRecord.endConnectorLength
must be at least omin.
Otherwise, it is not possible to satisfy the condition of
MathVariant.minConnectorOverlap.
In this specification, a glyph assembly is built by repeating each
extender r times and using the same overlap value o between each
glyph. The number of glyphs in such an assembly is
AssemblyGlyphCount(r) = NNonExt + r NExt while
the stretch size is
AssembySize(o, r) =
SNonExt + r SExt
− o (AssemblyGlyphCount(r) − 1).
rmin is the minimal number of repetitions
needed to obtain an assembly of
size at least T, i.e. the minimal r such that
AssembySize(omin, r) ≥ T.
It is defined as the maximum between 0 and the ceiling of
((T − SNonExt + omin (NNonExt − 1)) / SExt,NonOverlapping).
omax,theorical = (AssembySize(0, rmin) − T) / (AssemblyGlyphCount(rmin) − 1)
is the theorical overlap obtained by
splitting evenly the extra size of an assembly built with
null overlap.
omax is the
maximum overlap possible to build an assembly of size at least
T by repeating each extender rmin times.
If AssemblyGlyphCount(rmin) ≤ 1, then the actual overlap value is irrelevant.
Otherwise, omax is defined to be the minimum of:
GlyphPartRecord.startConnectorLength for all
the entries in
GlyphAssembly.partRecords, excluding the
last one if it is not an extender.
GlyphPartRecord.endConnectorLength for all
the entries in
GlyphAssembly.partRecords, excluding the
first one if it is not an extender.
The glyph assembly stretch size
for a target size T is
AssembySize(omax, rmin).
The
glyph assembly width,
glyph assembly ascent
and glyph assembly descent
are defined as follows:
If GlyphAssembly is vertical,
the width is the maximum advance width of the glyphs of ID
GlyphPartRecord.glyphID for all the
GlyphPartRecord in
GlyphAssembly.partRecords,
the ascent is the
glyph assembly stretch size
for a given target size T
and the descent is 0.
Otherwise, the GlyphAssembly is horizontal,
the width is glyph assembly stretch size
for a given target size T while
the ascent (respectively descent) is the
maximum ascent (respectively descent) of the glyphs of ID
GlyphPartRecord.glyphID for all the
GlyphPartRecord in
GlyphAssembly.partRecords.
Set (x, y) to (0, 0),
RepetitionCounter to 0 and
PartIndex to -1.
Repeat the following steps:
If RepetitionCounter is 0:
Increment PartIndex.
If PartIndex is
GlyphAssembly.partCount
then stop.
Otherwise, set
Part to
GlyphAssembly.partRecords[PartIndex].
Set RepetitionCounter to
rmin if
Part is an extender and to 1 otherwise.
If the glyph assembly is horizontal then
draw the glyph of ID
Part.glyphID
so that its (left, baseline) coordinates
are at position (x, y).
Set x to
x + Part.fullAdvance −
omax.
Otherwise (if the glyph assembly is vertical),
then
draw the glyph of id
Part.glyphID
so that its (left, bottom) coordinates
are at position (x, y).
Set y to
y − Part.fullAdvance +
omax.
Decrement RepetitionCounter.
5.3.2 Algorithms for glyph stretching
The preferred inline size of a glyph stretched along the block
axis
is calculated using the following algorithm:
Set S to the glyph's advance width.
If there is a MathGlyphConstruction table
in the MathVariants.vertGlyphConstructionOffsets
table for the given glyph:
For each MathGlyphVariantRecord in
MathGlyphConstruction.mathGlyphVariantRecord,
ensure that S is at least
the advance width of the glyph of id
MathGlyphVariantRecord.variantGlyph.
If there is valid GlyphAssembly subtable,
then ensure
that S is at least the
glyph assembly width.
Return S.
Note
The preferred inline size of a glyph stretched along the block
axis will return the maximum width of all possible
vertical constructions for that glyph.
In practice, math fonts are designed so that
vertical constructions are almost constant width, so possible
over-estimation of the actual width is small.
The algorithm to shape a stretchy glyph to inline
(respectively block) dimension T
is the following:
If there is not any MathGlyphConstruction table
in the MathVariants.horizGlyphConstructionOffsets
table (respectively
MathVariants.vertGlyphConstructionOffsets table)
for the given glyph then exit with failure.
If the glyph's advance width
(respectively height) is at least T
then use normal shaping and bounding box for that glyph,
the MathItalicsCorrectionInfo for that glyph as
italic correction and exit with success.
Browse the list of MathGlyphVariantRecord in
MathGlyphConstruction.mathGlyphVariantRecord.
If one MathGlyphVariantRecord.advanceMeasurement
is at least T then use
normal shaping and bounding box
for MathGlyphVariantRecord.variantGlyph,
the MathItalicsCorrectionInfo for that glyph as
italic correction and exit with success.
If none of the stretch options above allowed to cover the target
size T, then choose last one that was tried and exit
with success.
Note
If a font does not provide tables for stretchy constructions, User
Agents may use their own internal constructions as a fallback
such as
the one suggested in B.4 Unicode-based Glyph Assemblies.
The algorithm to set the properties of an operator from its category is as follows:
Set minsize to 100%.
Set maxsize to ∞.
Find the row corresponding to the specified category
on Figure 26.
Set lspace and rspace to the
value specified in the corresponding column.
For each property stretchy,
symmetric, largeop,
movablelimits, set that property to true
if it is listed in the last column or to false
otherwise.
The algorithm to determine the category of an operator
(Content, Form) is as folllows:
If Content as an UTF-16 string does not have length
or 1 or 2 then exit with category Default.
If Content is a single character in the
range U+0320–U+03FF
then exit with category Default. Otherwise,
if it has two characters:
If Content is the surrogate pairs corresponding
to
U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
or U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL and
Form is postfix, exit with category
I.
If the second character is
U+0338 COMBINING LONG SOLIDUS OVERLAY or
U+20D2 COMBINING LONG VERTICAL LINE OVERLAY then replace
Content with the first character and move to step
3.
Otherwise, if Content is listed in
Operators_2_ascii_chars then
replace Content with the
Unicode character
"U+0320 plus the index of Content in
Operators_2_ascii_chars" and move to step
3.
Otherwise exit with category Default.
If Form is infix and Content corresponds
to one of U+007C VERTICAL LINE or U+223C TILDE OPERATOR then exit
with category ForceDefault. If the category of
(Content, Form)
provided by table
Figure 25
has N/A encoding in table
Figure 26
(namely if it has category L or M), then
exit with that category.
Otherwise:
Set Key to Content if it is in
range U+0000–U+03FF; or to Content − 0x1C00
if it is in range U+2000–U+2BFF. Otherwise, exit with
category Default.
Add 0x0000, 0x1000, 0x2000
to Key according to whether Form
is infix, prefix,
postfix respectively.
Search an Entry in table
Figure 27
such that Entry % 0x4000 is equal to
Key. If one is found then return the category
corresponding to encoding Entry / 0x1000 in
Figure 26.
Otherwise, return category Default.
Figure 25Mapping from operator (Content, Form) to a category. Total size: 725 entries, 639 bytes (assuming characters are UTF-16 and 1-byte range lengths).
Category
Form
Encoding
lspace
rspace
properties
Default
N/A
N/A
0.2777777777777778em
0.2777777777777778em
N/A
ForceDefault
N/A
N/A
0.2777777777777778em
0.2777777777777778em
N/A
A
infix
0x0
0.2777777777777778em
0.2777777777777778em
stretchy
B
infix
0x4
0.2222222222222222em
0.2222222222222222em
N/A
C
infix
0x8
0.16666666666666666em
0.16666666666666666em
N/A
D
prefix
0x1
0
0
N/A
E
postfix
0x2
0
0
N/A
F
prefix
0x5
0
0
stretchy symmetric
G
postfix
0x6
0
0
stretchy symmetric
H
prefix
0x9
0.16666666666666666em
0.16666666666666666em
symmetric largeop
I
postfix
0xA
0
0
stretchy
J
prefix
0xD
0.16666666666666666em
0.16666666666666666em
symmetric largeop movablelimits
K
infix
0xC
0
0
N/A
L
prefix
N/A
0.16666666666666666em
0
N/A
M
infix
N/A
0
0.16666666666666666em
N/A
Figure 26Operators values for each category. The third column provides a 4-bit encoding of the categories where the 2 least significant bits encode the form infix (0), prefix (1) and postfix (2).
Tables of
Figure 25 and
Figure 27 are
encoded as ranges to take profit of the presence of many
contiguous Unicode blocks.
To quickly find an entry in these tables, one can still perform a
binary search over the range starts, followed by an
extra check on the range length.
Since log is concave,
it is more efficient to perform one binary search
on the whole table of
Figure 27
rather than on each large subtable
of Figure 25.
The intrinsic stretch axis a Unicode character
c is inline if it belongs to the list below.
Otherwise, the intrinsic stretch axis of c is
block.
The intrinsic stretch axis could be included as a boolean property of
the operator dictionary. But since it
does not depend on the form and since very few operators can stretch
along the inline axis, it is better implemented as a separate
sorted array. Each entry can be encoded with 16 bytes if
U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL and
U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL are tested
separately.
B.2 Operator Dictionary (human-readable)
This section is non-normative.
The following dictionary provides a human-readable version
of B.1 Operator Dictionary. Please refer to
3.2.4.2 Dictionary-based attributes for explanation about
how to use this dictionary and how to
determine the values Content and Form
indexing together
the dictionary.
Figure 29Mapping from operator (Content, Form) to properties. Total size: 1177 entries, ≥ 3679 bytes (assuming 'Content' uses at least one UTF-16 character, 'Stretch Axis' 1 bit, 'Form' 2 bits, the different combinations of 'rspace' and 'space' at least 3 bits, and the different combinations of properties 3 bits).
B.3 Combining Character Equivalences
This section is non-normative.
The following table gives mappings between spacing and non spacing
characters when used in MathML accent constructs.
Combining
Non Combining
Style
Combining
U+002B
plus sign
below
U+031F
combining plus sign below
U+002D
hyphen-minus
above
U+0305
combining overline
U+002D
hyphen-minus
below
U+0320
combining minus sign below
U+002D
hyphen-minus
below
U+0332
combining low line
U+002E
full stop
above
U+0307
combining dot above
U+002E
full stop
below
U+0323
combining dot below
U+005E
circumflex accent
above
U+0302
combining circumflex accent
U+005E
circumflex accent
below
U+032D
combining circumflex accent below
U+005F
low line
below
U+0332
combining low line
U+0060
grave accent
above
U+0300
combining grave accent
U+0060
grave accent
below
U+0316
combining grave accent below
U+007E
tilde
above
U+0303
combining tilde
U+007E
tilde
below
U+0330
combining tilde below
U+00A8
diaeresis
above
U+0308
combining diaeresis
U+00A8
diaeresis
below
U+0324
combining diaeresis below
U+00AF
macron
above
U+0304
combining macron
U+00AF
macron
above
U+0305
combining overline
U+00B4
acute accent
above
U+0301
combining acute accent
U+00B4
acute accent
below
U+0317
combining acute accent below
U+00B8
cedilla
below
U+0327
combining cedilla
U+02C6
modifier letter circumflex accent
above
U+0302
combining circumflex accent
U+02C7
caron
above
U+030C
combining caron
U+02C7
caron
below
U+032C
combining caron below
U+02D8
breve
above
U+0306
combining breve
U+02D8
breve
below
U+032E
combining breve below
U+02D9
dot above
above
U+0307
combining dot above
U+02D9
dot above
below
U+0323
combining dot below
U+02DB
ogonek
below
U+0328
combining ogonek
U+02DC
small tilde
above
U+0303
combining tilde
U+02DC
small tilde
below
U+0330
combining tilde below
U+02DD
double acute accent
above
U+030B
combining double acute accent
U+203E
overline
above
U+0305
combining overline
U+2190
leftwards arrow
above
U+20D6
U+2192
rightwards arrow
above
U+20D7
combining right arrow above
U+2192
rightwards arrow
above
U+20EF
combining right arrow below
U+2212
minus sign
above
U+0305
combining overline
U+2212
minus sign
below
U+0332
combining low line
U+27F6
long rightwards arrow
above
U+20D7
combining right arrow above
U+27F6
long rightwards arrow
above
U+20EF
combining right arrow below
Non Combining
Combining
Style
Non Combining
U+0300
combining grave accent
above
U+0060
grave accent
U+0301
combining acute accent
above
U+00B4
acute accent
U+0302
combining circumflex accent
above
U+005E
circumflex accent
U+0302
combining circumflex accent
above
U+02C6
modifier letter circumflex accent
U+0303
combining tilde
above
U+007E
tilde
U+0303
combining tilde
above
U+02DC
small tilde
U+0304
combining macron
above
U+00AF
macron
U+0305
combining overline
above
U+002D
hyphen-minus
U+0305
combining overline
above
U+00AF
macron
U+0305
combining overline
above
U+203E
overline
U+0305
combining overline
above
U+2212
minus sign
U+0306
combining breve
above
U+02D8
breve
U+0307
combining dot above
above
U+02E
U+0307
combining dot above
above
U+002E
full stop
U+0307
combining dot above
above
U+02D9
dot above
U+0308
combining diaeresis
above
U+00A8
diaeresis
U+030B
combining double acute accent
above
U+02DD
double acute accent
U+030C
combining caron
above
U+02C7
caron
U+0312
combining turned comma above
above
U+0B8
U+0316
combining grave accent below
below
U+0060
grave accent
U+0317
combining acute accent below
below
U+00B4
acute accent
U+031F
combining plus sign below
below
U+002B
plus sign
U+0320
combining minus sign below
below
U+002D
hyphen-minus
U+0323
combining dot below
below
U+002E
full stop
U+0323
combining dot below
below
U+02D9
dot above
U+0324
combining diaeresis below
below
U+00A8
diaeresis
U+0327
combining cedilla
below
U+00B8
cedilla
U+0328
combining ogonek
below
U+02DB
ogonek
U+032C
combining caron below
below
U+02C7
caron
U+032D
combining circumflex accent below
below
U+005E
circumflex accent
U+032E
combining breve below
below
U+02D8
breve
U+0330
combining tilde below
below
U+007E
tilde
U+0330
combining tilde below
below
U+02DC
small tilde
U+0332
combining low line
below
U+002D
hyphen-minus
U+0332
combining low line
below
U+005F
low line
U+0332
combining low line
below
U+2212
minus sign
U+0338
combining long solidus overlay
over
U+02F
U+20D7
combining right arrow above
above
U+2192
rightwards arrow
U+20D7
combining right arrow above
above
U+27F6
long rightwards arrow
U+20EF
combining right arrow below
above
U+2192
rightwards arrow
U+20EF
combining right arrow below
above
U+27F6
long rightwards arrow
B.4 Unicode-based Glyph Assemblies
This section is non-normative.
The following table provides fallback that user agents may use for
stretching a given base character when the font does not
provide a MATH.MathVariants table.
The algorithms of
5.3 Size variants for operators (MathVariants)
work the same except with some adjustments:
Entries are indexed by the base character.
All the glyph IDs and metrics have to be deduced from Unicode
code points.
If the glyph construction is horizontal then
the entry corresponds to
a MathVariants.horizGlyphConstructionOffsets[] item;
if it is vertical it corresponds to
a MathVariants.vertGlyphConstructionOffsets[] item.
The MathGlyphConstruction.mathGlyphVariantRecord is
always empty.
The
MathVariants.minConnectorOverlap,
GlyphPartRecord.startConnectorLength and
GlyphPartRecord.endConnectorLength
are treated as 0.
The array of
MathGlyphConstruction.GlyphAssembly.partRecords is built
from each table row as follows:
A (non-extender) bottom/left character
Followed by an extender character.
Optionally followed by this:
Optionally, a (non-extender) middle character
and the same extender character previously mentioned.
A (non-extender) top/right character.
Base Character
Glyph Construction
Extender Character
Bottom/Left Character
Middle Character
Top/Right Character
U+0028 (
Vertical
U+239C ⎜
U+239D ⎝
N/A
U+239B ⎛
U+0029 )
Vertical
U+239F ⎟
U+23A0 ⎠
N/A
U+239E ⎞
U+003D =
Horizontal
U+003D =
U+003D =
N/A
N/A
U+005B [
Vertical
U+23A2 ⎢
U+23A3 ⎣
N/A
U+23A1 ⎡
U+005D ]
Vertical
U+23A5 ⎥
U+23A6 ⎦
N/A
U+23A4 ⎤
U+005F _
Horizontal
U+005F _
U+005F _
N/A
N/A
U+007B {
Vertical
U+23AA ⎪
U+23A9 ⎩
U+23A8 ⎨
U+23A7 ⎧
U+007C |
Vertical
U+007C |
U+007C |
N/A
N/A
U+007D }
Vertical
U+23AA ⎪
U+23AD ⎭
U+23AC ⎬
U+23AB ⎫
U+00AF ¯
Horizontal
U+00AF ¯
U+00AF ¯
N/A
N/A
U+2016 ‖
Vertical
U+2016 ‖
U+2016 ‖
N/A
N/A
U+203E ‾
Horizontal
U+203E ‾
U+203E ‾
N/A
N/A
U+2190 ←
Horizontal
U+23AF ⎯
U+2190 ←
N/A
U+23AF ⎯
U+2191 ↑
Vertical
U+23D0 ⏐
U+23D0 ⏐
N/A
U+2191 ↑
U+2192 →
Horizontal
U+23AF ⎯
U+23AF ⎯
N/A
U+2192 →
U+2193 ↓
Vertical
U+23D0 ⏐
U+2193 ↓
N/A
U+23D0 ⏐
U+2194 ↔
Horizontal
U+23AF ⎯
U+2190 ←
N/A
U+2192 →
U+2195 ↕
Vertical
U+23D0 ⏐
U+2193 ↓
N/A
U+2191 ↑
U+21A4 ↤
Horizontal
U+23AF ⎯
U+2190 ←
N/A
U+22A3 ⊣
U+21A6 ↦
Horizontal
U+23AF ⎯
U+22A2 ⊢
N/A
U+2192 →
U+21BC ↼
Horizontal
U+23AF ⎯
U+21BC ↼
N/A
U+23AF ⎯
U+21BD ↽
Horizontal
U+23AF ⎯
U+21BD ↽
N/A
U+23AF ⎯
U+21C0 ⇀
Horizontal
U+23AF ⎯
U+23AF ⎯
N/A
U+21C0 ⇀
U+21C1 ⇁
Horizontal
U+23AF ⎯
U+23AF ⎯
N/A
U+21C1 ⇁
U+2223 ∣
Vertical
U+2223 ∣
U+2223 ∣
N/A
N/A
U+2225 ∥
Vertical
U+2225 ∥
U+2225 ∥
N/A
N/A
U+2308 ⌈
Vertical
U+23A2 ⎢
U+23A2 ⎢
N/A
U+23A1 ⎡
U+2309 ⌉
Vertical
U+23A5 ⎥
U+23A5 ⎥
N/A
U+23A4 ⎤
U+230A ⌊
Vertical
U+23A2 ⎢
U+23A3 ⎣
N/A
N/A
U+230B ⌋
Vertical
U+23A5 ⎥
U+23A6 ⎦
N/A
N/A
U+23B0 ⎰
Vertical
U+23AA ⎪
U+23AD ⎭
N/A
U+23A7 ⎧
U+23B1 ⎱
Vertical
U+23AA ⎪
U+23A9 ⎩
N/A
U+23AB ⎫
U+27F5 ⟵
Horizontal
U+23AF ⎯
U+2190 ←
N/A
U+23AF ⎯
U+27F6 ⟶
Horizontal
U+23AF ⎯
U+23AF ⎯
N/A
U+2192 →
U+27F7 ⟷
Horizontal
U+23AF ⎯
U+2190 ←
N/A
U+2192 →
U+294E ⥎
Horizontal
U+23AF ⎯
U+21BC ↼
N/A
U+21C0 ⇀
U+2950 ⥐
Horizontal
U+23AF ⎯
U+21BD ↽
N/A
U+21C1 ⇁
U+295A ⥚
Horizontal
U+23AF ⎯
U+21BC ↼
N/A
U+22A3 ⊣
U+295B ⥛
Horizontal
U+23AF ⎯
U+22A2 ⊢
N/A
U+21C0 ⇀
U+295E ⥞
Horizontal
U+23AF ⎯
U+21BD ↽
N/A
U+22A3 ⊣
U+295F ⥟
Horizontal
U+23AF ⎯
U+22A2 ⊢
N/A
U+21C1 ⇁
C. Mathematical Alphanumeric Symbols
This section is non-normative.
As detailed in [xml-entity-names] mathematical alphanumeric symbols
with form bold, italic, fraktur, monospace, double-struck etc
are available in Unicode.
These alphanumeric
symbols should be accessed using their Unicode code points.
It is sometimes needed to distinguish between
Chancery and Roundhand style for MATHEMATICAL SCRIPT characters.
These are notably used in LaTeX for the
\mathcal and \mathscr commands.
One way to do that is to rely on
Chapter 23.4 Variation Selectors of
Unicode which describes a way to
specify selection of particular glyph variants [UNICODE].
Indeed, the
StandardizedVariants.txt file from the
Unicode Character Database indicates that variant selectors
U+FE00 and U+FE01 can be used on capital script to specify
Chancery and Roundhand respectively.
Alternatively, some
mathematical fonts rely on salt or
ssXY properties from [OPEN-FONT-FORMAT]
to provide both styles. Page authors may use the
font-variant-alternates property with corresponding OpenType font features
to access these glyphs.
In addition, the italic math alphanumeric characters may be accessed as described above using the CSS
text-transform: math-auto transform which is applied by default to single character <mi> elements.
As a convenience the mapping to math italic is shown below.
C.1 italic mappings
Original
italic
Δcode point
A U+0041
𝐴 U+1D434
1D3F3
B U+0042
𝐵 U+1D435
1D3F3
C U+0043
𝐶 U+1D436
1D3F3
D U+0044
𝐷 U+1D437
1D3F3
E U+0045
𝐸 U+1D438
1D3F3
F U+0046
𝐹 U+1D439
1D3F3
G U+0047
𝐺 U+1D43A
1D3F3
H U+0048
𝐻 U+1D43B
1D3F3
I U+0049
𝐼 U+1D43C
1D3F3
J U+004A
𝐽 U+1D43D
1D3F3
K U+004B
𝐾 U+1D43E
1D3F3
L U+004C
𝐿 U+1D43F
1D3F3
M U+004D
𝑀 U+1D440
1D3F3
N U+004E
𝑁 U+1D441
1D3F3
O U+004F
𝑂 U+1D442
1D3F3
P U+0050
𝑃 U+1D443
1D3F3
Q U+0051
𝑄 U+1D444
1D3F3
R U+0052
𝑅 U+1D445
1D3F3
S U+0053
𝑆 U+1D446
1D3F3
T U+0054
𝑇 U+1D447
1D3F3
U U+0055
𝑈 U+1D448
1D3F3
V U+0056
𝑉 U+1D449
1D3F3
W U+0057
𝑊 U+1D44A
1D3F3
X U+0058
𝑋 U+1D44B
1D3F3
Y U+0059
𝑌 U+1D44C
1D3F3
Z U+005A
𝑍 U+1D44D
1D3F3
a U+0061
𝑎 U+1D44E
1D3ED
b U+0062
𝑏 U+1D44F
1D3ED
c U+0063
𝑐 U+1D450
1D3ED
d U+0064
𝑑 U+1D451
1D3ED
e U+0065
𝑒 U+1D452
1D3ED
f U+0066
𝑓 U+1D453
1D3ED
g U+0067
𝑔 U+1D454
1D3ED
h U+0068
ℎ U+0210E
20A6
i U+0069
𝑖 U+1D456
1D3ED
j U+006A
𝑗 U+1D457
1D3ED
k U+006B
𝑘 U+1D458
1D3ED
l U+006C
𝑙 U+1D459
1D3ED
m U+006D
𝑚 U+1D45A
1D3ED
n U+006E
𝑛 U+1D45B
1D3ED
o U+006F
𝑜 U+1D45C
1D3ED
p U+0070
𝑝 U+1D45D
1D3ED
q U+0071
𝑞 U+1D45E
1D3ED
r U+0072
𝑟 U+1D45F
1D3ED
s U+0073
𝑠 U+1D460
1D3ED
t U+0074
𝑡 U+1D461
1D3ED
u U+0075
𝑢 U+1D462
1D3ED
v U+0076
𝑣 U+1D463
1D3ED
w U+0077
𝑤 U+1D464
1D3ED
x U+0078
𝑥 U+1D465
1D3ED
y U+0079
𝑦 U+1D466
1D3ED
z U+007A
𝑧 U+1D467
1D3ED
ı U+0131
𝚤 U+1D6A4
1D573
ȷ U+0237
𝚥 U+1D6A5
1D46E
Α U+0391
𝛢 U+1D6E2
1D351
Β U+0392
𝛣 U+1D6E3
1D351
Γ U+0393
𝛤 U+1D6E4
1D351
Δ U+0394
𝛥 U+1D6E5
1D351
Ε U+0395
𝛦 U+1D6E6
1D351
Ζ U+0396
𝛧 U+1D6E7
1D351
Η U+0397
𝛨 U+1D6E8
1D351
Θ U+0398
𝛩 U+1D6E9
1D351
Ι U+0399
𝛪 U+1D6EA
1D351
Κ U+039A
𝛫 U+1D6EB
1D351
Λ U+039B
𝛬 U+1D6EC
1D351
Μ U+039C
𝛭 U+1D6ED
1D351
Ν U+039D
𝛮 U+1D6EE
1D351
Ξ U+039E
𝛯 U+1D6EF
1D351
Ο U+039F
𝛰 U+1D6F0
1D351
Π U+03A0
𝛱 U+1D6F1
1D351
Ρ U+03A1
𝛲 U+1D6F2
1D351
ϴ U+03F4
𝛳 U+1D6F3
1D2FF
Σ U+03A3
𝛴 U+1D6F4
1D351
Τ U+03A4
𝛵 U+1D6F5
1D351
Υ U+03A5
𝛶 U+1D6F6
1D351
Φ U+03A6
𝛷 U+1D6F7
1D351
Χ U+03A7
𝛸 U+1D6F8
1D351
Ψ U+03A8
𝛹 U+1D6F9
1D351
Ω U+03A9
𝛺 U+1D6FA
1D351
∇ U+2207
𝛻 U+1D6FB
1B4F4
α U+03B1
𝛼 U+1D6FC
1D34B
β U+03B2
𝛽 U+1D6FD
1D34B
γ U+03B3
𝛾 U+1D6FE
1D34B
δ U+03B4
𝛿 U+1D6FF
1D34B
ε U+03B5
𝜀 U+1D700
1D34B
ζ U+03B6
𝜁 U+1D701
1D34B
η U+03B7
𝜂 U+1D702
1D34B
θ U+03B8
𝜃 U+1D703
1D34B
ι U+03B9
𝜄 U+1D704
1D34B
κ U+03BA
𝜅 U+1D705
1D34B
λ U+03BB
𝜆 U+1D706
1D34B
μ U+03BC
𝜇 U+1D707
1D34B
ν U+03BD
𝜈 U+1D708
1D34B
ξ U+03BE
𝜉 U+1D709
1D34B
ο U+03BF
𝜊 U+1D70A
1D34B
π U+03C0
𝜋 U+1D70B
1D34B
ρ U+03C1
𝜌 U+1D70C
1D34B
ς U+03C2
𝜍 U+1D70D
1D34B
σ U+03C3
𝜎 U+1D70E
1D34B
τ U+03C4
𝜏 U+1D70F
1D34B
υ U+03C5
𝜐 U+1D710
1D34B
φ U+03C6
𝜑 U+1D711
1D34B
χ U+03C7
𝜒 U+1D712
1D34B
ψ U+03C8
𝜓 U+1D713
1D34B
ω U+03C9
𝜔 U+1D714
1D34B
∂ U+2202
𝜕 U+1D715
1B513
ϵ U+03F5
𝜖 U+1D716
1D321
ϑ U+03D1
𝜗 U+1D717
1D346
ϰ U+03F0
𝜘 U+1D718
1D328
ϕ U+03D5
𝜙 U+1D719
1D344
ϱ U+03F1
𝜚 U+1D71A
1D329
ϖ U+03D6
𝜛 U+1D71B
1D345
D. Acknowledgments
This section is non-normative.
MathML Core is based on MathML3. See the
appendix E
of [MathML3] for the people that contributed to that specification.
MathML Core was initially developed by the MathML Community Group, and
then by the Math Working Group. Working Group or Community Group
members who regularly participated in MathML
Core meetings during the development of this specification:
Brian Kardell,
Bruce Miller,
Daniel Marques,
David Carlisle,
David Farmer,
Deyan Ginev,
Frédéric Wang,
Louis Mahler,
Moritz Schubotz,
Murray Sargent,
Neil Soiffer,
Patrick Ion,
Rob Buis,
Steve Noble and
Sam Dooley.
In addition, we would like to extend special thanks to
Brian Kardell,
Neil Soiffer and
Rob Buis for help with the editing.
Many thanks also to the following people for their help with the
test suite:
Brian Kardell,
Frédéric Wang,
Neil Soiffer and
Rob Buis.
Several tests are also based on MathML tests from browser
repositories and we are grateful to the Mozilla and WebKit
contributors.
We would like to thank the people who, through their input and
feedback on public communication channels, have helped us with the
creation of this specification:
André Greiner-Petter,
Anne van Kesteren,
Boris Zbarsky,
Brian Smith,
Elika Etemad,
Emilio Cobos Álvarez,
ExE Boss,
Ian Kilpatrick,
Koji Ishii,
L. David Baron,
Michael Kohlhase,
Michael Smith,
Ryosuke Niwa,
Sergey Malkin,
Tab Atkins Jr.,
Viktor Yaffle and
frankvel.
E. Security Considerations
This section is non-normative.
This specification adds script execution mechanisms via the
MathML event handler attributes described in
2.1.3 Global Attributes. UAs may decide to prevent execution
of scripts specified in these attributes, following the same
security restrictions as those applying to HTML or SVG elements.
Note
In [MathML3], it was possible to make any element linkable
via href or xlink:href attributes, with
an URL pointing to an untrusted resource or even
javascript: execution. These attributes are not
available in MathML Core. However, as described in
2.2.1 HTML and SVG it is possible to embed
HTML or SVG content inside MathML, including HTML or SVG links.
Note
In [MathML3], it was possible to use the
maction element with
the actiontype value set to "statusline"
in order to override the text of the browser statusline. In particular,
an attacker could use this
to hide the URL text of an untrusted link e.g.
This feature is not available in MathML Core, where
the maction element essentially behaves
like an mrow container with extra style.
An attacker can try to hang the UA by inserting very large
stretchy operators, effectively making the algorithm
shaping of the glyph assembly deal with a huge amount of
glyphs. UAs may work around this issue
by limiting rmin and
GlyphAssembly.partCount to
maximum values.
As described in
CSS Fonts Module,
an attacker can try to rely on malformed or malicious fonts to
exploit potential security faults in browser implementations.
Because the OpenType MATH table
is used extensively in this specification, UAs should ensure their font
sanitization mechanisms are able to deal with that table.
Finally,
in order to reduce attack surface, some UAs expose runtime options
to disable part of the web platform. Disabling MathML layout can
essentially be
achieved by forcing elements in the DOM tree to be put in the HTML
namespace and disabling 4. CSS Extensions for Math Layout.
F. Privacy Considerations
This section is non-normative.
As explained in 2.2.1 HTML and SVG,
MathML can be embedded into an SVG image via the
<foreignObject>
element which can thus be used in a
canvas
element.
UA may decide to implement any measure to prevent potential
information leakage
such as tainting the canvas and returning a
"SecurityError"
when one tries to access the canvas' content via JavaScript APIs.
In the following example, the canvas image is set to the image of
some MathML content with an HTML link to https://example.org/.
It should not be possible for an attacker to determine whether that
link was visited by reading pixels via context.getImageData().
For more about links in MathML, see
E. Security Considerations.
let svg = `
<svgxmlns="https://www.w3.org/2000/svg"width="100px"height="100px"><foreignObjectwidth="100"height="100"requiredExtensions="https://www.w3.org/1998/Math/MathML"><mathxmlns="https://www.w3.org/1998/Math/MathML"><msqrtstyle="font-size: 25px"><mtext>■</mtext><mtext><ahref="https://example.org/">■</a></mtext></msqrt></math></foreignObject></svg>`;
let image = new Image();
image.width = 100;
image.height = 100;
image.onload = () => {
let canvas = document.createElement('canvas');
canvas.width = 100;
canvas.height = 100;
canvas.style = "border: 1px solid black";
document.body.appendChild(canvas);
let context = canvas.getContext("2d");
context.drawImage(image, 0, 0);
};
image.src = `data:image/svg+xml;base64,${window.btoa(svg)}`;
This specification describes layout of DOM
elements which may involve system
fonts. Like for HTML/CSS layout,
it is thus possible to use JavaScript APIs
(e.g.
context.getImageData() on content embedded in a canvas context, or even just
getBoundingClientRect())
to measure box sizes and positions and infer data from system fonts.
By combining miscellaneous tests on such fonts and
comparing measurements against results of well-known fonts, an attacker
can try and determine the default fonts of the user.
The following
HTML+CSS+JavaScript document relies on a Web font with exotic metrics
to try and determine whether A Well Known System Font
is available by default.
The following
HTML+CSS document contains the same text rendered with
text-decoration-thickness set to from-font and 1em (here
100 pixels)
respectively. By comparing the heights of the two underlines,
one can calculate a good approximation of the
underlineThickness value from the PostScript Table
[OPEN-FONT-FORMAT].
This specification relies on information from
5. OpenType MATH table to render MathML content. One
can get good approximation of most
layout parameters from MathConstants and
MathGlyphInfo using measurement
techniques similar to what is described above for
HTML+CSS+JavaScript document. The use of the MathVariants
table for MathML rendering can also be observed by putting stretchy
operators of different sizes inside a canvas context.
Although none of these parameters taken individually are personal,
implementing this specification increases the set of exposed
font information that can be used by an attacker to implement
fingerprinting techniques. Typically, they could help determine
available and preferred math fonts for a user.
G. Conformance
Conformance requirements are expressed with a combination of
descriptive assertions and RFC 2119 terminology. The key words “MUST”,
“MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
document are to be interpreted as described in RFC 2119.
However, for readability, these words do not appear in all uppercase
letters in this specification.
All of the text of this specification is normative except sections
explicitly marked as non-normative, examples, and notes.
[RFC2119]
Examples in this specification are introduced with the words
“for example” or are set apart from the normative text with
class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from
the normative text with class="note", like this:
Note
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention
and are set apart from other normative text with
<strong class="advisement">, like this:
UAs MUST provide an accessible alternative.
