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.
This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
The [[MATHML3]] specification has several shortcomings that make it hard to implement consistently across web rendering engines or to extend with userdefined constructions e.g.
This MathML Core specification intends to address these issues by being as accurate as possible on the visual rendering of mathematical formulas using additional rules from the TeXBook’s Appendix G [[?TEXBOOK]] and from the Open Font Format [[OPENFONTFORMAT]], [[OPENTYPEMATHILLUMINATED]]. It also relies on modern browser implementations and web technologies [[HTML]] clarifying interactions with them when needed or introducing new lowlevel 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 browserdriven 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 DOM, custom elements, CSS layout API or other Houdini APIs.
The term MathML element refers to any element in the MathML namespace. The MathML element 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.
The grouping elements are <maction>, <math>, <merror> <mphantom>, <mprescripts>, <mrow>, <mstyle>, <none>, <semantics> and unknown MathML elements.
The scripted elements are <mmultiscripts>, <mover>, <msub>, <msubsup>, <msup>, <munder> and <munderover>.
The radical elements are <mroot> and <msqrt>.
The attributes defined in this specification have no namespace and are called MathML attributes:
maction
attributesmo
attributesmpadded
attributesmspace
attributesmunderover
attributesmtr
attributesencoding
display
linethickness
<math>
ElementMathML specifies a single toplevel 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 as well as the
following attribute:
The
display
attribute, if present,
must be an
ASCII caseinsensitive
match
to block
or inline
.
The user agent stylesheet
described in
contains rules for this attribute that affect the
default values for the display
(math
or inlinemath
)
and mathstyle
(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
.
If the element does not have its computed
display
property equal to
math
or inlinemath
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
box. That MathML box is used as the content for the layout of
the element, as described by CSS for display: block
(if the computed value is math
) or
display: inline
(if the computed value is inlinemath
).
Additionally, if the computed
display
property is equal to
math
then that MathML box is rendered horizontally
centered within the content box.
$...$
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:
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
alignement. 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
fontfamily
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
fontstyle
, fontweight
,
direction
or textindent
etc
are not expected to apply to the math formula and so the
user agent stylesheet
has rules to reset them by default.
All token elements and the mrow grouping element are potentially linkable and may contain an href
attribute. They are the MathML equivalents of HTML's a and must follow all of the same criteria laid out for links there.
<integervalue>
value as defined in
[[CSSVALUES3]], whose first character is neither
U+002D HYPHENMINUS character () nor
U+002B PLUS SIGN (+).
<lengthpercentage>
value as defined in
[[CSSVALUES3]]
<color>
value as defined in [[CSSCOLOR3]]
true
or
false
.
The following attributes are common to and may be specified on all MathML elements:
The
id
,
class
,
style
,
data*
,
nonce
and
tabindex
attributes have the same syntax and semantic as defined for
id,
class,
style,
data*,
nonce and
tabindex
attributes on HTML elements.
The
href
attribute has the same syntax and semantic as defined for
the href attribute on
<a>
element.
To fully implement this attribute, the following CSS properties for
links must be specified in the
user agent stylesheet:
The
dir
attribute, if present,
must be an
ASCII caseinsensitive 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.
This attribute is used to set the directionality of math formulas, which is
often rtl
in Arabic speaking world.
In the following example, the dir attribute is used to render "𞸎 plus 𞸑 raised to the power of (٢ over, 𞸟 plus ١)" from righttoleft.
All MathML elements support event handler content attributes, as described in event handler content attributes in HTML.
All event handler content attributes noted by HTML as being supported by all HTMLElements are supported by all MathML elements as well, as defined in the MathMLElement IDL.
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
backgroundcolor
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 lengthpercentage.
In that case, the user agent is expected to treat the attribute as a
presentational hint setting the element's
fontsize
property to the corresponding value.
The mathsize
property indicates indicates the desired height
of glyphs in math formulas but also scale other parts (spacing, shifts,
line thickness of bars etc) accordingly.
mathvariant
attribute
The
mathvariant
attribute,
if present, must be an
ASCII caseinsensitive
match to one of:
normal
,
bold
,
italic
,
bolditalic
,
doublestruck
,
boldfraktur
,
script
,
boldscript
,
fraktur
,
sansserif
,
boldsansserif
,
sansserifitalic
,
sansserifbolditalic
,
monospace
,
initial
,
tailed
,
looped
, or
stretched
.
In that case, the user agent is expected to treat the attribute as a
presentational hint setting the element's
texttransform
property to the corresponding value.
More precisely, normal
is mapped to none
while all the other values are mapped to the corresponding CSS
value with the extra
math
prefix.
The mathvariant
attribute defines logical classes of token
elements. Each class provides a collection of typographicallyrelated
symbolic tokens with specific meaning within a given mathematical
expression.
For mathvariant
values other than normal
,
this is done by using glyphs of
Unicode's Mathematical Alphanumeric Symbols.
In the following example, the mathvariant attribute is used to render different A letters. Note that by default variables use mathematical italic.
mathvariant
values other than normal
are implemented for compatibility with full MathML and legacy editors that can't access characters in Plane 1 of Unicode. Authors are encouraged to use the corresponding Unicode characters.
The normal
value is still important to cancel automatic
italic of the <mi>
element.
salt
or
ssXY
properties from [[OPENFONTFORMAT]]
to provide both styles. Page authors may use the
fontvariantalternates
property with corresponding OpenType font features
to access these glyphs.
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
mathstyle
property to the corresponding value.
More precisely, true
is mapped to normal
and
false
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
unsignedinteger.
In that case and if the mathsize attribute is absent,
the user agent is expected to treat the scriptlevel
attribute as a
presentational hint setting the element's
fontsize
property to the corresponding value.
More precisely,
+<U>
, <U>
and
<U>
are respectively mapped to
scriptlevel(add(<U>))
scriptlevel(add(<U>))
and scriptlevel(<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 .
In this example, a <munder>
element is used to attach a
script "A" attached to a base "∑". By default, the summation
symbol is rendered with the fontsize 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 fontsize as the toplevel math
root.
\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.
When parsing HTML documents user agents must treat any tag name corresponding to a MathML Core Element as belonging to the MathML namespace.
Users agents must allow mixing HTML, SVG and MathML elements as allowed by sections HTML integration point, MathML integration point, tree construction dispatcher, MathML and SVG from [[HTML]].
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
a 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>
include an interactive input field inside a mathematical
formula.
<math>
element can be used at
position permitted for
flow content
(e.g. a
<foreignObject>
element)
or phrasing content.
<mi>
,
<mo>
,
<mn>
,
<ms>
and
<mtext>
elements.
<svg>
element can be used inside
<annotationxml>
elements.
<annotationxml>
elements with
encoding
application/xhtml+xml
or text/html
.
User agents must support various CSS features mentioned in this specification, including new ones described in . 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 fontfamily
specified via the
style attribute.
All documents containing MathML Core elements must include CSS rules described in as part of useragent level style sheet defaults.
The following CSS features are not supported and must be ignored:
writingmode
is treated as horizontaltb
on all MathML
elements.whitespace
is treated as nowrap
on all MathML elements.
width
,
height
,
inlinesize
and
blocksize
are treated as auto
on elements
with computed display value
math
or
inlinemath
.
float
and clear
are treated as none
on all MathML elements.
aligncontent
, justifycontent
,
alignself
, justifyself
have
no effect on MathML elements.
User agents supporting Web application APIs must ensure that they keep the visual rendering of MathML in synchronization with the [[DOM]] tree.
All the nodes representing MathML elements in the DOM
must implement, and expose to scripts, the following
MathMLElement
interface.
The
GlobalEventHandlers
,
DocumentAndElementEventHandlers
and
HTMLOrForeignElement
interfaces are defined in
[[HTML]].
The
ElementCSSInlineStyle
interface is defined in [[CSSOM]].
Each IDL attribute of the
MathMLElement
interface
reflects the
corresponding MathML
content attribute.
In the following example, a MathML formula is used to render the fraction "α over 2". When clicking the red α, it is changed into a blue β.
All of the nodes representing MathML Hyperlink Elements in the DOM must implement, and expose to scripts the following MathMLLinkableElement
interface.
MathMLUnknownElement
interface?HTMLElement includes ElementCSSInlineStyle;
to the [[CSSOM]] specification.
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 [[OPENFONTFORMAT]] when performing text layout.
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 focusrelated pseudoclasses as defined in CSS Selectors apply, as defined in that specification.
All MathMLLinkableElement
elements are potentially linkable with an href
attribute. Their default tabindex is 0
. If their href
contains a valid URL, their focus flag must be set unless the user agent normally provides an alternative
method of keyboard traversal of links, and they appear in the
sequential focus order.
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).
The default display
property
is described in :
<math>
root,
it is equal to inlinemath
or math
according to the value of the display attribute.
<mtable>
,
<mtr>
,
<mtd>
it is respectively equal to
inlinetable
,
tablerow
and
tablecell
.
none
.
math
.
In order to specify math layout in different writing modes, this specification uses concepts from [[CSSWRITINGMODES3]]:
horizontallr
and ltr
.
See ,
and
for examples of other
writing modes that are sometimes used for math layout.
MathML boxes have 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. Each math box has the following parameters:
Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:
Given a MathML box, the inline offset of a child box is the distance between the inlinestart edge of the parent box and the inlinestart edge of the child box. The block offset of a child box is the offset between blockstart edge of the parent box and the blockstart edge of the child box.
The lineleft offset, lineright offset, lineover offset and lineunder offset are defined similarly as offsets between the corresponding parent and child edges.
Here are examples of offsets obtained from linerelative metrics:
ltr
and
is the inline size of the box −
(lineleft offset + inline size of
the child box) otherwise.
horizontallr
,
verticalrl
or sidewaysrl
and is the linedescent otherwise.
The layout algorithms described in this chapter for MathML boxes have the following structure:
During box layout, the following extra steps must be performed:
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 baselines of the padding box are the same as the one of the content box.
If the content box has a top accent attachment then the padding box has the same property, increased by the inlinestart padding. If the content box has an italic correction then the padding box has the same property, increased by the inlineend padding.
The box metrics and offsets of the
border box
are obtained from the
padding box
by taking into account the corresponding
borderwidth
property as described in CSS.
In general, the baselines of the border box are the same as the one of the padding box. However, if the lineover border is positive then the inkover baseline is set to the lineover edge of the border box and if the lineunder border is positive then the inkunder baseline is set to the lineunder edge of the border box.
If the padding box has a top accent attachment then the border box has the same property, increased by the borderwidth of its inlinestart egde. If the padding box has an italic correction then the border box has the same property, increased by the borderwidth of its inlineend egde.
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.
The baselines of the margin box are the same as the one of the border box.
If the padding box has a top accent attachment then the margin box has the same property, increased by the inlinestart margin. If the padding box has an italic correction then the margin box has the same property, increased by the inlineend margin.
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 lineascent and ink linedescent 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.
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: math
or display: inlinemath
generates a new stacking
context. The painting order
of inflow 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: inlinemath
and right after
step 7.2 for display: math
).
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.
<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.
The <mtext>
element accepts the attributes described
in .
In the following example, <mtext> is used to put conditional words in a definition:
<mtext>
If the element does not have its computed
display
property equal to
math
or inlinemath
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The mtext
element is laid out as a
block box
and the mincontent inline size,
maxcontent inline size,
inline size, block size,
first baseline set and last baseline set are determined
accordingly.
If the <mtext>
element contains only text
content without
forced line break
or
soft wrap opportunity
then in addition:
<mtext>
element.
<mi>
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 . Its layout algorithm is
the same as the <mtext> element.
The
user agent stylesheet
must contain the following property in order to implement automatic
italic:
In the following example, <mi> is used to render variables and function names. Note that identifiers containing a single letter are italic by default.
<mn>
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 . Its layout algorithm is
the same as the
<mtext>
element.
In the following example, <mn> is used to write a decimal number.
<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 as well as the following
attributes:
This specification does not define any observable behavior that is specific to the fence and separator attributes.
fence
and separator
to describe specific semantics of operators.
The default values may be determined from the
Operators_fence
and Operators_separator
tables, or equivalently
the humanreadable version
of the operator dictionary.
In the following example, the <mo> element
is used for the binary operator +. Default spacing is symmetric
around that operator. A tigher 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 operator such as summation. When displaystyle is true, such an operator are drawn larger but one can change that with the largeop attribute. When displaystyle is false, underscript are actually rendered as subscript 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 stretchy symmetrically above and below the baseline. Finally the minsize and maxsize attributes add additional constraints over the stretch size.
Note that the default properties of operators are dictionarybased, as explained in . For example a binary operator typically has default symmetric spacing around it while a fence is generally stretchy by default.
A MathML Core element is an embellished operator if is is:
<mo>
element;<mfrac>
,
whose first inflow child exists and is an
embellished operator;
The core operator of an embellished operator
is the <mo>
element defined recursively as
follows:
<mo>
element; is the element itself.<mfrac>
element is the core operator of its first inflow child.
The stretch axis of an embellished operator
is inline if its
core operator contains only text content
made of a unique character c
and that
character has stretch axis inline per
.
Otherwise, stretch axis of the embellished operator
is block.
The form
property of an embellished operator is either
infix
, prefix
or
postfix
.
The corresponding form
attribute on the
<mo>
element, if present, must
must be an
ASCII caseinsensitive
match to one of these values.
The form
of an embellished operator is determined as follows:
form
attribute is present and valid
on the core operator, then its value is used;
prefix
;
<mpadded>
or
<msqrt>
with more than one inflow child
(ignoring all spacelike children) then it has
form postfix
;
postfix
;
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 operator has the
property.
The corresponding attributes on the
<mo>
element, if present, must be a
boolean.
The
lspace
,
rspace
,
minsize
properties of an embellished operator are
lengthpercentage.
The maxsize
property
of an embellished operator is either a
lengthpercentage or ∞.
The
lspace
,
rspace
,
minsize
and
maxsize
attributes on the
<mo>
element, if present,
must be a lengthpercentage.
The
stretchy
,
symmetric
,
largeop
,
movablelimits
,
lspace
,
rspace
,
maxsize
,
minsize
properties of
an embellished operator are determined as follows:
Content=T,Form=F
where F
is the form
of the
embellished operator;
form
of embellished operator was not explicitly specified
as an attribute on its core operator, then
user agents must try other dictionary entries for different
values of F
in the following order:
infix
, prefix
, postfix
;
false
for
stretchy
,
symmetric
,
largeop
and
movablelimits
properties ;
0.2777777777777778em
for
lspace
and
rspace
properties ;
100%
for the minsize
property and
∞ for the maxsize
property.
Percentage values for lspace
,
rspace
properties of an embellished operator
are interpreted relative to the value read from the dictionary
or to the fallback value above.
Percentages value for minsize
and
maxsize
properties of an embellished operator
are interpreted relative to
the target stretch size before application of
size constraints, as described in
.
Fontrelative lengths for
lspace
, rspace
,
minsize
and maxsize
rely on the
font style of the core operator, not the one of the
embellished operator.
If the <mo>
element does not have its computed
display
property equal to
math
or inlinemath
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:
<mo>
element is not
made
of a single character c
then fallback to the
layout algorithm of .
c
in the inline direction
with the current font then fallback to the
layout algorithm of .
T_{inline}
then
fallback to the
layout algorithm of .
T_{inline}
.
T_{inline}
and
at position determined by the previous box metrics.
c
in the block direction
with the current font then fallback to the
layout algorithm of .
(U_{ascent}, U_{descent})
then
fallback to the
layout algorithm of .
T_{ascent}
and
T_{descent}
to
S_{ascent}
and
S_{descent}
respectively:
S_{ascent}
=
max(
U_{ascent}
− AxisHeight,
U_{descent}
+ AxisHeight
) + AxisHeight
S_{descent}
=
max(
U_{ascent}
− AxisHeight,
U_{descent}
+ AxisHeight
) − AxisHeight
U_{ascent}
and
U_{descent}
respectively.
minsize
and maxsize
be the minsize and maxsize properties on the
operator. Percentage values are intepreted relative
to T
=
T_{ascent}
+
T_{descent}
.
If minsize
< 0 then set minsize
to 0.
If maxsize
< minsize
then
then set maxsize
to minsize
.
Then 0 ≤ minsize
≤ maxsize
:
T
= 0 then set
T_{ascent}
and
T_{descent}
to minsize
/2.
T
< minsize
then first
multiply
T_{ascent}
by minsize
/ T
and then set T_{descent}
to minsize

T_{ascent}
.
maxsize
< T
then first multiply
T_{ascent}
by
maxsize
/ T
and
then set T_{descent}
to maxsize
−
T_{ascent}
.
T_{ascent}
+
T_{descent}
.
The inline size of the content is the width of
the stretchy glyph. The stretchy glyph is shifted
towards the lineunder by a value Δ so that its
center aligns with the center of the target:
the ink ascent of the content is
the ascent of the stretchy glyph − Δ
and the ink descent of the content is
the descent of the stretchy glyph + Δ.
These centers have coordinates "½(ascent − descent)"
so Δ = [(ascent of stretchy glyph − descent of stretchy glyph) − (T_{ascent}
− T_{descent}
)] / 2.
T_{ascent}
+
T_{descent}
and at position determined by the previous box metrics
shifted by Δ towards the lineover.
mathstyle
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, fallback to the
largest nonbase glyph. If none is found, fallback to
the layout algorithm of .
If the algorithm to shape a stretchy glyph has been used for one of the step above, then the italic correction of the content is set to the value returned by that algorithm.
maxsize
is equal to its default value ∞
then minsize ≤ maxsize
is satisfied but
maxsize < T
is not.
<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 as well as the following
attributes:
The
mspace@width
,
mspace@height
,
mspace@depth
, if present, must
have a value that is a valid lengthpercentage.
An unspecified attribute, a percentage value, or an invalid value
is interpreted as 0
.
If one of the requested values calculated is negative then it is
treated as 0
.
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
math
or inlinemath
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
.
The mincontent inline size and
maxcontent inline size of the content are
equal to the requested inline size.
The inline size, lineascent and linedescent of the content
are respectively
the requested inline size, lineascent and linedescent.
A number of MathML presentation elements are "spacelike" 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.
A MathML Core element is a spacelike element if is is:
<mtext>
or
<mspace>
.
<mphantom>
is not
automatically defined to be spacelike, unless its content is
spacelike. This is because operator spacing is affected by
whether adjacent elements are spacelike.
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.
<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 . Its layout algorithm is
the same as the <mtext>
element.
In the following example, <ms> is used to write a literal string of characters:
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 lefttoright 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.
<mrow>
The
<mrow>
element is used to group together any number of subexpressions, 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 . An <mrow>
element with inflow children
child_{1}, child_{2}, … child_{N}
is laid out as show on . The child boxes
are put in a row one after the other with all their
alphabetic baselines
aligned.
The algorithm for stretching operators along the block axis consists in the following steps:
L_{ToStretch}
containing
embellished operators with
a stretchy property and block stretch axis ;
and a second list L_{NotToStretch}
.
L_{NotToStretch}
.
If L_{ToStretch}
is empty then stop.
If L_{NotToStretch}
is empty, perform
layout with stretch size constraint 0 on
all the items of L_{ToStretch}
.
U_{ascent}
and U_{descent}
as respectively the maximum
ink ascent and maximum ink descent of the margin boxes of
inflow children that
have been laid out in the previous step.
L_{ToStretch}
with
block stretch size constraint
(U_{ascent}, U_{descent})
.
<mrow>
If the element does not have its computed
display
property equal to
math
or inlinemath
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
A child box is slanted if it is not an embellished operator and has nonzero italic correction.
lspace
and
rspace
.
The mincontent inline size (respectively maxcontent inline size) are calculated using the following algorithm:
addspace
to true if
the element is a <math> or is not an
embellished operator; and to false otherwise.
inlineoffset
to 0.previousitaliccorrection
to 0.inlineoffset
by
previousitaliccorrection
.
addspace
is true then
increment inlineoffset
by
its lspace
property.
inlineoffset
by
the mincontent inline size
(respectively maxcontent inline size) of
the child's margin box.
previousitaliccorrection
to
its italic correction. Otherwise set it to 0.
addspace
is true then
increment inlineoffset
by
its rspace
property.
inlineoffset
by
previousitaliccorrection
.
inlineoffset
.
The inflow children are laid out using the algorithm for stretching operators along the block axis.
The inline size of the content is calculated like the mincontent inline size and maxcontent inline size of the content, using the inline size of the inflow children's margin boxes instead.
The ink lineascent (respectively lineascent) of the content is the maximum of the ink lineascents (respectively lineascents) of all the inflow children's margin boxes. Similarly, the ink linedescent (respectively linedescent) of the content is the maximum of the ink linedescents (respectively ink lineascents) of all the inflow children's margin boxes.
The inflow children are positioned using the following algorithm:
addspace
to true if
the element is a <math> or is not an
embellished operator; and to false otherwise.
inlineoffset
to 0.previousitaliccorrection
to 0.inlineoffset
by
previousitaliccorrection
.
addspace
is true then
increment inlineoffset
by
its lspace
property.
inlineoffset
and its block offset such
that the alphabetic baseline of the child is aligned with the alphabetic baseline.
inlineoffset
by
the inline size of the child's margin box.
previousitaliccorrection
to
its italic correction. Otherwise set it to 0.
addspace
is true then
increment inlineoffset
by
its rspace
property.
The italic correction of the content is set to the italic
correction of the last inflow child, which is
the final value of previousitaliccorrection
.
<mfrac>
The
<mfrac>
element is used for fractions. It can also be used to mark up
fractionlike objects such as binomial coefficients and Legendre symbols.
If the <mfrac>
element does not have its computed
display
property equal to math
or inlinemath
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 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 lengthpercentage.
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 fontsize.
The <mfrac>
element sets
displaystyle
to false
,
or if it was already false
increments
scriptlevel
by 1, within its children.
It sets mathshift 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 1pixel 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 inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called
numerator, the second inflow child is called
denominator and the layout algorithm is explained below.
<mfrac>
element has two children
that are inflow. Hence the CSS rules basically performs
scriptlevel
, displaystyle
and mathshift
changes for the numerator and
denominator.
If the fraction line thickness is nonzero, the
<mfrac>
element is laid out as shown on .
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 mincontent inline size (respectively maxcontent inline size) of content is the maximum between the mincontent inline size (respectively maxcontent inline size) of the numerator's margin box and the mincontent inline size (respectively maxcontent inline size) of the denominator's margin box.
If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.
The inline size of the content is the maximum between the inline size of the numerator's margin box and the inline size of the denominator's margin box.
NumeratorShift
is the maximum between:
compact
(respectively normal
).
compact
(respectively normal
) +
the ink linedescent of the numerator's margin box.
DenominatorShift
is the maximum between:
compact
(respectively normal
).
compact
(respectively normal
) +
the ink lineascent of the denominator's margin box −
the AxisHeight.
The lineascent of the content is the maximum between:
Numerator Shift
+
the lineascent of the numerator's margin box.
Denominator Shift
+
the lineascent of the denominator's margin box
The linedescent of the content is the maximum between:
Numerator Shift
+ the linedescent of the numerator's margin box.
Denominator Shift
+ the linedescent of the denominator's margin box.
The inline offset of the numerator (respectively denominator) is the half the inline size of the content − half the inline size of the numerator's margin box (respectively denominator's margin box).
The alphabetic baseline of the numerator (respectively denominator)
is shifted away from the alphabetic baseline by a distance of
NumeratorShift
(respectively
DenominatorShift
)
towards the lineover (respectively lineunder).
The inline size of the fraction bar is the inline size of the content and its inline offset is 0. The center of the fraction bar is shifted away from the alphabetic baseline by a distance of AxisHeight towards the lineover. Its block size is the fraction line thickness.
If the fraction line thickness is zero,
the <mfrac>
element is instead laid out as
shown on .
The mincontent inline size, maxcontent inline size and inline size of the content are calculated the same as in .
If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.
If the mathstyle is compact
then
TopShift
and
BottomShift
are respectively
set to StackTopShiftUp and StackBottomShiftDown.
Otherwise mathstyle is normal
and
they are respectively set to StackTopDisplayStyleShiftUp
and StackBottomDisplayStyleShiftDown.
The Gap
is defined to be
(BottomShift
−
the ink lineascent of the denominator's margin box) +
(TopShift
−
the ink linedescent of the numerator's margin box).
If mathstyle is compact
then GapMin
is StackGapMin
otherwise mathstyle is normal
and it is StackDisplayStyleGapMin.
If Δ = GapMin
− Gap
is positive then
TopShift
and BottomShift
are respectively increased by Δ/2 and Δ − Δ/2.
The lineascent of the content is the maximum between:
TopShift
+
the lineascent of the numerator's margin box.
BottomShift
+ the lineascent of the denominator's margin box.
The linedescent of the content is the maximum between:
TopShift
+ the linedescent of the numerator's margin box.
BottomShift
+ the linedescent of the denominator's margin box.
The inline offsets of the numerator and denominator are calculated the same as in .
The alphabetic baseline of the numerator (respectively denominator) is
shifted away from the alphabetic baseline by a distance of
TopShift
(respectively −
BottomShift
) towards the
lineover (respectively lineunder).
<msqrt>
, <mroot>
The
<msqrt>
and
<mroot>
elements construct radicals. 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 .
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 the first child (the square root). Also note these elements only change the fontsize 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 mathshift to
compact
.
The <mroot>
element sets
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 math
or inlinemath
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
inflow children,
its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called
mroot base and
the second inflow child is called
mroot index
and its layout algorithm is explained below.
<mroot>
element has two children
that are inflow. Hence the CSS rules basically performs
scriptlevel
and displaystyle
changes for the index.
The children of the
<msqrt>
element are laid out
using the algorithm of the <mrow>
element
to produce a box that is also called the msqrt base.
In particular, the
algorithm for stretching operators along the block axis is used.
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 gap is given by
RadicalVerticalGap
if the mathstyle is compact
and
RadicalDisplayStyleVerticalGap
if the mathstyle is normal
.
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.
The <msqrt>
element is laid out as shown on
.
The mincontent inline size (respectively maxcontent inline size) of the content is the sum of the preferred inline size of a glyph stretched along the block axis for the radical glyph and of the mincontent inline size (respectively maxcontent inline size) of the base's margin box.
The inline size of the content is the sum of the advance width of the box metrics of the radical glyph and of the inline size of the base's margin's box.
The lineascent of the content is the maximum between:
The linedescent of the content is the maximum between:
The inline size of the overbar is the inline size of the base's margin's box. The inline offsets of the base and overbar are also the same and equal to the width of the box metrics of the radical glyph.
The alphabetic baseline of the base is aligned with the alphabetic baseline. The block size of the overbar is RadicalRuleThickness. Its vertical center is shifted away from the alphabetic baseline by a distance towards the lineover equal to the lineascent of the content, minus the RadicalExtraAscender, minus half the RadicalRuleThickness.
Finally, the painting of the surd is performed:
The <mroot>
element is laid out as shown on
.
The root index is first ignored and the base and
radical glyph are laid out as
shown on figure
using the same algorithm as in
in order to produce a margin box B (represented in green).
The mincontent inline size (respectively maxcontent inline size) of the content is the sum of max(0, RadicalKernBeforeDegree), the index's mincontent inline size (respectively maxcontent inline size) of the index's margin box, max(−mincontent inline size, RadicalKernAfterDegree) (respectively max(−maxcontent inline size, RadicalKernAfterDegree)) and of the mincontent inline size (respectively maxcontent inline size) of B.
Using the same clamping, AdjustedRadicalKernBeforeDegree and AdjustedRadicalKernAfterDegree are respectively defined as max(0, RadicalKernBeforeDegree) and is max(−inline size of the index's margin box, RadicalKernAfterDegree).
The inline size of the content is the sum of AdjustedRadicalKernBeforeDegree, the inline size of the index's margin box, AdjustedRadicalKernAfterDegree and of the inline size of B.
The lineascent of the content is the maximum between:
The linedescent of the content is the maximum between:
The inline offset of the index is AdjustedRadicalKernBeforeDegree. The inlineoffset of the base is the same + the inline size of the index's margin box.
The alphabetic baseline of B is aligned with the alphabetic baseline. The alphabetic baseline of the index is shifted away from the lineunder edge by a distance of RadicalDegreeBottomRaisePercent × the block size of B + the linedescent of the index's margin box.
<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
. Its layout algorithm is the
same as the <mrow>
element.
<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 fontsize and placement of subscripts of their descendants. In MathML Core, one could just have used <mrow> elements instead.
<merror>
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 LaTeXlike input:
The <merror>
element accepts the attributes described in
. 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:
<mpadded>
The
<mpadded>
element renders the same as its inflow 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 as well as the following
attributes:
The
mpadded@width
,
mpadded@height
,
mpadded@depth
,
mpadded@lspace
and
mpadded@voffset
if present, must
have a value that is a valid lengthpercentage.
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).
Inflow children
of the <mpadded>
element are laid out
using the algorithm of the <mrow>
element
to produce the
mpadded inner box for the content with parameters called
inner inline size, inner lineascent and inner linedescent.
The requested <mpadded>
parameters are determined as follows:
width
(respectively height
,
depth
, lspace
, voffset
)
attributes are absent or invalid the requested width
(respectively height, depth, lspace, voffset)
is the inner inline size
(respectively inner lineascent, inner linedescent,
0
,
0
).
width
(respectively height
,
depth
, lspace
, voffset
)
attribute is a
lengthpercentage
then the requested width
(respectively height, depth, lspace, voffset)
is the resolved value
with percentage interpreted relative to
the inner inline size (respectively
inner lineascent, inner linedescent, 0
,
0
).
If one of the requested width, depth, height or lspace values calculated
above is negative then it is treated as 0
.
<mpadded>
If the <mpadded>
element does not have its
computed
display
property equal to math
or inlinemath
then it is laid out according to the CSS specification where
the corresponding value is described.
Otherwise, it is laid out as shown on
.
The mincontent inline size (respectively maxcontent inline size) of the content is the requested width calculated in but using the mincontent inline size (respectively maxcontent inline size) of the mpadded inner box instead of the "inner inline size".
The inline size of the content is the requested width calculated in .
The lineascent of the content is the requested height. The linedescent of the content is the requested depth.
The mpadded inner box is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by the requested voffset towards the lineover.
<mphantom>
Historically, the
<mphantom>
element was introduced to render
its content invisibly, but with the same metrics size and other dimensions,
including alphabetic baseline positionthat 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 . 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>
is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
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 generalpurpose 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.
<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
.
The following example, shows basic use of subscripts and superscripts. The fontsize is automatically scaled down within the scripts.
If the
<msub>
,
<msup>
or
<msubsup>
elements do not have their
computed
display
property equal to math
or inlinemath
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
<msub>
,
<msup>
, <msubsup>
If the <msub>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
msub base, the second inflow child is called the
msub subscript and the layout algorithm is explained
in .
If the <msup>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
msup base, the second inflow child is called the
msup superscript and the layout algorithm is explained
in .
If the <msubsup>
element
has less or more than three inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
msubsup base, the second inflow child
is called the msubsup subscript,
its third inflow child is called
the msupsup superscript and the layout algorithm is explained
in .
The <msub>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The
mincontent inline size (respectively maxcontent inline size) of the content is the
mincontent inline size (respectively maxcontent inline size) inline size of the base's margin box −
LargeOpItalicCorrection
+
mincontent inline size (respectively maxcontent inline size) of
the subscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
The inline size of the content
is the inline size of the base's margin box −
LargeOpItalicCorrection
+
the inline size of
the subscript's margin box + SpaceAfterScript.
SubShift
is the maximum between:
The lineascent of the content is the maximum between:
SubShift
.The linedescent of the content is the maximum between:
SubShift
.
The inline offset of the base is 0 and the inline offset of the
subscript is the inline size of the base's margin box −
LargeOpItalicCorrection
.
The base is placed so that its alphabetic baseline
matches the alphabetic baseline. The subscript is placed so that its alphabetic baseline
is shifted away from the alphabetic baseline by SubShift
towards the lineunder.
The <msup>
element is laid out as shown on
.
ItalicCorrection
is the italic correction of the base
if it is not an embellished operator with
the largeop
property and 0 otherwise.
The
mincontent inline size (respectively maxcontent inline size) of
the content
is the
mincontent inline size (respectively maxcontent inline size) of
the base's margin box +
ItalicCorrection
+
the mincontent inline size (respectively maxcontent inline size) of
the superscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
The inline size of the content
is the inline size of the base's margin box +
ItalicCorrection
+
the inline size of
the superscript's margin box + SpaceAfterScript.
SuperShift
is the maximum between:
compact
, or
SuperscriptShiftUp otherwise.The lineascent of the content is the maximum between:
SuperShift
.The linedescent of the content is the maximum between:
SuperShift
.
The inline offset of the base is 0 and the inline offset of
superscript is the inline size of the base's margin box +
ItalicCorrection
.
The base is placed so that its alphabetic baseline
matches the alphabetic baseline. The superscript is placed so that its
alphabetic baseline
is shifted away from the alphabetic baseline by SuperShift
towards the lineover.
The <msubsup>
element is laid out as shown on
.
LargeOpItalicCorrection
and SubShift
are set as in .
ItalicCorrection
and SuperShift
are set as in .
The mincontent inline size (respectively maxcontent inline size and inline size) of the content is the maximum between the mincontent inline size (respectively maxcontent inline size and inline size) of the content calculated in and .
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint 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 base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
SubSuperGap
is the gap between the two scripts
along the block axis and is defined by
(SubShift
− the ink lineascent of the subscript's
margin box) +
(SuperShift
− the ink linedescent of the
superscript's margin box).
If SubSuperGap
is not at least
SubSuperscriptGapMin then the following steps are
performed to ensure that the condition holds:
SuperShift
− the ink linedescent of the
superscript's margin box).
If Δ > 0 then set Δ to the minimum between Δ set
SubSuperscriptGapMin − SubSuperGap
and
increase SuperShift
(and so
SubSuperGap
too) by Δ.
SubSuperGap
.
If Δ > 0 then
increase SubscriptShift
(and so
SubSuperGap
too) by Δ.
The ink lineascent (respectively lineascent, ink linedescent,
linedescent) of the content
is set to the maximum
of the
ink lineascent (respectively lineascent, ink linedescent,
linedescent) of the content
calculated in
in and
but using the adjusted values SubShift
and
SuperShift
above.
The inline offset and block offset of the base and scripts are performed the same as described in and .
Even when the subscript (respectively superscript) is an empty
box, <subsup>
does not generally render the same as
(respectively )
because of the additional constraint on
SubSuperGap
.
Moreover, positioning the empty subscript
(respectively superscript)
may also change the total size.
In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.
<munder>
, <mover>
, <munderover>
The <munder>
,
<mover>
and
<munderover>
elements are used to
attach
accents or limits placed under or over a MathML expression.
The <munderover>
element accepts the attribute
described in as well as the
following attributes:
Similarly, the <mover>
element
(respectively <munder>
element) accepts the
attribute described in
as well as the accent
attribute (respectively the
accentunder
attribute).
accent
,
accentunder
,
attributes, if present, must have values that are booleans.
User agents must implement them as described in
.
The following example, shows basic use of under and over scripts. The fontsize 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 math
or inlinemath
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
<munder>
,
<mover>
, <munderover>
If the <munder>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
munder base and the second inflow child is called the
munder underscript.
If the <mover>
element
has less or more than two inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
mover base and the second inflow child is called the
mover overscript.
If the <munderover>
element
has less or more than three inflow children, its layout algorithm
is the same as the <mrow>
element.
Otherwise, the first inflow child is called the
munderover base, the second inflow child
is called the munderover underscript
and its third inflow child is called
the munderover overscript.
If the
<munder>
, <mover>
or
<munderover>
element have a computed
mathstyle property equal to compact
and their base is an embellished operator with the
movablelimits
property, then
their layout algorithms are respectively
the same as the ones described for
<msub>
, <msup>
and
<msubsup>
in
,
and
.
Otherwise, the
<mover>
, <mover>
and
<munderover>
layout algorithms are respectively
described in
,
and
The algorithm for stretching operators along the inline axis is as follows.
L_{ToStretch}
containing
embellished operators with
a stretchy property and inline stretch axis ;
and a second list L_{NotToStretch}
.
L_{NotToStretch}
.
If L_{ToStretch}
is empty then stop.
If L_{NotToStretch}
is empty, perform
layout with stretch size constraint 0 on
all the items of L_{ToStretch}
.
T
to
the maximum inline size of the
margin boxes of child boxes that have been laid out in the
previous step.
L_{ToStretch}
with inline stretch size constraint T
.
The <munder>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The mincontent inline size (respectively maxcontent inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the mincontent inline size (respectively maxcontent inline size) of the base's margin box and underscript's margin box.
The inflow children are laid out using the algorithm for stretching operators along the inline axis.
The inline size of the content is calculated by determining the absolute difference between:
LargeOpItalicCorrection
.LargeOpItalicCorrection
.
If m is the minimum calculated in the second item above then the
inline offset
of the base is −m − half the inline size of the base's margin box.
The inline offset of the underscript is
−m − half the inline size of the underscript's margin box −
half LargeOpItalicCorrection
.
Parameters
UnderShift
and UnderExtraDescender
are determined by considering three cases in the following order:
The base is an
embellished operator with the
largeop
property.
UnderShift
is the maximum of
UnderExtraDescender
is 0.
The base is an
embellished operator with the
stretchy
property
and stretch axis inline.
UnderShift
is the maximum of:
UnderExtraDescender
is 0.
UnderShift
is equal to UnderbarVerticalGap
if the accentunder attribute is equal to
false
and to zero otherwise.
UnderExtraAscender
is
UnderbarExtraDescender.
The lineascent of the content is the maximum between:
UnderShift
.The linedescent of the content is the maximum between:
UnderShift
+ UnderExtraAscender
.
The alphabetic baseline of the base is aligned with the alphabetic baseline.
The alphabetic baseline of the underscript is shifted away from the alphabetic baseline
and towards the lineunder by a distance equal to
the ink linedescent of the base's margin box
+ UnderShift
.
The <mover>
element is laid out as shown on
.
LargeOpItalicCorrection
is the italic correction of the base
if it is an embellished operator with
the largeop
property and 0 otherwise.
The mincontent inline size (respectively maxcontent inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the mincontent inline size (respectively maxcontent inline size) of the base's margin box and underscript's margin box.
The inflow children are laid out using the algorithm for stretching operators along the inline axis.
The TopAccentAttachment
is the
top accent attachment of the overscript or
half the inline size of the overscript's margin box
if it is undefined.
The inline size of the content is calculated by applying the algorithm for stretching operators along the inline axis for layout and determining the absolute difference between:
TopAccentAttachment
+
half LargeOpItalicCorrection
.TopAccentAttachment
+
half LargeOpItalicCorrection
.
If m is the minimum calculated in the second item above then the
inline offset
of the base is −m − half the inline size of the base's margin.
The inline offset of the overscript is
−m − half the inline size of the overscript's margin box +
half LargeOpItalicCorrection
.
Parameters
OverShift
and OverExtraDescender
are determined by considering three cases in the following order:
The base is an
embellished operator with the
largeop
property.
OverShift
is the maximum of
OverExtraAscender
is 0.
The base is an
embellished operator with the
stretchy
property and
stretch axis inline.
OverShift
is the maximum of:
OverExtraDescender
is 0.
Otherwise, OverShift
is equal to
false
.
OverExtraAscender
is OverbarExtraAscender.
The lineascent of the content is the maximum between:
OverShift
+ OverExtraAscender
.The linedescent of the content is the maximum between:
OverShift
.
The alphabetic baseline of the base is aligned with the alphabetic baseline.
The alphabetic baseline of the overscript is shifted away from the alphabetic baseline
and towards the lineover by a distance equal to
the ink lineascent of the base + OverShift
.
The general layout of <munderover>
is shown on
. The
LargeOpItalicCorrection
,
UnderShift
,
UnderExtraDescender
,
OverShift
,
OverExtraDescender
parameters
are calculated the same as in
and
.
The mincontent inline size, maxcontent inline size and inline size of the content are calculated as an absolute difference between a maximum inline offset and minimum inline offset. These extrema are calculated by taking the extremum value of the corresponding extrema calculated in and . The inline offsets of the base, underscript and overscript are calculated as in these sections but using the new minimum m (minimum of the corresponding minima).
Like in these sections, the inflow children are laid out using the algorithm for stretching operators along the inline axis.
The lineascent and linedescent of the content are also calculated by taking the extremum value of the extrema calculated in and .
Finally, the alphabetic baselines of the base, undescript and overscript are calculated as in sections and .
When the underscript (respectively overscript) is an empty box, the base and overscript (respectively underscript) are laid out similarly to (respectively ) 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.
<mmultiscripts>
Presubscripts and tensor notations are represented
the <mmultiscripts>
with hints given by the
<mprescripts>
(to distinguish postscripts and prescripts)
and
<none>
elements
(to indicate empty scripts).
These element accept the attributes described in
.
The following example, shows basic use of prescripts and postscripts, involving <none> and <mprescripts>. The fontsize is automatically scaled down within the scripts.
If the
<mmultiscripts>
,
<mprescripts>
or
<none>
elements do not have their
computed
display
property equal to math
or inlinemath
then they are laid out according to the CSS specification where
the corresponding value is described.
Otherwise, the layout below is performed.
The empty
<mprescripts>
and <none>
elements are laid out as an <mrow>
element.
A valid <mmultiscripts>
element contains the
following inflow children:
<mprescripts>
element.
<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.
<mprescripts>
element and
an even number of inflow children called
mmultiscripts prescripts, none of them being a
<mprescripts>
element.
These scripts form a (possibly empty) list of
subscript/superscript pair.
If an <mmultiscripts>
element is not valid then
it is laid out the same as the
<mrow>
element.
Otherwise the layout algorithm is explained below.
<none>
element is preserved for backward
compatibility reasons but is actually not taken into account
in the layout algorithm.
The <mmultiscripts>
element is laid out as
shown on .
For each postscript pair, the ItalicCorrection
LargeOpItalicCorrection
are defined as
in
and .
The mincontent inline size (respectively maxcontent inline size) of the content is calculated the same as the inline size of the content below, but replacing "inline size" with "mincontent inline size" (respectively "maxcontent inline size") for the base's margin box and scripts's margin boxes.
If there is an inline stretch size constraint or a block stretch size constraint the base is also laid out with the same stretch size constraint. Otherwise it is laid out without any stretch size constraint. The other elements are always laid out without any stretch size constraint.
The inline size of the content is calculated with the following algorithm:
inlineoffset
to 0.
For each prescript pair, increment
inlineoffset
by SpaceAfterScript + the
maximum of
inlineoffset
by the inline size of the
base's margin box and
set inlinesize
to inlineoffset
.
For each postscript pair, modify
inlinesize
to be at least:
LargeOpItalicCorrection
.
ItalicCorrection
.
Increment inlineoffset
to the maximum of:
Increment inlineoffset
by
SpaceAfterScript.
inlinesize
SubShift
(respectively SuperShift
)
is calculated by taking the maximum of all subshifts
(respectively supershifts) of each
subscript/superscript pair as described in
.
The lineascent of the content is calculated
by taking the maximum of all the lineascent
of each subscript/superscript pair as described in
but using the SubShift
and
SuperShift
values calculated above.
The linedescent of the content is calculated
by taking the maximum of all the linedescent
of each subscript/superscript pair as described in
but using the SubShift
and
SuperShift
values calculated above.
Finally, the placement of the inflow children is performed using the following algorithm:
inlineoffset
to 0.For each prescript pair:
inlineoffset
by
SpaceAfterScript.
pairinlinesize
to the maximum of
inlineoffset
+ pairinlinesize
− the inline size of the subscript's margin box.
inlineoffset
+ pairinlinesize
− the inline size of the superscript's margin box.
SubShift
(respectively SuperShift
)
towards the lineunder (respectively lineover).
inlineoffset
by
pairinlinesize
.
<mprescript>
boxes
at inline offsets
inlineoffset
and with their alphabetic baselines
aligned with the alphabetic baseline.
For each postscript pair:
pairinlinesize
to the maximum of
inlineoffset
− LargeOpItalicCorrection
.
inlineoffset
+ ItalicCorrection
.
SubShift
(respectively SuperShift
)
towards the lineunder (respectively lineover).
inlineoffset
by
pairinlinesize
inlineoffset
by
SpaceAfterScript.
An <mmultiscripts>
with only one
postscript pair is laid out the same as a
<msubsup>
with the same inflow 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 or <none>
scripts in a special
way.
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 caseinsensitive
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 caseinsensitive
match to "true"
do not increment scriptlevel within
their second child.
<mmultiscripts>
sets
mathshift
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 mathshift
to
compact
on their second child.
An <mover>
and
<munderover>
elements with an accent
attribute that is an
ASCII caseinsensitive
match to "true"
also sets mathshift
to
compact
within their first child.
The must contain the following style in order to implement this behavior:
<mprescript>
is empty.
Hence the CSS rules essentially performs automatic displaystyle
and
scriptlevel
changes for the scripts ; and
mathshift
changes for
subscripts and sometimes the base.
Matrices, arrays and other tablelike mathematical notation are marked up
using
<mtable>
<mtr>
<mtd>
elements. These elements are similar to the
<table>
,
<tr>
and
<td>
elements of [[HTML]].
The following example, 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.
<mtable>
The <mtable>
is laid out as an
inlinetable
and sets
displaystyle
to false
. The
user agent stylesheet must contain
the following rules in order to implement these properties:
The mtable
element is as a CSS
table
and the
mincontent inline size, maxcontent inline size,
inline size, block size,
first baseline set and last baseline set
sets are determined
accordingly.
The center of the table is aligned with the math axis.
<mtr>
The <mtr>
is laid out as
tablerow
. The
user agent stylesheet must contain
the following rules in order to implement that behavior:
<mtd>
The <mtd>
is laid out as
a tablecell
with content centered in the cell and
a default padding. The
user agent stylesheet must contain
the following rules:
The <mtd>
accepts the attributes described
in as well as the following attributes:
The columnspan
(respectively
rowspan
) attribute has the same
syntax and semantic as the
<colspan>
(respectively
<rowspan>
)
attribute on the <td>
element from [[HTML]].
columnspan
as in [[MathML3]] and not
colspan
as in [[HTML]].
Historically, the
<maction>
element provides a mechanism
for binding actions to expressions.
The <maction>
element accepts the attributes described
in as well as the following
attributes:
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
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>
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]].
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 <annotationxml>
element.
The following example, shows how the fraction "one half" can be annotated with a textual annotation (LaTeX) or an XML annotation (content MathML). These annotations are not intended to be rendered by the user agent.
The <semantics>
element accepts the attributes
described in . 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:
The <annotationxml>
and
<annotation>
element accepts the attributes
described in 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 <annotationxml>
and <annotation>
element is the same as the <mtext>
element.
/* Hide the annotated child. */ semantics > :firstchild { display: none; } /* Show all text annotations. */ semantics > annotation { display: inline; } /* Show all HTML annotations. */ semantics > annotationxml[encoding="text/html" i], semantics > annotationxml[encoding="application/xhtml+xml" i] { display: inlineblock; }
display: math
and display: inlinemath
valueThe display
property
from
is extended with new values value:
<displayold>  math  inlinemath
For the <math>
,
<mtable>
,
<mtr>
and
<mtd>
elements, the
math
value respectively computes to
inline
,
inlinetable
,
tablerow
and tablecell
.
MathML Core elements with display: math
or
display: inlinemath
control box generation and layout according to their tag name, as
described in the relevant sections while
Unknown MathML elements with display: math
or display: inlinemath
behave the same as the <mrow>
element.
For elements that are not MathML elements, the
display: math
value
and display: inlinemath
computes to
none
.
display: math
and
display: inlinemath
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 overriden to render its content as a grid.
texttransform
valuesThe texttransform
property
from
is extended with new values:
<texttransformold>  mathauto  mathbold  mathitalic  mathbolditalic  mathdoublestruck  mathboldfraktur  mathscript  mathboldscript  mathfraktur  mathsansserif  mathboldsansserif  mathsansserifitalic  mathsansserifbolditalic  mathmonospace  mathinitial  mathtailed  mathlooped  mathstretched
On text nodes containing a unique character, mathauto
has
the same effect as mathitalic
, otherwise it has no effects.
For the
mathbold
,
mathitalic
,
mathbolditalic
,
mathdoublestruck
,
mathboldfraktur
,
mathscript
,
mathboldscript
,
mathfraktur
,
mathsansserif
,
mathboldsansserif
,
mathsansserifitalic
,
mathsansserifbolditalic
,
mathmonospace
,
mathinitial
,
mathtailed
,
mathlooped
and
mathstretched
values, the transformed text is
obtained by performing conversion of each character according to
the corresponding
bold,
italic,
bolditalic,
doublestruck,
boldfraktur,
script,
boldscript,
fraktur,
sansserif,
boldsansserif,
sansserifitalic,
sansserifbolditalic,
monospace,
initial,
tailed,
looped,
stretched tables.
User agents may decide to rely on italic, bold and bolditalic
fontlevel properties when available fonts lack the proper glyphs to
perform mathauto
, mathitalic
,
mathbold
, mathbolditalic
characterlevel
transforms.
The following example shows a mathematical formula where "exp" is rendered with normal variant, "A" with bold variant, "gl" with fraktur variant, "n" using italic variant and and "R" using doublestruck variant.
Values other than mathauto
are intended to infer
specific contextdependent mathematical meaning.
In the previous example, one can guess that the author
decided to use the convention of bold variables for
matrices, fraktur variables for Lie algebras and doublestruck
variables for set of numbers. Although the corresponding Unicode
characters could have been used directly in these cases, it may
be helpful for authoring tools or polyfills to support these
transformations via the texttransform
property.
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
mathauto
property is intended to implement this
default behavior, which can be overriden by authors if necessary.
Note that mathematical fonts are designed with special kind
of italic glyphs located at the Unicode positions of
, which differ from the shaping
obtained via italic font style. Compare this
mathematical formula
rendered with the Latin Modern Math font using
fontstyle: italic
(left) and
texttransform: mathauto
(right):
mathstyle
propertyName: 
mathstyle


Value:  normal  compact 
Initial:  normal 
Applies to:  All elements 
Inherited:  yes 
Percentages:  n/a 
Media:  visual 
Computed value:  specified keyword 
Canonical order:  n/a 
Animation type:  not animatable 
When mathstyle
is compact
,
the math layout on descendants try to minimize the
logical height by
applying the following rules:
fontsize
is scaled down when
scriptlevel(auto)
is specified
(default for <mfrac>)
as described in .The following example shows a
mathematical formula renderered with
its <math>
root styled with
mathstyle: compact
(left) and
mathstyle: normal
(right).
In the former case, the fontsize 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
fontsize) is larger.
These two mathstyle
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 mathstyle 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.
mathshift
propertyName: 
mathshift


Value:  normal  compact 
Initial:  normal 
Applies to:  All elements 
Inherited:  yes 
Percentages:  n/a 
Media:  visual 
Computed value:  specified keyword 
Canonical order:  n/a 
Animation type:  not animatable 
If the value of mathshift
is compact
, the math layout on descendants will use the
superscriptShiftUpCramped parameter to place superscript.
If the value of mathshift
is normal
, the math
will use the superscriptShiftUp parameter instead.
This property is used for positioning superscript during the layout of MathML scripted elements. See § and .
In the following example, the two "x squared" are rendered with
compact mathstyle and the same fontsize
.
However, the one within the square root is rendered with
compact mathshift
while
the other one is rendered with
normal mathshift
, 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 mathshift 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.
scriptlevel()
function for fontsizeThe fontsize
property
from
is extended with new values:
<fontsizeold>  scriptlevel(auto)  scriptlevel(add(<integer>))  scriptlevel(<integer>)
Each element has an internal scriptlevel which is determined as folows:
scriptlevel(auto)
and
the inherited value of mathstyle
is compact
then the internal scriptlevel of
the element is the one of its parent plus one.
scriptlevel(add(<integer>))
then the
internal scriptlevel is the one of its parent plus
the specified integer.
scriptlevel(<integer>)
then the
internal scriptlevel of the element is the specified
integer.
If the specified value fontsize is of the form
scriptlevel(...)
then the computed value of
fontsize is obtained by multiplying the inherited value of
fontsize
by a nonzero scale factor calculated by the
following procedure:
InvertScaleFactor
to true.InvertScaleFactor
to false.InvertScaleFactor
is false and 1/S otherwise.The following example shows a mathematical formula with normal mathstyle rendered with the Latin Modern Math font. When entering subexpressions like scripts or fractions, the fontsize is automatically scaled down according to the values of MATH table contained in that font. Note that fontsize 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 mathstyle in fractions.
These rules from [[TeXBook]] are subtle and it's worth having a
separate scriptlevel()
function 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 scriptlevel changes.
MATH
table
This chapter describes features provided by MATH
table
of an OpenType font [[OPENFONTFORMAT]]. Throughout this chapter,
a Clike notation
Table.Subtable1[index].Subtable2.Parameter
is used to
denote OpenType parameters.
Such parameters may not be available (e.g. if the font lack one of the
subtable, has an invalid offset, etc) and so fallback options are
provided.
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
fontsize
or zoom level.
MathConstants
)These are global layout constants for a given mathematical font:
post.underlineThickness
MATH.MathConstants.scriptPercentScaleDown / 100
or
0.71 if MATH.MathConstants.scriptPercentScaleDown
is
null or not available.
MATH.MathConstants.scriptScriptPercentScaleDown / 100
or
0.5041 if
MATH.MathConstants.scriptScriptPercentScaleDown
is
null or not available.
MATH.MathConstants.displayOperatorMinHeight
or
Default fallback constant
if the constant is not available.MATH.MathConstants.axisHeight
or
Default fallback constant if the constant is not available.MATH.MathConstants.accentBaseHeight
or OS/2.sxHeight
if the constant is not available.MATH.MathConstants.subscriptShiftDown
or OS/2.ySubscriptYOffset
if the constant is not available.MATH.MathConstants.subscriptTopMax
or ⅘ × OS/2.sxHeight
if the constant is not available.MATH.MathConstants.subscriptBaselineDropMin
or
Default fallback constant if the constant is not available.MATH.MathConstants.superscriptShiftUp
or OS/2.ySuperscriptYOffset
if the constant is not available.MATH.MathConstants.superscriptShiftUpCramped
or
Default fallback constant if the constant is not available.MATH.MathConstants.superscriptBottomMin
or ¼ × OS/2.sxHeight
if the constant is not available.MATH.MathConstants.superscriptBaselineDropMax
or
Default fallback constant if the constant is not available.MATH.MathConstants.subSuperscriptGapMin
or 4 × default rule thickness if the constant is not available.MATH.MathConstants.superscriptBottomMaxWithSubscript
or ⅘ × OS/2.sxHeight
if the constant is not available.MATH.MathConstants.spaceAfterScript
or 1/24em if the constant is not available.MATH.MathConstants.upperLimitGapMin
or
Default fallback constant if the constant is not available.MATH.MathConstants.upperLimitBaselineRiseMin
or Default fallback constant if the constant is not available.MATH.MathConstants.lowerLimitGapMin
or Default fallback constant if the constant is not available.MATH.MathConstants.lowerLimitBaselineDropMin
or Default fallback constant if the constant is not available.MATH.MathConstants.stackTopShiftUp
or Default fallback constant if the constant is not available.MATH.MathConstants.stackTopDisplayStyleShiftUp
or Default fallback constant if the constant is not available.MATH.MathConstants.stackBottomShiftDown
or Default fallback constant if the constant is not available.MATH.MathConstants.stackBottomDisplayStyleShiftDown
or Default fallback constant if the constant is not available.MATH.MathConstants.stackGapMin
or 3 × default rule thickness if the constant is not available.MATH.MathConstants.stackDisplayStyleGapMin
or 7 × default rule thickness if the constant is not available.MATH.MathConstants.stretchStackTopShiftUp
or Default fallback constant if the constant is not available.MATH.MathConstants.stretchStackBottomShiftDown
or Default fallback constant if the constant is not available.MATH.MathConstants.stretchStackGapAboveMin
or upperLimitGapMin if the constant is not available.MATH.MathConstants.stretchStackGapBelowMin
or lowerLimitGapMin if the constant is not available.MATH.MathConstants.fractionNumeratorShiftUp
or Default fallback constant if the constant is not available.MATH.MathConstants.fractionNumeratorDisplayStyleShiftUp
or stackTopDisplayStyleShiftUp if the constant is not available.MATH.MathConstants.fractionDenominatorShiftDown
or Default fallback constant if the constant is not available.MATH.MathConstants.fractionDenominatorDisplayStyleShiftDown
or stackBottomDisplayStyleShiftDown if the constant is not available.MATH.MathConstants.fractionNumeratorGapMin
or default rule thickness if the constant is not available.MATH.MathConstants.fractionNumDisplayStyleGapMin
or 3 × default rule thickness if the constant is not available.MATH.MathConstants.fractionRuleThickness
or default rule thickness if the constant is not available.MATH.MathConstants.fractionDenominatorGapMin
or default rule thickness if the constant is not available.MATH.MathConstants.fractionDenomDisplayStyleGapMin
or 3 × default rule thickness if the constant is not available.MATH.MathConstants.overbarVerticalGap
or 3 × default rule thickness if the constant is not available.MATH.MathConstants.overbarRuleThickness
or default rule thickness if the constant is not available.MATH.MathConstants.overbarExtraAscender
or default rule thickness if the constant is not available.MATH.MathConstants.underbarVerticalGap
or 3 × default rule thickness if the constant is not available.MATH.MathConstants.underbarRuleThickness
or default rule thickness if the constant is not available.MATH.MathConstants.underbarExtraDescender
or default rule thickness if the constant is not available.MATH.MathConstants.radicalVerticalGap
or 1¼ × default rule thickness if the constant is not available.MATH.MathConstants.radicalDisplayStyleVerticalGap
or default rule thickness + ¼ OS/2.sxHeight
if the constant is not available.MATH.MathConstants.radicalRuleThickness
or default rule thickness if the constant is not available.MATH.MathConstants.radicalExtraAscender
or radicalRuleThickness if the constant is not available.MATH.MathConstants.radicalKernBeforeDegree
or 5/18em if the constant is not available.MATH.MathConstants.radicalKernAfterDegree
or −10/18em if the constant is not available.MATH.MathConstants.radicalDegreeBottomRaisePercent / 100.0
or 0.6 if the constant is not available.MathGlyphInfo
)These are perglyph tables for a given mathematical font:
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
or 0
otherwise.
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
or half the advance width of the glyph otherwise.
MathVariants
)
This section describes how to handle stretchy glyphs of arbitrary
size using the MATH.MathVariants
table.
GlyphAssembly
tableThis section is based on [[?OPENTYPEMATHINHARFBUZZ]]. For convenience, the following definitions are used:
MATH.MathVariant.minConnectorOverlap
.
GlyphPartRecord
is an extender
if and only if
GlyphPartRecord.partFlags
has the
fExtender
flag set.
GlyphAssembly
is horizontal
if it is obtained from
MathVariant.horizGlyphConstructionOffsets
.
Otherwise it is vertical (and obtained from
MathVariant.vertGlyphConstructionOffsets
).
GlyphAssembly
table,
N_{Ext} (respectively
N_{NonExt}) is the number of extenders
(respectively nonextenders) in
GlyphAssembly.partRecords
.
GlyphAssembly
table,
S_{Ext} (respectively
S_{NonExt}) is the sum of
GlyphPartRecord.fullAdvance
for all extenders (respectively nonextenders) in
GlyphAssembly.partRecords
.
User agents must treat the GlyphAssembly
as invalid
if the following conditions are not satisfied:
GlyphPartRecord
in GlyphAssembly.partRecords
,
the values of
GlyphPartRecord.startConnectorLength
and
GlyphPartRecord.endConnectorLength
must be at least o_{min}.
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) = N_{NonExt} + r N_{Ext} while the stretch size is AssembySize(o, r) = S_{NonExt} + r S_{Ext} − o (AssemblyGlyphCount(r) − 1).
r_{min} is the minimal number of repetitions needed to obtain an assembly of size at least T i.e. the minimal r such that AssembySize(o_{min}, r)) ≥ T. It is defined as the maximum between 0 and the ceiling of ((T − S_{NonExt} + o_{min} (N_{NonExt} − 1)) / S_{Ext,NonOverlapping}).
o_{max} is the maximum overlap possible to build an assembly of size at least T by repeating each extender r_{min} times. If AssemblyGlyphCount(r_{min}) ≤ 1, then the actual overlap value is irrelevant. Otherwise, o_{max} 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(o_{max}, r_{min}).
The glyph assembly width, glyph assembly ascent and glyph assembly descent are defined as follows:
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.
GlyphAssembly
is horizontal,
the width is glyph assembly stretch size
for a given target size T
while
the ascent (respectively descent) is the
the maximum ascent (respectively descent) of the glyphs of id
GlyphPartRecord.glyphID
for all the
GlyphPartRecord
in
GlyphAssembly.partRecords
.
The glyph assembly height is the sum of the glyph assembly ascent and glyph assembly descent.
T
.
The shaping of the glyph assembly is performed with the following algorithm:
(x, y)
to (0, 0)
,
RepetitionCounter
to 0 and
PartIndex
to 1.
RepetitionCounter
is 0, then
PartIndex
.PartIndex
is
GlyphAssembly.partCount
then stop.Part
to
GlyphAssembly.partRecords[PartIndex]
.
Set RepetitionCounter
to
r_{min} if
Part
is an extender and to 1 otherwise.
Part.glyphID
so that its (left, baseline) coordinates
are at position (x, y)
.
Set x
to
x + Part.fullAdvance −
o_{max}
Part.glyphID
so that its (left, bottom) coordinates
are at position (x, y)
.
Set y
to
y − Part.fullAdvance +
o_{max}
RepetitionCounter
.The preferred inline size of a glyph stretched along the block axis is calculated using the following algorithm:
S
to the glyph's advance width.
MathGlyphConstruction
table
in the MathVariants.vertGlyphConstructionOffsets
table for the given glyph:
MathGlyphVariantRecord
in
MathGlyphConstruction.mathGlyphVariantRecord
,
ensure that S
is at least
the advance width of the glyph of id
MathGlyphVariantRecord.variantGlyph
.
GlyphAssembly
subtable,
then ensure
that S
is at least the
glyph assembly width.
S
.
The algorithm to shape a stretchy glyph to inline
(respectively block) dimension T
is the following:
MathGlyphConstruction
table
in the MathVariants.horizGlyphConstructionOffsets
table (respectively
MathVariants.vertGlyphConstructionOffsets
table)
for the given glyph the exit with failure.
T
then use normal shaping and bounding box for that glyph,
the MathItalicsCorrectionInfo for that glyph as
italic correction and exit with success.
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.
GlyphAssembly
subtable
then use the bounding box given by
glyph assembly width,
glyph assembly ascent, the value
GlyphAssembly.italicsCorrection
as italic
correction, perform shaping of the glyph assembly and
exit with success.
T
, then choose last one that was tried and exit
with success.
@namespace url(http://www.w3.org/1998/Math/MathML); /* Default display */ /* Links */ /* The <math> element */ /* <mrow>like elements */ /* Token elements */ /* Tables */ /* Fractions */ /* Other rules for scriptlevel, displaystyle and mathshift */
The following dictionary for default values of
of operators
when they are not specified via explicit attributes or equal to
the generic default values. Please refer to
for explanation about
how to use this dictionary and how to
determine the values Content
and
Form
indexing it.
Tables below are suitable for computer manipulation,
see for an alternative
presentation.
This compact form removes about 800 entries from the original
operator dictionary that actually
correspond to default values.
They are not necessary since they are handled by the
fallback case of
anyway. For other
(Content
, Form
)
key, the search is done as follows:
stretchy
, symmetric
largeop
, movablelimits
to false
.
Content
as an UTF16 string does not have length
or 1 or 2 then exit with NotFound
status.
Content
is a single character in the
range U+0320–U+03FF
then exit with NotFound
status. Otherwise,
if it has two characters:
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,
then set properties according to category I of
and move to the last step.Content
with the first character.Content
it 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
".
NotFound
status.Content
, Form
) from
and
either exit with NotFound
status or and move to
the next point. More precisely, this can be done as follows:
Content
, Form
)
according to .
If a result is found then set the properties according to
.
Otherwise exit with NotFound
status.
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
NotFound
status.
Key
is at most 0x0FFF.
Key
according to whether Form
is infix
, prefix
,
postfix
respectively.
Key
is at most 0x2FFF.
Entry
in table
such Entry
% 0x4000 is equal to
Key
. Either exit with
NotFound
status or
set the properties corresponding to the category with
encoding Entry
/ 0x1000 in
.
lspace
, rspace
,
stretchy
, symmetric
largeop
,
movablelimits
)
value.
When encoded as ranges, one can perform a binary search by looking for the range start, followed by an extra check on the range length. Since log is concave, it is worse to do one binary search on each large subtable of than one binary search on the whole table of . One can see that there are several contiguous Unicode blocks, so encoding tables as ranges allow to get almost 8 bits per entry.
Alternatively, it is possible to use a perfect hash function to implement table lookup in constant time [[?gperf]] [[?CMPH]]. This would instead take 16 bits per entry, plus 16 bits per extra empty entry (for nonminimal perfect hash function) as well as extra data to store the hash function parameters. For minimal perfect hash function, the theorical lower bound for storing these parameters is 1.44bits/entry and existing algorithms range from close to that limit up to 4bits/entry.
The default stretch axis for all characters is block. However, the stretch axis for the following characters is inline:
The following dictionary provides a humanreadable version
of . Please refer to
for explanation about
how to use this dictionary and how to
determine the values Content
and Form
indexing together
the dictionary.
The values for rspace and lspace are indicated
in the corresponding columns.
The values of
stretchy
,
symmetric
,
largeop
,
movablelimits
,
are true
if they are listed in the "properties" column.
The following table gives mappings between spacing and non spacing characters when used in MathML accent constructs.
The following table provide 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
works the same except with some adjustments:
MathVariants.horizGlyphConstructionOffsets[]
item ;
if it is vertical it corresponds to
a MathVariants.vertGlyphConstructionOffsets[]
item.
MathGlyphConstruction.mathGlyphVariantRecord
is
always empty.
MathVariants.minConnectorOverlap
,
GlyphPartRecord.startConnectorLength
and
GlyphPartRecord.endConnectorLength
are treated as 0.
MathGlyphConstruction.GlyphAssembly.partRecords
is built
from each table row as follows:
texttransform
Mappingsboldscript
mappingsbolditalic
mappingstailed
mappingsbold
mappingsfraktur
mappingsscript
mappingsmonospace
mappingsinitial
mappingssansserif
mappingsdoublestruck
mappingslooped
mappingsstretched
mappingsitalic
mappingsboldfraktur
mappingssansserifbolditalic
mappingssansserifitalic
mappingsboldsansserif
mappingsMathML Core is based on MathML3. See the appendix E of [[MathML3]] for the people that contributed to that specification.
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é GreinerPetter, Anne van Kesteren, Boris Zbarsky, Brian Smith, Daniel Marques, David Carlisle, Deyan Ginev, Elika Etemad, Emilio Cobos Álvarez, ExE Boss, Ian Kilpatrick, Koji Ishii, L. David Baron, Michael Kohlhase, Michael Smith, Moritz Schubotz, Murray Sargent, Ryosuke Niwa, Sergey Malkin, Tab Atkins Jr., Viktor Yaffle and frankvel.
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.
Community Group members who have regularly participated to MathML Core meetings during the development of this specification: Brian Kardell, Bruce Miller, David Carlisle, Murray Sargent, Frédéric Wang, Neil Soiffer (Chair), Patrick Ion, Rob Buis, David Farmer, Steve Noble, Daniel Marques, Sam Dooley.
As explained in ,
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"
DOMException
when one tries to access the canvas' content via JavaScript APIs.
This specification adds an href
attribute that
can be used to make MathML elements match
:link
and
:visited
pseudoclasses and one could rely on
these features to determine whether a link has been visited.
UAs may implement suggestions from [[SELECT]] to preserve the
user's privacy.
This specification only adds script execution mechanisms in the
the MathML event handler attributes described in
and
in javascript:...
links for the href
attribute. UAs may decide to apply the same
security restrictions as HTML and SVG to prevent execution of scripts
in these attributes.
This specification describes layout of a DOM elements which may involve system fonts. Like for HTML/CSS layout, it is thus possible to use JavaScript APIs to measure box sizes and positions and infer data from system fonts (e.g. default fonts, available glyphs, font layout parameters...). The only font informations that are not exposed by other existing Web APIs are the math layout data described in .
<maction>
element with
the actiontype
value set to "statusline"
in order to override the text of the browser statusline. In particular,
this could be used to hide the URL text of an untrusted
href
link. This has been removed in MathML Core
and the <maction>
element essentially behaves
like an <mrow>
container with extra style.
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 nonnormative, 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, 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.