Copyright © 19982017 W3C^{®} (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This specification defines a core subset of Mathematical Markup Language, or MathML. 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.
Compared with prior versions of MathML, this specification tries to be 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 version 3 [OpenFontFormat3]. It also focuses on compatibility with existing technologies of web rendering engines [HTML5] by relying as much as possible on CSS, text & table layout and box models.
This document is governed by the 1 March 2017 W3C Process Document.
This section is nonnormative.
The [MathML3] specification has two serious shortcomings that make it hard to implement presentation MathML in web rendering engines:
The MathML 3 specification intentionally does not contain any detailed
rendering rules. As a consequence, the fact that web rendering engines are
compliant with the MathML 3 specification does not necessarily mean that they
will have the rendering quality expected by most readers.
For example, the specification essentially just says that
“mfrac element is used for fractions” and that the default medium
linethickness “is left up to the rendering agent” [MathML3].
As a comparison, to determine the exact spacing and thickness of
fractions and stacks the
TeXBook’s Appendix G [TeXBook] relies on parameters
σ_{8}, σ_{9}, ξ_{8}, 3ξ_{8}, 7ξ_{8},
σ_{11} and σ_{12} while the MATH table of the Open Font Format
[OpenFontFormat3] extends these to parameters
FractionNumeratorDisplayStyleShiftUp
,
FractionNumeratorShiftUp
,
FractionNumeratorDisplayStyleGapMin
,
FractionNumeratorGapMin
,
FractionRuleThickness
,
FractionDenominatorDisplayStyleGapMin
,
FractionDenominatorGapMin
,
FractionDenominatorDisplayStyleShiftDown
,
FractionDenominatorShiftDown
,
StackTopDisplayStyleShiftUp
,
StackTopShiftUp
,
StackDisplayStyleGapMin
,
StackGapMin
,
StackBottomDisplayStyleShiftDown
and
StackBottomShiftDown
.
The MathML 3 specification is designed as an independent
XML language and browser vendors have almost not been involved in the
standardization process. The Math WG and WHATWG worked together to
integrate MathML in [HTML5]
but MathML3 has inconsistencies and lacks of details when it comes to
interaction with CSS / HTML5 features: vertical writing mode,
user stylesheet, mstyle
inheritance, outofflow elements,
attributes sensitiveness, definition of space characters...
The MathML 3 specification is sometimes biased by MathML rendering and
authoring tools behaving quite differently from web rendering engines.
Hence it is not always obvious whether all features are fundamental or
whether they fit well into the web rendering engine codebase.
For example, the <mfenced> element is just a
“convenient form in which to express common constructs involving fences”
but is strictly equivalent to an expanded form with <mrow> and
<mo> elements. It requires web rendering engines
to create many “anonymous”
rendering frames and keep them uptodate, to duplicate the logic
for drawing and exposing the content of fenced expressions etc.
[MathML3].
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 [OpenFontFormat3]. Focus has been put on keeping compatible with existing technologies of web rendering engines [HTML5] by relying as much as possible on CSS, text & table layout and box models. As a consequence, parts of MathML 3 that do not fit well in this framework or are rarely used in practice have been ommited and moved into a larger specification [MathML4].
By increasing the level of implementation details and by focusing more on browserdriven design, this specification is expected to greatly improve MathML interoperability. A auto is available in a separate auto. Browser vendors are encouraged to use these tests during implementation & automated testing. Contribution of new tests and error reports are welcome.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, are to be interpreted as described in [IETFRFC2119].
This document relies on many definitions taken from the MATH specification of the Open Font Format [OpenFontFormat3]. These values are written with the following style: This is a definition from the MATH specification.
User agents must use a HTML5 [HTML5] parser to build a DOM tree [DOM1] from the source code of web pages. In particular, they must follow the rules describing when elements must be in the MathML namespace http://www.w3.org/1998/Math/MathML and must recognize the entity definitions from the HTML MathML entity set of [XMLEntities]. They must also take into account the following integration points between SVG, MathML and HTML as allowed by [ValidatorSchemas]:
The <math> element can be used at any position permitted for phrasing content or inside SVG <foreignObject> elements.
The <svg> element can be used inside <annotationxml> elements with encoding SVG1.1 or image/svg+xml.
The <html> element and flow content can be used inside <annotationxml> elements with encoding application/xhtml+xml or text/html.
Any phrasing element can be used inside <mtext> elements.
From this DOM tree, user agents must provide a visual representation of the document. The DOM tree may be dynamically modified using Javascript [ECMA262] and the user agents must keep the visual representation in synchronization with the DOM tree.
All MathML elements accept the id
, class
and style
attributes
[MathML3]. They must be interpreted as described in section 3.2.5 of the
HTML5 specification [HTML5] and in particular they specify a unique
identifier (to identify elements in links and scripting), affect
CSS selectors, affect getElementsByClassName() and enable authors to do
inline styling.
MathML 3 allows to use the href
attribute on any MathML element
[MathML3]. In the present document, it is only required to implement
href
on the mrow
element with the behavior described in 4.8
of the HTML5 specification for the a
element [HTML5]. It is
recommended to make links visually distinguisable by default, for example by
adding a rule in the user agent stylesheet (section 2.3.2) such as
mrow[href] { color: blue; }
The toplevel math
element accepts the altimg
, altimgwidth,
altimgheight, altimgvalign and alttext
attributes.
These attributes allow to specify fallback content and must be ignored by
user agents for rendering purpose. User agents that do not follow the current
implementation note, may follow implementation suggestions from Appendix
auto in order to use that fallback image.
The toplevel math
element also accepts the display
attribute,
mathcolor
, mathbackground
attributes as well as other attributes
from the mstyle
element. These attributes must be supported and this
may be achieved using specific rules in the user agent stylesheet
as described in section 2.3.2.
In general MathML elements or attributes that are not mentioned in this document may just be ignored. This includes deprecated attributes or Content Markup described in chapter 4 of the MathML 3 specification [MathML3].
User agents must contain an operator dictionary describing the default properties of operators. For interoperability, it is recommended to use the one proposed in the nonnormative Appendix C of [MathML3].
Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. This behavior is specified in math fonts using the USE_TYPO_METRICS flag from the OS/2 table [OpenFontFormat3] and user agents must honor that flag.
Mathematical formulas can be viewed as an extension of standard text layout and thus user agents must be able to perfom complex text layout [CTL] using fonts under the Open Font Format [OpenFontFormat3]. In particular, they must implement bidirectional rendering and shaping of Arabic scripts.
Mathematical formulas may mix standard text with other graphical outlines
(e.g. fraction or top radical bars). For consistency, these outlines should
be rendered the same way as normal text. In particular, user agents must be
able to apply visibility
and color
CSS properties to them. They may
also support similar CSS properties for text such as textshadow or
opacity
.
Good mathematical rendering requires use of nonUnicode glyphs. Mathematical
fonts may only provide these glyphs when the math
script tag is enabled and so user agents must ensure that the text within
MathML token elements is rendered with that script tag. Some characters like
primes already have script size by default and hence would be too small when
used in a script position.
Hence user agents must support glyph selections via the OpenType font feature
ssty
(Script Style) in order to display such
“prescripted” characters with the appropriate size.
For bidirectional layout, Unicode defines characterlevel mirroring
to transform a character into its mirrored form,
for example U+0028 LEFT PARENTHESIS into U+0029 RIGHT PARENTHESIS.
User agents must also support the OpenType font feature
rtlm
(Righttoleft mirrored forms)
to allow glyphlevel mirroring in cases where characterlevel is not enough
[OpenFontFormat3].
At the time of writing, Unicode does not distinguish between Chancery and
Spencerian style for the Unicode MATHEMATICAL SCRIPT characters. Some
mathematical fonts rely on salt
or ssXY
properties to provide
both styles. User agents may support the CSS fontvariantalternates
property and corresponding OpenType font features to enable page authors
to get access to these styles [CSS3Font] [OpenFontFormat3].
User agents must be able to read information from the
OpenType MATH table [OpenFontFormat3].
In particular they must be able to read the values from the
MathConstants
subtable.
They must also be able to use the MathVariants
subtable
to solve the following problem: given a particular default glyph shape and a
certain width or height, find a variant shape glyph (or a construct created by
putting several glyphs together) that has the required measurement.
More information are provided in see section 4.2.3.
Mathematical rendering rules in this document are implicitly based on MathML, OpenType MATH table and the TeXBook [MathML3] [OpenFontFormat3] [TeXBook]. In this section, we describe more precisely some rules from the TeXBook.
In addition to concepts similar to MathML’s displaystyle
and
scriptlevel
, LaTeX has
a “cramped” property, which is involved in the determination of script shifts.
It is initially unset on the math
element and in general
all the children inherits the “cramped” property from their parent.
However, it is set to true in the following children:
The denominator of an mfrac
element. See section 4.3.2.
The subscripts of the msub
, msubsup
,
munder
and munderover
elements.
See section 4.4.
The overscript of the
mover
and munderover
elements when it is an accent
per
the MathML specification. See section 4.4.
The children of the msqrt
and mroot
elements.
To implement math spacing, the TeXBook defines eight basic types
(Ord
for ordinary atoms, Op
for large operators,
Bin
for binary operations, Rel
for relations,
Open
for opening fences, Close
for closing fences,
Punct
for punctuations and Inner
for a delimited subformula) and
define an inter space for each pair of such types. In the present document,
we only follow the spacing algorithm of MathML 3: by default the inter space
is always zero and the spacing is produced by spacing elements like
mspace
, mphantom
or mpadded
or by the leading and trailing
space around embellished operators.
User agents must support the CSS language [CSS2] and must take special
styling into account when building the visual representation of the document.
Many of the MathML elements accept attributes with length value whose
general syntax is described in section 2.1.5.2 of the MathML specification
[MathML3]. In general,
the syntax is compatible with [CSS2] but user agents must handle
specificities of the MathML specification. In particular, the keywords
veryverythinmathspace
,
verythinmathspace
,
thinmathspace
,
mediummathspace
,
thickmathspace
,
verythickmathspace
,
veryverythickmathspace
,
negativeveryverythinmathspace
,
negativeverythinmathspace
,
negativethinmathspace
,
negativemediummathspace
,
negativethickmathspace
,
negativeverythickmathspace
and
negativeveryverythickmathspace
must be interpreted as their
equivalent em
value. Also, percent values must be interpreted
with respect to the appropriate reference value.
Note that the mpadded
element also accepts more general length values as discussed in section
4.3.6.
User agents must support at least the following properties:
display
: at least inline, block, inlinetable, tablerow,
tablecell and none. It is used for the math
and tabular
elements. Appropriate values may be specified in the user agent stylesheet
as described in section 2.3.2.
direction
. The dir
attribute on the math
, mstyle
,
mrow
and token
elements must be mapped to that property.
font
property and its shorthands. The mathsize
attribute on
the math
, mstyle
and token elements must mapped to that property.
background
and color
. The mathcolor
and
mathbackground
attributes on presentation MathML elements must be
mapped to these properties.
visibility
. It is is used for the mphantom
element and may be
specified in the user agent stylesheet as described in section
2.3.2.
User agents must support the displaystyle
attribute. This may be
implemented using a new mathmlmathstyle property described in
table 2.3.1. The expected behavior may be completely
specified in the user agent stylesheet as described in section
2.3.2.
User agents must support the mathvariant
attribute. This may be
implemented using a new mathmlmathvariant property described in
table Unknown Reference. The expected behavior may be implemented by
mapping mathvariant
attributes on the math
, mstyle
and token
elements to mathmlmathvariant. Then during the rendering of text nodes,
the mathmlmathvariant value must be taken into account to remap
some characters to their equivalent code points, as specified by the MathML
specification. However, as indicated in section 2.2.2, when
mathmlmathvariant is none
on an mi
element with a single
character, it must actually be treated as if the mathvariant was italic
.
User agents must implement the scriptlevel
attributes and support
automatic incrementation of the scriptlevel
described in the MathML
specification.
Because mathematical formulas are generally written with special fonts, the
default user agent stylesheet must reset the CSS fontfamily on the
math
element to serif
. User agents should then use their own
mechanism to try and interpret this serif
value on the math
element
as a font with an OpenType MATH table.
Below is an example on a stylesheet to style MathML elements on which the User Agents may rely. Unfortunately, some rendering engines do not allow universal selectors in their user agent stylesheets and so rules must be expanded to list all possible MathML elements described in the present document. For example mfrac > * can be converted into mfrac > mi, mfrac > mn, mfrac > mo, mfrac > mtext, mfrac > mspace, mfrac > ms, mfrac > mrow, mfrac > mfrac, mfrac > msqrt, mfrac > mroot, mfrac > mstyle, mfrac > merror, mfrac > mpadded, mfrac > mphantom, mfrac > menclose, mfrac > msub, mfrac > msubsup, mfrac > munder, mfrac > mover, mfrac > munderover, mfrac > mmultiscripts, mfrac > mtable, mfrac > maction.
@namespace url(http://www.w3.org/1998/Math/MathML); /* The <math> element */ math { direction: ltr; display: inline; fontsize: inherit; fontstyle: normal; fontfamily: serif; mathmlmathstyle: inline; } math[display="block"] { display: block; textalign: center; mathmlmathstyle: display; } math[display="inline"] { display: inline; mathmlmathstyle: inline; } math[displaystyle="false"] { mathmlmathstyle: inline; } math[displaystyle="true"] { mathmlmathstyle: display; } /* Links */ mrow[href] { color: blue; } /* Tabular elements */ mtable { display: inlinetable; mathmlmathstyle: inline; } mtable[displaystyle="true"] { mathmlmathstyle: display; } mtable[frame="none"] { border: none; } mtable[frame="solid"] { border: solid thin; } mtable[frame="dashed"] { border: dashed thin; } mtr, mlabeledtr { display: tablerow; verticalalign: baseline; } mlabeledtr > mtd:firstchild { display: none; } mtd { display: tablecell; verticalalign: inherit; textalign: center; padding: 0.5ex 0.4em; } /* The <ms> element */ ms { display: inline; } ms:before, ms:after { content: "\0022" } ms[lquote]:before { content: attr(lquote) } ms[rquote]:after { content: attr(rquote) } /* The <merror> element */ merror { outline: solid thin red; backgroundcolor: lightYellow; } /* The <mphantom> element */ mphantom { visibility: hidden; } /* Scriptlevel and displaystyle for other elements */ mstyle[displaystyle="false"] { mathmlmathstyle: inline; } mstyle[displaystyle="true"] { mathmlmathstyle: display; } mfrac > * { mathmlscriptlevel: auto; mathmlmathstyle: inline; } mroot > :not(:firstchild) { mathmlscriptlevel: incrementby 2; mathmlmathstyle: inline; } msub > :not(:firstchild), msup > :not(:firstchild), msubsup > :not(:firstchild), mmultiscripts > :not(:firstchild) { mathmlscriptlevel: incrementby 1; mathmlmathstyle: inline; } munder > :not(:firstchild), mover > :not(:firstchild), munderover > :not(:firstchild) { mathmlmathstyle: inline; }
Several MathML elements have attributes sharing common syntax for constructs such as 3.1 or color. the syntax for these attributes is defined below.
MathML Core attributes of type length must have value consisting of an optional U+002D HYPHENMINUS () followed by a string of characters representing a length or percentage as specifed by HTML5 percentages and lengths.
MathML Core attributes of type color must have value consisting of a string of characters representing a color as specified by HTML5 color.
User agents must also follow the rules described in section 4.7.14
Embedded content, MathML of [HTML5], in particular the equivalence with
implicit mtext
and merror
to handle nonconforming MathML markup.
MathML elements have the following box model. The <math> root may have inline or block display, as suggested in section 2.3.2. Tabular MathML elements have table, tablerow and tablecell display as discussed in section 4.5. The <math> and <mtd> elements generate an anonymous <mrow> MathML box child that contains the boxes of their children and use the box parameters below to layout this anonymous <mrow> box. No line breaking can happen within MathML boxes and the mincontent width is equal to the maxcontent width, these are simply called the intrinsic width. Each MathML box has the following parameters:
intrinsic width W.
logical width w, ascent above the origin a and descent below the origin b. The height is then a + b.
ink ascent A and descent B, corresponding to the exact box enclosing ink of text and bars within the MathML box.
For MathML element containing only text nodes or foreign elements, we assume that the content is simple enough to determine these values. For example, in most case, this is just a single text node and w = W. A MathML element containing only other MathML elements follow special rules to layout their children at position (x_{i}, y_{i}) with parameters W_{i}, w_{i}, a_{i}, b_{i}, A_{i}, B_{i}. Then as a general rule, its box parameters are given by taking the union of child boxes, that is:
w = max_{1 ≤ i ≤ n} (x_{i} + w_{i}) − max_{1 ≤ i ≤ n} x_{i}
W = max_{1 ≤ i ≤ n} (x_{i} + W_{i}) − max_{1 ≤ i ≤ n} x_{i}
a = max_{1 ≤ i ≤ n} (a_{i} − y_{i})
b = max_{1 ≤ i ≤ n} (b_{i} + y_{i})
A = max_{1 ≤ i ≤ n} (A_{i} − y_{i})
B = max_{1 ≤ i ≤ n} (B_{i} + y_{i})
Note that the schemas in this document are drawn assuming lefttoright
directionality. If the CSS direction
is set to righttoleft, then the
elements should be layout by making the xaxis pointing from righttoleft.
In this document, we use the terminology of [MathML3]: “leading”
means “left” in righttoleft and “right” in righttoleft mode, while
“trailing” means “right” in righttoleft and “left” in righttoleft
mode.
The MathItalicsCorrectionInfo
table contains the italic
correction of some glyphs, which provides a measure of how slanted the
glyphs are (see figure 2). The
MathTopAccentAttachment
table also contains a reference
points that is used for the horizontal positioning of glyphs as an accent
(see figure 3). In later sections, we
generalize this by claiming that all MathML boxes have italic correction
and top accent attachment values. The values for glyphs are used to try and
extend to token elements or to special boxes that do not change child metrics.
Otherwise fallback values are used: 0 for italic correction and half
the width of the box for top accent attachment.
The present document assumes that W, w, a, b, A, B, italic correction
and top accent attachment are nonnegative values. If computations result
in negative values, then they must be interpreted as being zero.
Note that some MathML elements such as mspace
or mpadded
may set box
dimensions to negative values.
For compatibility with HTML5 rendering, the MathML layout is performed in two independent steps:
In the first step, we determine the intrinsic width W of MathML boxes. To do so we just follow the description given in this document for each MathML box. We rely on vertical positions x as well as values for italic correction and top accent attachment. However, we ignore any vertical positioning or metrics.
In the second step, we do the final layout of MathML boxes following the description given in this document. We obtain all the box metrics, including the actual width w, vertical metrics a, b, A, B and vertical positions y.
In order to perform the first step independently of the second one, the
horizontal metrics must not depend on the vertical metrics. As described in
section 4.3.6, this adds some restrictions on the possible pseudounits
of the mpadded
element. As indicated in section 4.2.3,
the width of size variants or of the glyph assembly used for vertical stretchy
operators may depend on the target size to cover. Taking the maximum widths
for all these size variants or for the glyph assembly during the first step
makes the intrinsic width independent of the target size but may lead to a
small overestimation.
Each of this step is done recursively: the metrics of a given MathML box are determined from those of the child boxes. User agents must implement the “Exception for embellished operators” described in [MathML3]. This means that the actual stretching of operators described in section 4.2.3 may be “delayed” until we reach the top of its embellished operator subtree. We then have to apply the current operation again to this embellished operator (intrinsic width determination or layout). Fortunately, such embellished operator subtrees are not deep in practice.
This document does not require support for operator stretching in table cells.
The “delayed” stretching of all operators must then be performed when we
arrive at the anonymous <mrow> child of <math> and <mtd>
elements.
That way, the intrinsic width of this anonymous <mrow> is welldefined
for the layout of mtable
elements and of the containers of the
<math> element. Similarly, the final layout of this anonymous
<mrow> is already done when we want to perform the one of its ancestors.
An 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.
In general, the mi
element must be treated the same as the mtext
element. However, when the mathvariant
on an mi
element is
none
and the mi
content is made of a single character then the
element must behave as if mathvariant
was actually set to italic
.
An 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.
For the layout algorithm described in this document, the
mn
element must be treated the same as the mtext
element.
An 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. We will use the term "operator" in this chapter to refer to operators in
this broad sense.
Many properties of an mo
element can be specified via attribute on
that element. The default value of the form
of an mo
element is
obtained as described in section “Default value of the form attribute” of
[MathML3]. From the form
and the text content, we can deduce other
default values from the operator dictionary or use the fallback values given
in “Dictionarybased attributes” of [MathML3].
The leading space lspace
and trailing space rspace
must be added on
each side of the mo
element (or its outermost embellished ancestor).
In most cases, the mo
element is treated as an mtext
element.
However, when an mo
element with a single character must be displayed as
a large operator then instead we use the MathVariants
table to try and find a glyph of height at least
DisplayOperatorMinHeight
(figure 4). If none is found, we fallback to the
largest one. Because this parameter does not always give
the best size, user agents may also use the following heuristic: ensure
that the large variant height is at least 2 times as large as the base height
for integrals and √2 times as large as the base height for other
operators.
When an mo
element with a single character must be displayed as a
horizontal or vertical
operator then instead of displaying the normal character we use
the MathVariants
table to try and find a glyph
that has at least the desired size or an assembly from several glyphs
to cover at least the desired size
(figure 5). The rules for vertical stretching
are a bit more complicated and are described in section
“Vertical Stretching Rules” of [MathML3]. If the operator has property
symmetric="true", it must be stretched symmetrically with respect to
the math axis, which is given by the AxisHeight
value.
Figure 6 compares the symmetric
and nonsymmetric stretching.
The size variant or construction used for vertical stretchy operators will depend on the target size to cover. To determine the intrinsic width W of the operator, we consider the maximum of all possible widths for the base size, size variants and construction available for the given operator. It is assumed that the width of the operator is almost independent of the stretch size, which is the case in practice for most math fonts and operators.
See section 4.3.1 for details about how to treat “embellished ancestor”, and how decide when to display operators larger or when to stretch them vertically & horizontally.
An 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.
In most cases the <mtext> element contains some text that is laid out without line breaks using complex text layout [CTL]. It is assumed that we can measure the ink ascent & descent, logical ascent & descent and advance width of the text frame and use these values for the MathML box of the <mtext> element.
If the trailing glyph of the text content has an entry in the
MathItalicsCorrectionInfo
table then the specified
value is used as the italic correction.
User agents may subtract the advance width from the abscissa of the trailing
ink edge as a heuristic value for the italic correction of the <mtext>
element when it is not specified in the
MathItalicsCorrectionInfo
table.
If the text content is made of a single glyph and this glyph
has an entry in the MathTopAccentAttachment
table
then the specified value is used as the top accent attachment of the
<mtext> element.
If the CSS direction
on the <mtext> element is set to righttoleft
then user agents must enable the rtlm
OpenType feature on text nodes
unless it contradicts what the page author has specified with the
fontfeaturesettings CSS property.
If <mtext> is used at a nonzero scriptlevel then user agents must
enable the ssty
OpenType feature on text nodes unless it contradicts
what the page author has specified with the fontfeaturesettings
CSS property.
In the most general case, the <mtext> element may contain text with line breaks or arbitrary HTML5 phrasing elements. We assume that we can still determine logical dimensions and maxcontent width of the text content and use it for both the logical and ink values of the <mtext> element. The italic correction and top accent attachment are assigned the fallback values indicated in section 4.1.1
An mspace
empty element represents a blank space of any desired size, as set by its attributes.
The ms
element is used to represent "string literals" in expressions meant to be interpreted
by computer algebra systems or other systems containing "programming languages".
In general, ms
must be treated the same as the mtext
element except that quotes are automatically added around its content.
The user agents may implement the lquote
or rquote
attributes
with the following style in the user agent stylesheet as suggested in section
2.3.2:
ms { display: inline; } ms:before, ms:after { content: "\0022" } ms[lquote]:before { content: attr(lquote) } ms[rquote]:after { content: attr(rquote) }
An 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".
The dir
attribute must be mapped to the direction
CSS property.
The current version of this document does not define any linebreaking algorithm
for the mrow
element, user agents may just ignore linebreaking rules.
User agents must follow the rules for inferred mrow
s described in
[MathML3]. For example, to layout
<msqrt>child_1 child_2 child_3 ...</msqrt>, one must follow the layout
rules described for msqrt
in section 4.3.3 using
the box of <mrow>child_1 child_2 child_3 ... child_N</mrow> as the base.
The <mrow>child_1 child_2 child_3 ... child_N</mrow> element is laid
out as show on figure 8. The boxes of child_{1}, child_{2}, … child_{N} are put in a horizontal row
one after the other with all their baselines aligned. As a consequence of this
and of child box models, graphical elements such as fraction bars
or symmetric stretchy operators will also be
aligned along the math axis when the
AxisHeight
is unchanged (e.g. in the typical case
where the math font is unchanged).
As indicated in section auto, we generally do not add special spacing
around the children. For example, the leading and trailing spacing is already
included in the box metrics of embellished operators. The only exception is
for the italic correction: when a “slanted” child is
followed by a “straight” child, then an horizontal
space corresponding to the italic correction of the “slanted” child is added
between the two children [OpenFontFormat3]. The italic correction of the
last child is also added after that child when it is “slanted” and when
the mrow
has more than one child. In this document, we interpret
“slanted” as a child that is not an operator with
largeop="true" (or an embellished operator whose mo
element core
has largeop="true") and has nonzero italic correction and “straight”
as “nonslanted”.
When the mrow
element contains only one child then the previous
description implies that the box metrics of the mrow
is the same as
the one of its unique child. As indicated in section 4.1.1, we thus
use the italic correction and top accent attachment of the child as the
corresponding values of the mrow
box.
The mfrac
element is used for fractions. It can also be used to mark up fractionlike objects
such as binomial coefficients and Legendre symbols. The syntax for mfrac
is
<mfrac> numerator denominator </mfrac>
The displaystyle
and scriptlevel
changes be achieved with the
following style in the user agent stylesheet as suggested in section
2.3.2:
mfrac > * { mathmlscriptlevel: auto; mathmlmathstyle: inline; }
The axis of the mfrac
element is always given by
AxisHeight
.
The default line thickness is given by
FractionRuleThickness
Use the linethickness
attribute [MathML3] to determine the
actual thickness of the fraction bar. A percent or unitless length is
interpreted as a multiple of the default rule thickness.
The color and visibility of the fraction bar must honor the values given by the
color
and visibility
CSS properties on the mfrac
element.
If the actual line thickness is nonzero, the mfrac
element is laid out as
shown on figure 9.
The width is given by the maximum width of the
numerator and denominator and the numerator and denominator are horizontally
centered. A fraction bar with the actual thickness is drawn centered on the
axis height. The numerator and denominator are shifted
up and down using the values FractionNumeratorShiftUp
,
FractionDenominatorShiftDown
in inline style and
FractionNumeratorDisplayStyleShiftUp
,
FractionDenominatorDisplayStyleShiftDown
in display style.
If necessary, these shift values are increased to ensure that the gaps between
the numerator/denominator and fraction bar satisfy the minimal values provided
by FractionDenominatorGapMin
and
FractionNumeratorGapMin
in inline style and
FractionDenominatorDisplayStyleGapMin
and
FractionNumeratorDisplayStyleGapMin
in display style.
If the actual line thickness is zero,
the mfrac
element is instead laid out as
shown on figure 10.
The gap between the top and bottom boxes
is equally split around the axis height. The relevant shift values are now
StackTopShiftUp
,
StackBottomShiftDown
in inline style and
StackTopDisplayStyleShiftUp
,
StackBottomDisplayStyleShiftDown
in display style.
If necessary, the two shift values are increased by a same value to ensure
the gap between the top and bottom boxes satisfy the values provided by
by StackGapMin
in inline style and
StackDisplayStyleGapMin
in display style.
In order to prevent the fraction bar to be confused with other items around
the fraction (e.g. minus sign or the bar of another fraction), a 1 pixel space
must actually be added on each side of the mfrac
element.
If the numerator is an embellished operator and the mfrac
element is the
outermost element in this embellished operator hierarchy then the operator
leading and trailing spaces must be added around the fraction.
The MathML specification describes radicals as follows [MathML3]:
These 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 syntax for these elements is:
<msqrt> base </msqrt>
<mroot> base index </mroot>
The displaystyle
and scriptlevel
changes be achieved with the
following style in the user agent stylesheet as suggested in section
2.3.2:
mroot > :not(:firstchild) { mathmlscriptlevel: increment 2; mathmlmathstyle: inline; }
The line thickness of the overbar is given by
RadicalRuleThickness
.
The gap between the overbar and base is given by
RadicalVerticalGap
in inline style and RadicalDisplayStyleVerticalGap
in display style.
The ascent above the overbase is given by RadicalExtraAscender
.
The surd is drawn by trying to vertically stretch the character
U+221A SQUARE ROOT
to at least the sum of the ink height of the base, the radical gap and the
radical rule thickness. If the CSS direction
is set to righttoleft,
then the surd is actually drawn from the glyph obtained by mirroring
U+221A SQUARE ROOT via the rtlm
OpenType feature.
The color and visibility of the surd and overbar must honor the values given by
the color
and visibility
CSS properties on the msqrt
element.
The msqrt
element is laid out as shown on figure
11.
The width is given by the sum of the width of the surd and of the base.
The baseline of the square root matches the baseline of the base.
The ink box is determined from the ink boxes of the surd and base while the
logical box takes into account the extra ascender
The mroot
element is laid out as shown on figure 12.
We start by ignoring the root index and we layout the base and surd as
shown on figure 11 to obtain a box B.
The horizontal metrics of the mroot
element are obtained by putting
RadicalKernBeforeDegree
before the root index, then placing the root index, then a kerning
of RadicalKernAfterDegree
after the root index and finally placing B. In general
the kerning before the root index is positive while the kerning after it is
negative,
which means that the root element will have some space before it and that the
root index will overlap the surd.
For the vertical metrics of the mroot
element, we first take the baseline
of B as the baseline. We graduate the ink height of B with a linear
scale going from the bottom at coordinate 0 to the top at coordinate 1.
Then the ink bottom of the root index will
be vertically positioned at coordinate
RadicalDegreeBottomRaisePercent
.
Finally, we take into consideration the box of the root index and B to deduce
the metrics for the whole box of the mroot
element.
The mstyle
element is used to make style changes that affect the
rendering of its contents.
For the layout algorithm described in this document, the
mstyle
element must be treated the same as the mrow
element.
However, some attributes on the mstyle
element must be mapped to CSS
properties as indicated in section 2.3.1.
All the other mstyle
attributes not defined in this document must be ignored.
The merror
element displays its contents as an ”error message”. This might be done, for example,
by displaying the contents in red, flashing the
contents, or changing the background color.
For the layout algorithm described in this document, the
merror
element must be treated the same as the mrow
element.
The user agent stylesheet must set some CSS properties on the merror
element in order to highlight the error.
As suggested in section 2.3.2, this can for example be achieved
with the rule:
merror { outline: solid thin red; backgroundcolor: lightYellow; }
An mpadded
element renders the same as its child content, but with the
size of the child’s bounding box and the relative positioning point of its
content modified according to mpadded
’s attributes.
See [MathML3] for how the metrics of mpadded
element are determined.
Note that pseudounits allows horizontal metrics to depend on vertical metrics,
for example width="2height" which can be problematic to determine
intrinsic widths. Hence in the present document, if
the value of the width
and lspace
attributes contains
”height” or ”depth” pseudounits, then they must be ignored.
The mpadded
element is laid out as shown on figure
13.
The height, depth and width of the content in [MathML3] corresponds to
the logical box of the content. The content of the mpadded
element is
positioned from the origin of the mpadded
element as follows: We shift
the content
forward by a distance of lspace
and shift it upward by a distance of
voffset
. The logical metrics of the mpadded
element are given by the
height, depth and width of the mpadded
element described in
[MathML3]. The ink metrics of the mpadded
element match their logical
metrics.
The mphantom
element renders invisibly, but with the same size and other dimensions, including
baseline position, that its contents would have if they were rendered normally.
For the layout algorithm described in this document, the
mphantom
element must be treated the same as the mrow
element.
The user agent stylesheet must set some CSS properties on the mphantom
element in order to hide its content.
As suggested in section 2.3.2, this can for example be achieved
with the rule:
mphantom { visibility: hidden; }
The menclose
element renders its content inside the enclosing notation specified by its notation
attribute.
The color and visibility of the menclose
notations must honor the values
given by the color
and visibility
CSS properties on the
menclose
element.
Based on [OpenFontFormat3] [TeXBook], we use the notation ξ_{8}
from the TeXBook to denote the default rule thickness and use
3ξ_{8} for gaps.
We actually let ξ_{8} be OverbarRuleThickness
.
Note that contrary to what is done in general and unless specified otherwise,
the xaxis direction of notations is assumed to be independent of the CSS
direction
.
In order to determine the metrics of the menclose
notation, we
compute each notation individually and take the union of the metrics:
The left
notation is drawn by putting a vertical bar of thickness
ξ_{8} on the left of the content of the menclose
element.
The length of the bar is obtained by extending the height of the content
with OverbarVerticalGap
plus
OverbarRuleThickness
above
and UnderbarVerticalGap
plus
UnderbarRuleThickness
below.
The gap between the bar and the content is 3ξ_{8}.
The logical box is obtained by adding some space of width
ξ_{8} on the left of the bar. See figure 14.
The right
notation is drawn the same as the left
notation,
but with the vertical bar placed on the right.
The top
notation is drawn by putting an overbar of thickness
OverbarRuleThickness
over the content of the menclose
element.
The length of the bar is obtained by extending the width of the content
with 4ξ_{8} on each side.
The gap between the overbar and the content is
OverbarVerticalGap
.
The logical box is obtained by adding some space of height
OverbarExtraAscender
above the bar.
See figure 15.
The bottom
notation is drawn the same as the top
notation,
but with the vertical bar placed below the content and using parameters
UnderbarRuleThickness
,
UnderbarVerticalGap
.
and UnderExtraDescender
.
The box
notation is treated as equivalent to
left right top bottom.
To draw the roundedbox
notation, we consider the box
obtained by expanding the ink box by 7ξ_{8} / 2 on each side.
Using SVG terminology, we draw a rounded rectangle on this expanded box
with parameters rx
, ry
and strokewidth set to 3ξ_{8}
[SVG11]. To obtain the logical box we again add a space of ξ_{8} on
each side of the ink box. See figure 16.
The actuarial
notation is treated as equivalent to right top.
The madruwb
notation is treated as equivalent to
right bottom.
The horizontalstrike
notation is drawn with an horizontal bar
of thickness ξ_{8} and
vertically centered inside the menclose
content.
This does not change the box metrics.
See figure 17.
The verticalstrike
notation is drawn the same as
horizontalstrike
but with a vertical bar
of thickness ξ_{8} and horizontally centered inside the menclose
content.
The updiagonalstrike
notation is drawn with a line
of thickness ξ_{8} going from the bottom left corner of the menclose
content to its top right corner. Using SVG terminology, the
strokelinecap of the line is butt
[SVG11].
As an approximation, the ink box
is set equal to the logical box and obtained by increasing the original box
from each side by ξ_{8} / 2.
See figure 18.
The downdiagonalstrike
notation is drawn as an
updiagonalstrike
but the line strike goes from the top left corner to the bottom right corner.
Using SVG terminology, the
strokelinecap of the line is butt
[SVG11].
The longdiv
notation is drawn similarly to the msqrt
element
(figure 11). It is independent of CSS
direction
and U+221A SQUARE ROOT is replaced with
U+0029 RIGHT PARENTHESIS. The rule thickness is ξ_{8},
the gap between content and overbar is 3ξ_{8} and the extra ascender
is ξ_{8}.
To draw the circle
notation, we first consider the ink box of
width w and height h. We draw the ellipse
of axes the axes of symmetry of this ink box, of radii
w * √2 / 2
and
h * √2 / 2
and of thickness ξ_{8}.
We ensure that the logical box also has space ξ_{8} around each side
of the ellipse ink box.
This document does define any layout algorithm for other menclose
notations. User agents may ignore them.
Authors are encouraged to use the msqrt
element to represent square roots
instead of relying on the radical
notation of the menclose
element.
The msub element attaches a subscript to a base using the syntax
<msub> base subscript </msub>
The msup
element attaches a superscript to a base using the syntax
<msup> base superscript </msup>
The msubsup
element is used to attach both a subscript and superscript to
a base expression.
<msubsup> base subscript superscript </msubsup>
As suggested in section section 2.3.2, the displaystyle
and
scriptlevel
changes be achieved with the
following style in the user agent stylesheet:
msub > :not(:firstchild), msup > :not(:firstchild), msubsup > :not(:firstchild) { mathmlscriptlevel: increment 1; mathmlmathstyle: inline; }
The msub
element is laid out as shown on figure 20.
The baseline is the baseline of the base while the baseline of the script is
shifted down by SubShift
, which is the minimal value honoring the
following conditions:
SubShift
is at least SubscriptShiftDown
.
The top of the subscript SubTop
with respect to the baseline
is not above SubscriptTopMax
.
The drop SubscriptBaselineDrop
from the bottom of the base to
the baseline of the script is at least
SubscriptBaselineDropMin
.
When determining
the logical box, a space of width SpaceAfterScript
is added after
the subscript. By default, the leading edge of the subscript is aligned with
the trailing edge of the base. However, if the base is an operator with
largeop="true" (or an embellished operator whose mo
element core
has largeop="true") the subscript is horizontally shifted backward
by the italic correction of the base.
The msup
element is laid out as shown on figure 21.
The baseline is the baseline of the base while the baseline of the script is
shifted up by SuperShift
, which is the minimal value honoring the
following conditions:
SuperShift
is at least
SuperscriptShiftUpCramped
if the msup
element is
cramped (section auto) or at least
SuperscriptShiftUp
otherwise.
The bottom of the superscript SuperBottom
with respect to the
baseline is not below SuperscriptBottomMin
.
The drop SuperscriptBaselineDrop
from the top of the base to
the baseline of the script is at most SuperscriptBaselineDropMax
.
When determining
the logical box, a space of width SpaceAfterScript
is added after
the superscript. By default, the leading edge of the superscript is aligned with
the trailing edge of the base and shifted forward by the italic correction
of the base, except if the base is an operator with
largeop="true" (or an embellished operator whose mo
element core
has largeop="true").
The msubsup
element is laid out as shown on figure
22.
The baseline is the baseline of the base while the baseline of the script is
shifted down by SubShift
and the superscript is shifted up by
SuperShift
which is initially set to the minimal values honoring the
following conditions:
SubShift
is at least
SuperscriptShiftUpCramped
if the msup
element is
cramped (section auto) or at least
SuperscriptShiftUp
otherwise.
The top of the subscript SubTop
with respect to the baseline
is not above SubscriptTopMax
.
The drop SuperscriptBaselineDrop
from the top of the base to
the baseline of the superscript is at most SuperscriptBaselineDropMax
.
SubShift
is at least
SuperscriptShiftUpCramped
if the msup
element is
cramped (section auto) or at least
SuperscriptShiftUp
otherwise.
The bottom of the superscript SuperBottom
with respect to the
baseline is not below SuperscriptBottomMin
.
The drop SubscriptBaselineDrop
from
the bottom of the base to the the baseline of the subscript is at least
SubscriptBaselineDropMin
.
We then increase the gap SubSuperGap
between the bottom of the superscript
and the top of the subscript to ensure it is at least
SubSuperscriptGapMin
:
This is first done by continuing to shift the superscript up as long as the
SuperBottom
does not exceed
SuperscriptBottomMaxWithSubscript
and next by continuing to shift the subscript down.
When determining
the logical box, a space of width SpaceAfterScript
is added after
each script. By default the leading edges of the scripts are aligned with
the trailing edge and either the superscript is shifted forward by the italic
correction of the base. However, if the base is an operator with
largeop="true" (or an embellished operator whose mo
element core
has largeop="true") then instead the subscript is shifted forward by the
italic correction of the base.
The munder
element attaches an accent or limit placed under a base using
the syntax
<munder> base underscript </munder>
If base is an operator with movablelimits="true" (or an embellished
operator whose mo
element core has movablelimits="true"), and
displaystyle="false", then underscript is drawn in a subscript position.
In this case, the accentunder
attribute is ignored. […]
The mover
element attaches an accent or limit placed over a base using
the syntax
<mover> base overscript </mover>
If base is an operator with movablelimits="true" (or an embellished
operator whose mo
element core has movablelimits="true"), and
displaystyle="false", then overscript is drawn in a superscript position.
In this case, the accent
attribute is ignored.
The munderover
element attaches accents or limits placed both over and
under a base using the syntax
<munderover> base underscript overscript </munderover>
If base is an operator with movablelimits="true" (or an embellished
operator whose mo
element core has movablelimits="true"), and
displaystyle="false", then underscript and overscript are drawn in a
subscript and superscript position, respectively. In this case, the
accentunder
and accent
attributes are ignored.
User Agents must perform the scriptlevel
increment by checking
the appropriate accent
or accentunder
value, which can not be done
using only CSS. However, displaystyle
changes can be achieved with the
following style in the user agent stylesheet, as suggested in section
2.3.2:
munder > :not(:firstchild), mover > :not(:firstchild), munderover > :not(:firstchild) { mathmlmathstyle: inline; }
In cases where underscript and overscript are drawn as subscript and
superscript position then the layout algorithm is the same as section
4.4.1. Note that in that case,
accent
or accentunder
are ignored so the scriptlevel increment is
always performed.
The general layout of munderover
is shown on figure
23.
The overscript is placed above the base, the underscript below the base
and by default are aligned with respect to their geometrical center.
If the overscript is an accent and has a TopAccentAttachment
value, then this value may be used to horizontally align the accent instead
of its geometrical center.
OverShift
is the distance between the top ink
of the base and the baseline of the overscript, OverGap
is the distance
between the top ink of the base and the bottom ink of the overscript,
OverExtraAscender
is extra space to add above the overscript when
determining the logical box. UnderShift
, UnderGap
and
UnderExtraDescender
are defined similarly for the underscripts.
We distinguish three cases:
If the base is an operator with largeop="true"
(or an embellished operator whose mo
element core has
largeop="true") then ensure that OverGap
is at least
UpperLimitGapMin
, that OverShift
is at least
UpperLimitBaselineRiseMin
that UnderGap
is at
least
LowerLimitGapMin
, that UnderShift
is at least
LowerLimitBaselineDropMin
.
OverExtraAscender
and
UnderExtraDescender
are zero. The
underscript is shifted backward by half the italic correction of the base.
The overscript is shifted forward by half the italic correction of the base.
If the base is a horizontal operator with stretchy="true"
(or a horizontal embellished operator whose mo
element core has
stretchy="true"). Then ensure that OverGap
is at least
StretchStackGapBelowMin
, that OverShift
is at
least
StretchStackTopShiftUp
that UnderGap
is at least
StretchStackGapAboveMin
,
that UnderShift
is at least
StretchStackBottomShiftDown
.
OverExtraAscender
and
UnderExtraDescender
are zero.
In other cases we proceed as follows.
There are not any specific conditions to satisfy on OverShift
or
UnderShift
.
OverExtraAscender
and
OverExtraAscender
are respectively set to
OverbarExtraAscender
and UnderExtraDescender
.
We set UnderGap
to UnderbarVerticalGap
if the underscript is not an accent and to zero otherwise.
We set OverGap
to OverbarVerticalGap
if the overscript is not an accent and generally to zero otherwise.
However, if overscript is an accent and if the base ascent is at most
AccentBaseHeight
then we actually set OverGap
to
their nonnegative difference.
Remark: For accent overscripts and bases with ascents that are at most
AccentBaseHeight
, the rule from
[OpenFontFormat3] [TeXBook] is actually to align the baselines of the
overscripts and of the bases. This assumes that accent glyphs are designed in
such a way that their ink bottoms are more or less
AccentBaseHeight
above their baselines. Hence, the
previous rule will guarantee that all the overscript bottoms are aligned while
still avoiding collision with the bases. However, MathML can have arbitrary
accent overscripts so we provide a more general and simpler rule above: Ensure
that the bottom of overscript is at least
AccentBaseHeight
above the baseline of the base.
The layout of munder
and mover
is the same as the one of
munderover
except that one script and its corresponding extra space
are ignored.
Presubscripts and tensor notations are represented by a single element,
mmultiscripts
, using the syntax:
<mmultiscripts>
base
(subscript superscript)*
[ <mprescripts/> (presubscript presuperscript)* ]
</mmultiscripts>
This element allows the representation of any number of verticallyaligned
pairs of subscripts and superscripts, attached to one base expression. It
supports both postscripts and prescripts. Missing scripts can be represented
by the empty element none
.
The displaystyle
and scriptlevel
changes be achieved with the
following style in the user agent stylesheet as suggested in section
2.3.2:
mmultiscripts > :not(:firstchild) { mathmlscriptlevel: increment 1; mathmlmathstyle: inline; }
Any layout for mmultiscripts
is acceptable as long as it follows
the condition of the MathML 3 specification [MathML3] and is consistent
with section 4.4.1 for mmultiscripts
contructions that are equivalent to msubsup
. Here is a possible algorithm
that is represented on figure 24.
Determine the vertical shifts for each subscript/superscript pair
using the algorithm for msub
(if the superscript is none
),
msup
(if the subscript is none
) or msubsup
(if none of the scripts are none
) or otherwise use shifts of zero
(if both scripts of the pair are none
). When placing the scripts,
use the maximum of the subscript shift for all subscript and
the maximum of the superscript shift for all superscripts.
For the horizontal layout of postscripts, use the trailing edge of the
base or of the previous pair as the leading edge of the current pair.
For each pair, apply the same italic correction described for
msubsup
in section 4.4.1.
Apply the same italic corrections for all these postscripts.
For the horizontal layout of prescripts, use the leading edge of the base or of next pair as the trailing edge of the current pair. Do not apply any italic correction for prescripts.
Matrices, arrays and other tablelike mathematical notation are marked up using
mtable
, mtr
, mlabeledtr
and mtd
elements. These
elements are similar to the table, tr and td elements of HTML, except that they
provide specialized attributes for the fine layout control necessary for
commutative diagrams, block matrices and so on.
In the present document, we restrict ourselves to a minimal implementation
compatible with HTML tables. First the mtable
element must be treated as
a HTML table and by [MathML3], mtable
must accept a
displaystyle
attribute with default value false
. To implement that,
one may rely on the following rules for the user agent stylesheet as
suggested in section 2.3.2:
mtable { display: inlinetable; mathmlmathstyle: inline; } mtable[displaystyle="true"] { mathmlmathstyle: display; }
In addition, user agents may use the following rules to emulate the frame
attribute:
mtable[frame="none"] { border: none; } mtable[frame="solid"] { border: solid thin; } mtable[frame="dashed"] { border: dashed thin; }
By default, user agents must align the vertical center of the table on the
math axis, which is provided by the AxisHeight
value.
User agents may also support nondefault align
attribute values.
The mtr
and mlabeledtr
elements must be treated as HTML table rows
and the label of mlabeledtr
element must be hidden by default.
The default value of rowalign
must be baseline
.
One may rely on the following rules for the user agent stylesheet
as suggested in section 2.3.2:
mtr, mlabeledtr { display: tablerow; verticalalign: baseline; } mlabeledtr > mtd:firstchild { display: none; }
Finally, the mtd
elements must be treated as a HTML table cell.
The default value of rowalign
must be baseline
and
the default value of colulmnalign
must be center
.
User agents may also try to approximate the default rowspacing
and
columnspacing
between cells. This can be achieved with the following CSS:
mtd { display: tablecell; verticalalign: inherit; textalign: center; padding: 0.5ex 0.4em; }
The mtd
element must also support the columnspan
(sic) and
rowspan
attributes. This can be implemented the same way as
the HTML colspan
and rowspan
attributes.
To provide a mechanism for binding actions to expressions, MathML provides the maction element. This element accepts any number of subexpressions as arguments and the type of action that should happen is controlled by the actiontype attribute. Only three actions are predefined by MathML, but the list of possible actions is open.
User agents must display at most one of the child of a maction
element.
User agents must determine the visible child as follows:
If actiontype
is toggle
and the selection
attribute
(with default value 1) points to a valid child index
between 1 and the number of children, then use the specified child.
If the actiontype
is statusline
or tooltip
then
use the first child (if any).
Otherwise, the visible child is undetermined.
For the layout algorithm described in this document, the
maction
element must be treated the same as the mrow
element
containing its visible child. If it is undetermined,
the user agent may treat the maction
element as an
empty mrow
element or as an merror
element with some relevant error
message indicating invalid or unsupported markup.
User agents may additionally provide a complete implementation of the
toggle
actiontype updating the value of the selection
attribute
after the maction
element receives a click
event.
For statusline
and tooltip
attributes, they may also display the
second child in some way when the maction
element receives a hover
event. This document does not define how these DOM events are propagated
or how to change the default behavior.
Given the similarity with the semantics
element
described in section 4.7, it is
suggested to share the implementation of semantics
and maction
.
The semantics
element is the container element that associates
annotations with a MathML expression. The semantics element has as its first
child the expression to be annotated. Any MathML expression may appear as the
first child of the semantics element. Subsequent annotation and annotationxml
children enclose the annotations. An annotation represented in XML is enclosed
in an annotationxml element. An annotation represented in character data
is enclosed in an annotation
element.
User agents must display at most one of the child of a semantics
element.
For example, they may always display the first child (if any) or may use this
more advanced algorithm to determine a visible child:
If the semantics
element has a first child that is any of the
MathML elements (other than annotation
and annotationxml)
whose rendering is described in this document then use it as the visible
child and stop.
Otherwise, check the children of the semantics
element in the DOM
order to try and find the first child that is
Either an annotation
without any src
attribute.
Or an annotationxml without any src
attribute and
with an encoding
attribute that has value
"application/mathmlpresentation+xml",
"MathMLPresentation",
"image/svg+xml",
"SVG1.1",
"application/xhtml+xml" or
"text/html".
Otherwise, fallback to the first child (if any).
Otherwise, the semantics
element is empty and the visible child is
undetermined.
For the layout algorithm described in this document, the
annotationxml element must be treated the same as the mrow
element,
the annotation
element must be treated the same as the mtext
element. The semantics
element must be treated the same as an
mrow
element containing only its visible child. If it is undetermined,
the user agent may treat the semantics
element as an
empty mrow
element or as an merror
element with some error message
indicating invalid markup.
Given the similarity with the maction
element
described in section 4.6, it is
suggested to share the implementation of semantics
and maction
.
This section is nonnormative.
It is not clear how the DisplayOperatorMinHeight
is
supposed to be used or whether it is really reliable. More specifically,
integral symbols (e.g. INTEGRAL U+222B) are typically taller than Nary
operators (e.g. NARY SUMMATION U+2211) so a unique minimal height may not
always be enough to determine the display size. Suppose for example that the
sum has three size variants: the base size of height 1em, the display size
of height 2em and a bigger variant of height 3em.
Suppose that the integral has three sizes: a base size of
height 1em, a larger size variant of height 2em and a display size of height
3em. If DisplayOperatorMinHeight
is less than
3em then it does not force the display size of the integral to be selected.
If it is more than 3em then none of the available sizes satisfies the
condition. How to interpret that? Should we pick the largest as a fallback?
If it is 3em, the desired size will be selected for the integral in display
size but the one selected for the sum in display size will be too large.
A heuristic is proposed in section 4.2.3 to workaround limitations
of DisplayOperatorMinHeight
.
The OpenType MATH specification does not seem to take into account linebreaking. As explained in section 4.1.2 it is important in a HTML5 context to be able to determine the mincontent width and the maxcontent width. However when an operator is stretched vertically to cover a target size, it is not possible to know the selected size variant or glyph assembly without knowing the target size and so the mincontent and maxcontent widths can only be approximated. In practice, the width of the vertical operators is almost independent on its stretch size. Should that be a requirement of the OpenType MATH specification?
In section 4.3.8 we describe the MathML menclose
element. This
one contains many notations that are not mentioned in the OpenType MATH
specification. Some rendering suggestions are given based on the value of
OverbarRuleThickness
but perhaps new values should be
introduced in the MathConstants
subtable to cover these
notations.
This section is nonnormative.
User agents that do not support MathML may decide to
render the fallback content provided by the altimg* attributes in some
situations e.g. when they are specified or
under a preference option. In that case, an approximate implementation is to
render the math
element as a HTML img
element with the
value of altimg
as an src
attribute, the value of
alttext
as an alt
attribute, the value of altimgwidth as
the CSS width
property, the value of altimgheight as
the CSS height
property and the value of altimgvalign as
the CSS verticalalign property [HTML5] [CSS2]. Here is a
partial implementation using the attr() function of [CSS3Values]:
math { display: inline; } math[display="block"] { display: block; textalign: center; } math { backgroundimage: attr(altimg url); width: attr(altimgwidth length); height: attr(altimgheight length); verticalalign: attr(altimgvalign length); } math > * { display: none; }
This section displays a nonnormative Relax NG Schema which details the elements and attributes defined by this specification. Note that MathML does not need to be expressed in XML syntax, in particular the syntax defined by HTML may be used. However this schema may be taken as an informal specification of the structure, whatever syntax is used.
example# mathml4core default namespace m = "http://www.w3.org/1998/Math/MathML" start = math math = element math {math.attributes,MathExpression*} CommonAtt = attribute id {xsd:ID}?, attribute xref {text}?, attribute class {xsd:NMTOKENS}?, attribute style {xsd:string}?, attribute href {xsd:anyURI}? math.attributes = CommonAtt, attribute display {"block"  "inline"}?, # attribute maxwidth {length}?, # attribute overflow {"linebreak"  "scroll"  "elide"  "truncate"  "scale"}?, attribute altimg {xsd:anyURI}?, attribute altimgwidth {length}?, attribute altimgheight {length}?, attribute altimgvalign {length  "top"  "middle"  "bottom"}?, attribute alttext {text}? annotation = element annotation {CommonAtt,(srctext)} anyElement = element (*  m:*) {(attribute * {text}text anyElement)*} annotationxml = element annotationxml {CommonAtt, encoding?, (srcMathExpression*anyElement*)} encoding=attribute encoding {xsd:string} src=attribute src {xsd:string} semantics = element semantics {CommonAtt, MathExpression, (annotationannotationxml)*} length = xsd:string { pattern = '\s*((?[09]*([09]\.?\.[09])[09]*(e[mx]incmmmp[xtc]%))0(negative)?((very){0,2}thi(nck)medium)mathspace)\s*' } ## mathml3presentation, simplified MathExpression = TokenExpression mrowmfracmsqrtmrootmstylemerrormpaddedmphantom menclosemsubmsupmsubsupmundermovermunderover mmultiscriptsmtablemaction ImpliedMrow = MathExpression* TableRowExpression = mtrmlabeledtr MultiScriptExpression = (MathExpressionnone),(MathExpressionnone) mpaddedlength = xsd:string { pattern = '\s*([\+\]?[09]*([09]\.?\.[09])[09]*\s*((%?\s*(heightdepthwidth)?)e[mx]incmmmp[xtc]((negative)?((very){0,2}thi(nck)medium)mathspace))?)\s*' } linestyle = "none"  "solid"  "dashed" verticalalign = "top"  "bottom"  "center"  "baseline"  "axis" columnalignstyle = "left"  "center"  "right" notationstyle = "longdiv"  "actuarial"  "box"  "roundedbox"  "circle"  "left"  "right"  "top"  "bottom"  "updiagonalstrike"  "downdiagonalstrike"  "verticalstrike"  "horizontalstrike"  "madruwb" idref = text color = xsd:string { pattern = '\s*((#[09afAF]{3}([09afAF]{3})?)[aA][qQ][uU][aA][bB][lL][aA][cC][kK][bB][lL][uU][eE][fF][uU][cC][hH][sS][iI][aA][gG][rR][aA][yY][gG][rR][eE][eE][nN][lL][iI][mM][eE][mM][aA][rR][oO][oO][nN][nN][aA][vV][yY][oO][lL][iI][vV][eE][pP][uU][rR][pP][lL][eE][rR][eE][dD][sS][iI][lL][vV][eE][rR][tT][eE][aA][lL][wW][hH][iI][tT][eE][yY][eE][lL][lL][oO][wW])\s*'} TokenExpression = mimnmomtextmspacems mi = element mi {mi.attributes, text} mi.attributes = CommonAtt, CommonPresAtt, TokenAtt mn = element mn {mn.attributes, text} mn.attributes = CommonAtt, CommonPresAtt, TokenAtt mo = element mo {mo.attributes, text} mo.attributes = CommonAtt, CommonPresAtt, TokenAtt, attribute form {"prefix"  "infix"  "postfix"}?, attribute fence {"true"  "false"}?, attribute separator {"true"  "false"}?, attribute lspace {length}?, attribute rspace {length}?, attribute stretchy {"true"  "false"}?, attribute symmetric {"true"  "false"}?, # attribute maxsize {length  "infinity"}?, # attribute minsize {length}?, attribute largeop {"true"  "false"}?, attribute movablelimits {"true"  "false"}?, attribute accent {"true"  "false"}? # attribute linebreak {"auto"  "newline"  "nobreak"  "goodbreak"  "badbreak"}? mtext = element mtext {mtext.attributes, text} mtext.attributes = CommonAtt, CommonPresAtt, TokenAtt mspace = element mspace {mspace.attributes, empty} mspace.attributes = CommonAtt, CommonPresAtt, TokenAtt, attribute width {length}?, attribute height {length}?, attribute depth {length}? ms = element ms {ms.attributes, text} ms.attributes = CommonAtt, CommonPresAtt, TokenAtt, attribute lquote {text}?, attribute rquote {text}? none = element none {none.attributes,empty} none.attributes = CommonAtt, CommonPresAtt mprescripts = element mprescripts {mprescripts.attributes,empty} mprescripts.attributes = CommonAtt, CommonPresAtt CommonPresAtt = attribute mathcolor {color}?, attribute mathbackground {color  "transparent"}? TokenAtt = attribute mathvariant {"normal"  "bold"  "italic"  "bolditalic"  "doublestruck"  "boldfraktur"  "script"  "boldscript"  "fraktur"  "sansserif"  "boldsansserif"  "sansserifitalic"  "sansserifbolditalic"  "monospace"  "initial"  "tailed"  "looped"  "stretched"}?, attribute mathsize {length}?, attribute dir {"ltr"  "rtl"}? mrow = element mrow {mrow.attributes, MathExpression*} mrow.attributes = CommonAtt, CommonPresAtt, attribute dir {"ltr"  "rtl"}? mfrac = element mfrac {mfrac.attributes, MathExpression, MathExpression} mfrac.attributes = CommonAtt, CommonPresAtt, attribute linethickness {length}?, attribute numalign {"left"  "center"  "right"}?, attribute denomalign {"left"  "center"  "right"}?, attribute bevelled {"true"  "false"}? msqrt = element msqrt {msqrt.attributes, ImpliedMrow} msqrt.attributes = CommonAtt, CommonPresAtt mroot = element mroot {mroot.attributes, MathExpression, MathExpression} mroot.attributes = CommonAtt, CommonPresAtt mstyle = element mstyle {mstyle.attributes, ImpliedMrow} mstyle.attributes = CommonAtt, CommonPresAtt, attribute scriptlevel {xsd:integer}?, attribute displaystyle {"true"  "false"}?, attribute scriptsizemultiplier {xsd:decimal}? math.attributes &= CommonPresAtt math.attributes &= mstyle.attributes merror = element merror {merror.attributes, ImpliedMrow} merror.attributes = CommonAtt, CommonPresAtt mpadded = element mpadded {mpadded.attributes, ImpliedMrow} mpadded.attributes = CommonAtt, CommonPresAtt, attribute height {mpaddedlength}?, attribute depth {mpaddedlength}?, attribute width {mpaddedlength}?, attribute lspace {mpaddedlength}?, attribute voffset {mpaddedlength}? mphantom = element mphantom {mphantom.attributes, ImpliedMrow} mphantom.attributes = CommonAtt, CommonPresAtt menclose = element menclose {menclose.attributes, ImpliedMrow} menclose.attributes = CommonAtt, CommonPresAtt, attribute notation {notationstyle}? msub = element msub {msub.attributes, MathExpression, MathExpression} msub.attributes = CommonAtt, CommonPresAtt, attribute subscriptshift {length}? msup = element msup {msup.attributes, MathExpression, MathExpression} msup.attributes = CommonAtt, CommonPresAtt, attribute superscriptshift {length}? msubsup = element msubsup {msubsup.attributes, MathExpression, MathExpression, MathExpression} msubsup.attributes = CommonAtt, CommonPresAtt, attribute subscriptshift {length}?, attribute superscriptshift {length}? munder = element munder {munder.attributes, MathExpression, MathExpression} munder.attributes = CommonAtt, CommonPresAtt, attribute accentunder {"true"  "false"}?, attribute align {"left"  "right"  "center"}? mover = element mover {mover.attributes, MathExpression, MathExpression} mover.attributes = CommonAtt, CommonPresAtt, attribute accent {"true"  "false"}?, attribute align {"left"  "right"  "center"}? munderover = element munderover {munderover.attributes, MathExpression, MathExpression, MathExpression} munderover.attributes = CommonAtt, CommonPresAtt, attribute accent {"true"  "false"}?, attribute accentunder {"true"  "false"}?, attribute align {"left"  "right"  "center"}? mmultiscripts = element mmultiscripts {mmultiscripts.attributes, MathExpression, MultiScriptExpression*, (mprescripts,MultiScriptExpression*)?} mmultiscripts.attributes = msubsup.attributes mtable = element mtable {mtable.attributes, TableRowExpression*} mtable.attributes = CommonAtt, CommonPresAtt, attribute frame {linestyle}?, attribute displaystyle {"true"  "false"}? mlabeledtr = element mlabeledtr {mlabeledtr.attributes, mtd+} mlabeledtr.attributes = mtr.attributes mtr = element mtr {mtr.attributes, mtd*} mtr.attributes = CommonAtt, CommonPresAtt, attribute rowalign {"top"  "bottom"  "center"  "baseline"  "axis"}? mtd = element mtd {mtd.attributes, ImpliedMrow} mtd.attributes = CommonAtt, CommonPresAtt, attribute rowspan {xsd:positiveInteger}?, attribute columnspan {xsd:positiveInteger}?, attribute rowalign {"top"  "bottom"  "center"  "baseline"  "axis"}?, attribute columnalign {columnalignstyle}? maction = element maction {maction.attributes, MathExpression+} maction.attributes = CommonAtt, CommonPresAtt, attribute actiontype {text}, attribute selection {xsd:positiveInteger}?
The following table gives the suggested dictionary of rendering
properties for operators, fences, separators, and accents in MathML, all of
which are represented by mo
elements. For brevity,
all such elements will be called simply operators
in this
Appendix.
Note that the dictionary is indexed not just by the element
content, but by the element content and form
attribute
value, together. Operators with more than one possible form have more
than one entry. The MathML specification describes how the renderer
chooses (infers
) which form to use when no form
attribute is given; see
Having made that choice, or with the form
attribute
explicitly specified in the <mo>
element's start
tag, the MathML renderer uses the remaining attributes from the
dictionary entry for the appropriate single form of that operator,
ignoring the entries for the other possible forms.
In the table below, all nonASCII characters are represented by XMLstyle hexadecimal numeric character references. The choice of markup (character data, numeric character reference or named entity reference) for a given character in MathML has no effect on its rendering.
Each row of the table is indexed as described above by the both the character
(given by code point and Unicode Name) and the value of the form attribute.
The fourth column gives the
mrow
.
The rule described
there is especially relevant to the automatic generation of MathML by
conversion from other formats for displayed mathematics, such as T_{E}X,
which do not always specify how subexpressions nest.
The length valued attributes such as lspace
are given explicitly in the following columns.
Boolean valued attributes such as stretchy
are specified together in the final
linebreakstyle
=after.
Any attribute not listed for some entry has its default value, which is given in parentheses in the table of attributes in ??.
(  (  left parenthesis  prefix  1  0  0  fence


could be expressed as an mo
element by:
<mo form="prefix" fence="true" stretchy="true" lspace="0em" rspace="0em"> ( </mo>(note the whitespace added around the content for readability; Such whitespace will be ignored by a MathML system, as described in
This entry means that, for MathML renderers which use this
suggested operator dictionary, giving the element
<mo form="prefix"> ( </mo>
alone, or simply
<mo> ( </mo>
in a position for which
form="prefix"
would be inferred (see below), is equivalent to giving the element
with all attributes as shown above.
In some versions of this specification, the rows of the table may be reordered by clicking on a h2ing in the top row, to cause the table to be ordered by that column.
lspace
and
rspace
attributes
The values for lspace
and rspace
given here range from 0 to 7,
they are given numerically in order to save space in the table,
the values should be taken as referring to the named mathematical spaces, as follows.
Table Entry  Named Space  Default Length 
0  0 em  
1  veryverythinmathspace  1/18 em 
2  verythinmathspace  2/18 em 
3  thinmathspace  3/18 em 
4  mediummathspace  4/18 em 
5  thickmathspace  5/18 em 
6  verythickmathspace  6/18 em 
7  veryverythickmathspace  7/18 em 
For the invisible operators whose content is ⁢
or ⁡
,
it is suggested that MathML renderers choose spacing in a contextsensitive
way (which is an exception to the static values given in the following
table). For <mo>⁡</mo>
, the total
spacing (
sin x
(where the right operand
doesn't start with a fence) should be greater than zero; for
<mo>⁢</mo>
, the total spacing
should be greater than zero when both operands (or the nearest tokens on
either side, if on the baseline) are identifiers displayed in a nonslanted
font (i.e.. under the suggested rules, when both operands are
multicharacter identifiers).
Character  Glyph  Name  form  priority  lspace  rspace  Properties 

𞻰  𞻰  arabic mathematical operator meem with hah with tatweel  prefix  stretchy  
𞻱  𞻱  arabic mathematical operator hah with dal  prefix  stretchy  
‘  ‘  left single quotation mark  prefix  10  0  0  fence 
’  ’  right single quotation mark  postfix  10  0  0  fence 
“  “  left double quotation mark  prefix  10  0  0  fence 
”  ”  right double quotation mark  postfix  10  0  0  fence 
(  (  left parenthesis  prefix  20  0  0  fence, stretchy, symmetric 
)  )  right parenthesis  postfix  20  0  0  fence, stretchy, symmetric 
[  [  left square bracket  prefix  20  0  0  fence, stretchy, symmetric 
]  ]  right square bracket  postfix  20  0  0  fence, stretchy, symmetric 
{  {  left curly bracket  prefix  20  0  0  fence, stretchy, symmetric 
    vertical line  prefix  20  0  0  fence, stretchy, symmetric 
    vertical line  postfix  20  0  0  fence, stretchy, symmetric 
    multiple character operator:   prefix  20  0  0  fence, stretchy, symmetric 
    multiple character operator:   postfix  20  0  0  fence, stretchy, symmetric 
    multiple character operator:   prefix  20  0  0  fence, stretchy, symmetric 
    multiple character operator:   postfix  20  0  0  fence, stretchy, symmetric 
}  }  right curly bracket  postfix  20  0  0  fence, stretchy, symmetric 
‖  ‖  double vertical line  prefix  20  0  0  fence, stretchy 
‖  ‖  double vertical line  postfix  20  0  0  fence, stretchy 
⌈  ⌈  left ceiling  prefix  20  0  0  fence, stretchy, symmetric 
⌉  ⌉  right ceiling  postfix  20  0  0  fence, stretchy, symmetric 
⌊  ⌊  left floor  prefix  20  0  0  fence, stretchy, symmetric 
⌋  ⌋  right floor  postfix  20  0  0  fence, stretchy, symmetric 
〈  〈  leftpointing angle bracket  prefix  20  0  0  fence, stretchy, symmetric 
〉  〉  rightpointing angle bracket  postfix  20  0  0  fence, stretchy, symmetric 
❲  ❲  light left tortoise shell bracket ornament  prefix  20  0  0  fence, stretchy, symmetric 
❳  ❳  light right tortoise shell bracket ornament  postfix  20  0  0  fence, stretchy, symmetric 
⟦  ⟦  mathematical left white square bracket  prefix  20  0  0  fence, stretchy, symmetric 
⟧  ⟧  mathematical right white square bracket  postfix  20  0  0  fence, stretchy, symmetric 
⟨  ⟨  mathematical left angle bracket  prefix  20  0  0  fence, stretchy, symmetric 
⟩  ⟩  mathematical right angle bracket  postfix  20  0  0  fence, stretchy, symmetric 
⟪  ⟪  mathematical left double angle bracket  prefix  20  0  0  fence, stretchy, symmetric 
⟫  ⟫  mathematical right double angle bracket  postfix  20  0  0  fence, stretchy, symmetric 
⟬  ⟬  mathematical left white tortoise shell bracket  prefix  20  0  0  fence, stretchy, symmetric 
⟭  ⟭  mathematical right white tortoise shell bracket  postfix  20  0  0  fence, stretchy, symmetric 
⟮  ⟮  mathematical left flattened parenthesis  prefix  20  0  0  fence, stretchy, symmetric 
⟯  ⟯  mathematical right flattened parenthesis  postfix  20  0  0  fence, stretchy, symmetric 
⦀  ⦀  triple vertical bar delimiter  prefix  20  0  0  fence, stretchy 
⦀  ⦀  triple vertical bar delimiter  postfix  20  0  0  fence, stretchy 
⦃  ⦃  left white curly bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦄  ⦄  right white curly bracket  postfix  20  0  0  fence, stretchy, symmetric 
⦅  ⦅  left white parenthesis  prefix  20  0  0  fence, stretchy, symmetric 
⦆  ⦆  right white parenthesis  postfix  20  0  0  fence, stretchy, symmetric 
⦇  ⦇  z notation left image bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦈  ⦈  z notation right image bracket  postfix  20  0  0  fence, stretchy, symmetric 
⦉  ⦉  z notation left binding bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦊  ⦊  z notation right binding bracket  postfix  20  0  0  fence, stretchy, symmetric 
⦋  ⦋  left square bracket with underbar  prefix  20  0  0  fence, stretchy, symmetric 
⦌  ⦌  right square bracket with underbar  postfix  20  0  0  fence, stretchy, symmetric 
⦍  ⦍  left square bracket with tick in top corner  prefix  20  0  0  fence, stretchy, symmetric 
⦎  ⦎  right square bracket with tick in bottom corner  postfix  20  0  0  fence, stretchy, symmetric 
⦏  ⦏  left square bracket with tick in bottom corner  prefix  20  0  0  fence, stretchy, symmetric 
⦐  ⦐  right square bracket with tick in top corner  postfix  20  0  0  fence, stretchy, symmetric 
⦑  ⦑  left angle bracket with dot  prefix  20  0  0  fence, stretchy, symmetric 
⦒  ⦒  right angle bracket with dot  postfix  20  0  0  fence, stretchy, symmetric 
⦓  ⦓  left arc lessthan bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦔  ⦔  right arc greaterthan bracket  postfix  20  0  0  fence, stretchy, symmetric 
⦕  ⦕  double left arc greaterthan bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦖  ⦖  double right arc lessthan bracket  postfix  20  0  0  fence, stretchy, symmetric 
⦗  ⦗  left black tortoise shell bracket  prefix  20  0  0  fence, stretchy, symmetric 
⦘  ⦘  right black tortoise shell bracket  postfix  20  0  0  fence, stretchy, symmetric 
⧼  ⧼  leftpointing curved angle bracket  prefix  20  0  0  fence, stretchy, symmetric 
⧽  ⧽  rightpointing curved angle bracket  postfix  20  0  0  fence, stretchy, symmetric 
;  ;  semicolon  infix  30  0  3  separator, linebreakstyle=after 
,  ,  comma  infix  40  0  3  separator, linebreakstyle=after 
⁣   invisible separator  infix  40  0  0  separator, linebreakstyle=after 
∴  ∴  therefore  infix  70  5  5  
∵  ∵  because  infix  70  5  5  
>  >  multiple character operator: >  infix  90  5  5  
..  ..  multiple character operator: ..  postfix  100  0  0  
...  ...  multiple character operator: ...  postfix  100  0  0  
:  :  colon  infix  100  1  2  
϶  ϶  greek reversed lunate epsilon symbol  infix  110  5  5  
…  …  horizontal ellipsis  infix  150  0  0  
⋮  ⋮  vertical ellipsis  infix  150  5  5  
⋯  ⋯  midline horizontal ellipsis  infix  150  0  0  
⋱  ⋱  down right diagonal ellipsis  infix  150  5  5  
∋  ∋  contains as member  infix  160  5  5  
⊢  ⊢  right tack  infix  170  5  5  
⊣  ⊣  left tack  infix  170  5  5  
⊤  ⊤  down tack  infix  170  5  5  
⊨  ⊨  true  infix  170  5  5  
⊩  ⊩  forces  infix  170  5  5  
⊬  ⊬  does not prove  infix  170  5  5  
⊭  ⊭  not true  infix  170  5  5  
⊮  ⊮  does not force  infix  170  5  5  
⊯  ⊯  negated double vertical bar double right turnstile  infix  170  5  5  
∨  ∨  logical or  infix  190  4  4  
&&  &&  multiple character operator: &&  infix  200  4  4  
∧  ∧  logical and  infix  200  4  4  
∀  ∀  for all  prefix  230  2  1  
∃  ∃  there exists  prefix  230  2  1  
∄  ∄  there does not exist  prefix  230  2  1  
∁  ∁  complement  infix  240  1  2  
∈  ∈  element of  infix  240  5  5  
∉  ∉  not an element of  infix  240  5  5  
∌  ∌  does not contain as member  infix  240  5  5  
⊂  ⊂  subset of  infix  240  5  5  
⊂⃒  ⊂⃒  subset of with vertical line  infix  240  5  5  
⊃  ⊃  superset of  infix  240  5  5  
⊃⃒  ⊃⃒  superset of with vertical line  infix  240  5  5  
⊄  ⊄  not a subset of  infix  240  5  5  
⊅  ⊅  not a superset of  infix  240  5  5  
⊆  ⊆  subset of or equal to  infix  240  5  5  
⊇  ⊇  superset of or equal to  infix  240  5  5  
⊈  ⊈  neither a subset of nor equal to  infix  240  5  5  
⊉  ⊉  neither a superset of nor equal to  infix  240  5  5  
⊊  ⊊  subset of with not equal to  infix  240  5  5  
⊋  ⊋  superset of with not equal to  infix  240  5  5  
<=  <=  multiple character operator: <=  infix  241  5  5  
≤  ≤  lessthan or equal to  infix  241  5  5  
≥  ≥  greaterthan or equal to  infix  242  5  5  
>  >  greaterthan sign  infix  243  5  5  
>=  >=  multiple character operator: >=  infix  243  5  5  
≯  ≯  not greaterthan  infix  244  5  5  
<  <  lessthan sign  infix  245  5  5  
≮  ≮  not lessthan  infix  246  5  5  
≈  ≈  almost equal to  infix  247  5  5  
∼  ∼  tilde operator  infix  250  5  5  
≉  ≉  not almost equal to  infix  250  5  5  
≢  ≢  not identical to  infix  252  5  5  
≠  ≠  not equal to  infix  255  5  5  
!=  !=  multiple character operator: !=  infix  260  4  4  
*=  *=  multiple character operator: *=  infix  260  4  4  
+=  +=  multiple character operator: +=  infix  260  4  4  
=  =  multiple character operator: =  infix  260  4  4  
/=  /=  multiple character operator: /=  infix  260  4  4  
:=  :=  multiple character operator: :=  infix  260  4  4  
=  =  equals sign  infix  260  5  5  
==  ==  multiple character operator: ==  infix  260  4  4  
∝  ∝  proportional to  infix  260  5  5  
∤  ∤  does not divide  infix  260  5  5  
∥  ∥  parallel to  infix  260  5  5  
∦  ∦  not parallel to  infix  260  5  5  
≁  ≁  not tilde  infix  260  5  5  
≃  ≃  asymptotically equal to  infix  260  5  5  
≄  ≄  not asymptotically equal to  infix  260  5  5  
≅  ≅  approximately equal to  infix  260  5  5  
≆  ≆  approximately but not actually equal to  infix  260  5  5  
≇  ≇  neither approximately nor actually equal to  infix  260  5  5  
≍  ≍  equivalent to  infix  260  5  5  
≔  ≔  colon equals  infix  260  5  5  
≗  ≗  ring equal to  infix  260  5  5  
≙  ≙  estimates  infix  260  5  5  
≚  ≚  equiangular to  infix  260  5  5  
≛  ≛  star equals  infix  260  5  5  
≜  ≜  delta equal to  infix  260  5  5  
≟  ≟  questioned equal to  infix  260  5  5  
≡  ≡  identical to  infix  260  5  5  
≨  ≨  lessthan but not equal to  infix  260  5  5  
≩  ≩  greaterthan but not equal to  infix  260  5  5  
≪  ≪  much lessthan  infix  260  5  5  
≪̸  ≪̸  much less than with slash  infix  260  5  5  
≫  ≫  much greaterthan  infix  260  5  5  
≫̸  ≫̸  much greater than with slash  infix  260  5  5  
≭  ≭  not equivalent to  infix  260  5  5  
≰  ≰  neither lessthan nor equal to  infix  260  5  5  
≱  ≱  neither greaterthan nor equal to  infix  260  5  5  
≺  ≺  precedes  infix  260  5  5  
≻  ≻  succeeds  infix  260  5  5  
≼  ≼  precedes or equal to  infix  260  5  5  
≽  ≽  succeeds or equal to  infix  260  5  5  
⊀  ⊀  does not precede  infix  260  5  5  
⊁  ⊁  does not succeed  infix  260  5  5  
⊥  ⊥  up tack  infix  260  5  5  
⊴  ⊴  normal subgroup of or equal to  infix  260  5  5  
⊵  ⊵  contains as normal subgroup or equal to  infix  260  5  5  
⋉  ⋉  left normal factor semidirect product  infix  260  4  4  
⋊  ⋊  right normal factor semidirect product  infix  260  4  4  
⋋  ⋋  left semidirect product  infix  260  4  4  
⋌  ⋌  right semidirect product  infix  260  4  4  
⋔  ⋔  pitchfork  infix  260  5  5  
⋖  ⋖  lessthan with dot  infix  260  5  5  
⋗  ⋗  greaterthan with dot  infix  260  5  5  
⋘  ⋘  very much lessthan  infix  260  5  5  
⋙  ⋙  very much greaterthan  infix  260  5  5  
⋪  ⋪  not normal subgroup of  infix  260  5  5  
⋫  ⋫  does not contain as normal subgroup  infix  260  5  5  
⋬  ⋬  not normal subgroup of or equal to  infix  260  5  5  
⋭  ⋭  does not contain as normal subgroup or equal  infix  260  5  5  
■  ■  black square  infix  260  3  3  
□  □  white square  infix  260  3  3  
▪  ▪  black small square  infix  260  3  3  
▫  ▫  white small square  infix  260  3  3  
▭  ▭  white rectangle  infix  260  3  3  
▮  ▮  black vertical rectangle  infix  260  3  3  
▯  ▯  white vertical rectangle  infix  260  3  3  
▰  ▰  black parallelogram  infix  260  3  3  
▱  ▱  white parallelogram  infix  260  3  3  
△  △  white uppointing triangle  infix  260  4  4  
▴  ▴  black uppointing small triangle  infix  260  4  4  
▵  ▵  white uppointing small triangle  infix  260  4  4  
▶  ▶  black rightpointing triangle  infix  260  4  4  
▷  ▷  white rightpointing triangle  infix  260  4  4  
▸  ▸  black rightpointing small triangle  infix  260  4  4  
▹  ▹  white rightpointing small triangle  infix  260  4  4  
▼  ▼  black downpointing triangle  infix  260  4  4  
▽  ▽  white downpointing triangle  infix  260  4  4  
▾  ▾  black downpointing small triangle  infix  260  4  4  
▿  ▿  white downpointing small triangle  infix  260  4  4  
◀  ◀  black leftpointing triangle  infix  260  4  4  
◁  ◁  white leftpointing triangle  infix  260  4  4  
◂  ◂  black leftpointing small triangle  infix  260  4  4  
◃  ◃  white leftpointing small triangle  infix  260  4  4  
◄  ◄  black leftpointing pointer  infix  260  4  4  
◅  ◅  white leftpointing pointer  infix  260  4  4  
◆  ◆  black diamond  infix  260  4  4  
◇  ◇  white diamond  infix  260  4  4  
◈  ◈  white diamond containing black small diamond  infix  260  4  4  
◉  ◉  fisheye  infix  260  4  4  
◌  ◌  dotted circle  infix  260  4  4  
◍  ◍  circle with vertical fill  infix  260  4  4  
◎  ◎  bullseye  infix  260  4  4  
●  ●  black circle  infix  260  4  4  
◖  ◖  left half black circle  infix  260  4  4  
◗  ◗  right half black circle  infix  260  4  4  
◦  ◦  white bullet  infix  260  4  4  
⧀  ⧀  circled lessthan  infix  260  5  5  
⧁  ⧁  circled greaterthan  infix  260  5  5  
⧣  ⧣  equals sign and slanted parallel  infix  260  5  5  
⧤  ⧤  equals sign and slanted parallel with tilde above  infix  260  5  5  
⧥  ⧥  identical to and slanted parallel  infix  260  5  5  
⧦  ⧦  gleich stark  infix  260  5  5  
⧳  ⧳  errorbarred black circle  infix  260  3  3  
⪇  ⪇  lessthan and singleline not equal to  infix  260  5  5  
⪈  ⪈  greaterthan and singleline not equal to  infix  260  5  5  
⪯  ⪯  precedes above singleline equals sign  infix  260  5  5  
⪯̸  ⪯̸  precedes above singleline equals sign with slash  infix  260  5  5  
⪰  ⪰  succeeds above singleline equals sign  infix  260  5  5  
⪰̸  ⪰̸  succeeds above singleline equals sign with slash  infix  260  5  5  
⁄  ⁄  fraction slash  infix  265  4  4  stretchy 
∆  ∆  increment  infix  265  3  3  
∊  ∊  small element of  infix  265  5  5  
∍  ∍  small contains as member  infix  265  5  5  
∎  ∎  end of proof  infix  265  3  3  
∕  ∕  division slash  infix  265  4  4  stretchy 
∗  ∗  asterisk operator  infix  265  4  4  
∘  ∘  ring operator  infix  265  4  4  
∙  ∙  bullet operator  infix  265  4  4  
∟  ∟  right angle  infix  265  5  5  
∣  ∣  divides  infix  265  5  5  
∶  ∶  ratio  infix  265  5  5  
∷  ∷  proportion  infix  265  5  5  
∸  ∸  dot minus  infix  265  4  4  
∹  ∹  excess  infix  265  5  5  
∺  ∺  geometric proportion  infix  265  4  4  
∻  ∻  homothetic  infix  265  5  5  
∽  ∽  reversed tilde  infix  265  5  5  
∽̱  ∽̱  reversed tilde with underline  infix  265  3  3  
∾  ∾  inverted lazy s  infix  265  5  5  
∿  ∿  sine wave  infix  265  3  3  
≂  ≂  minus tilde  infix  265  5  5  
≂̸  ≂̸  minus tilde with slash  infix  265  5  5  
≊  ≊  almost equal or equal to  infix  265  5  5  
≋  ≋  triple tilde  infix  265  5  5  
≌  ≌  all equal to  infix  265  5  5  
≎  ≎  geometrically equivalent to  infix  265  5  5  
≎̸  ≎̸  geometrically equivalent to with slash  infix  265  5  5  
≏  ≏  difference between  infix  265  5  5  
≏̸  ≏̸  difference between with slash  infix  265  5  5  
≐  ≐  approaches the limit  infix  265  5  5  
≑  ≑  geometrically equal to  infix  265  5  5  
≒  ≒  approximately equal to or the image of  infix  265  5  5  
≓  ≓  image of or approximately equal to  infix  265  5  5  
≕  ≕  equals colon  infix  265  5  5  
≖  ≖  ring in equal to  infix  265  5  5  
≘  ≘  corresponds to  infix  265  5  5  
≝  ≝  equal to by definition  infix  265  5  5  
≞  ≞  measured by  infix  265  5  5  
≣  ≣  strictly equivalent to  infix  265  5  5  
≦  ≦  lessthan over equal to  infix  265  5  5  
≦̸  ≦̸  lessthan over equal to with slash  infix  265  5  5  
≧  ≧  greaterthan over equal to  infix  265  5  5  
≬  ≬  between  infix  265  5  5  
≲  ≲  lessthan or equivalent to  infix  265  5  5  
≳  ≳  greaterthan or equivalent to  infix  265  5  5  
≴  ≴  neither lessthan nor equivalent to  infix  265  5  5  
≵  ≵  neither greaterthan nor equivalent to  infix  265  5  5  
≶  ≶  lessthan or greaterthan  infix  265  5  5  
≷  ≷  greaterthan or lessthan  infix  265  5  5  
≸  ≸  neither lessthan nor greaterthan  infix  265  5  5  
≹  ≹  neither greaterthan nor lessthan  infix  265  5  5  
≾  ≾  precedes or equivalent to  infix  265  5  5  
≿  ≿  succeeds or equivalent to  infix  265  5  5  
≿̸  ≿̸  succeeds or equivalent to with slash  infix  265  5  5  
⊌  ⊌  multiset  infix  265  4  4  
⊍  ⊍  multiset multiplication  infix  265  4  4  
⊎  ⊎  multiset union  infix  265  4  4  
⊏  ⊏  square image of  infix  265  5  5  
⊏̸  ⊏̸  square image of with slash  infix  265  5  5  
⊐  ⊐  square original of  infix  265  5  5  
⊐̸  ⊐̸  square original of with slash  infix  265  5  5  
⊑  ⊑  square image of or equal to  infix  265  5  5  
⊒  ⊒  square original of or equal to  infix  265  5  5  
⊓  ⊓  square cap  infix  265  4  4  
⊔  ⊔  square cup  infix  265  4  4  
⊚  ⊚  circled ring operator  infix  265  4  4  
⊛  ⊛  circled asterisk operator  infix  265  4  4  
⊜  ⊜  circled equals  infix  265  4  4  
⊝  ⊝  circled dash  infix  265  4  4  
⊦  ⊦  assertion  infix  265  5  5  
⊧  ⊧  models  infix  265  5  5  
⊪  ⊪  triple vertical bar right turnstile  infix  265  5  5  
⊫  ⊫  double vertical bar double right turnstile  infix  265  5  5  
⊰  ⊰  precedes under relation  infix  265  5  5  
⊱  ⊱  succeeds under relation  infix  265  5  5  
⊲  ⊲  normal subgroup of  infix  265  5  5  
⊳  ⊳  contains as normal subgroup  infix  265  5  5  
⊶  ⊶  original of  infix  265  5  5  
⊷  ⊷  image of  infix  265  5  5  
⊹  ⊹  hermitian conjugate matrix  infix  265  5  5  
⊺  ⊺  intercalate  infix  265  4  4  
⊻  ⊻  xor  infix  265  4  4  
⊼  ⊼  nand  infix  265  4  4  
⊽  ⊽  nor  infix  265  4  4  
⊾  ⊾  right angle with arc  infix  265  3  3  
⊿  ⊿  right triangle  infix  265  3  3  
⋄  ⋄  diamond operator  infix  265  4  4  
⋆  ⋆  star operator  infix  265  4  4  
⋇  ⋇  division times  infix  265  4  4  
⋈  ⋈  bowtie  infix  265  5  5  
⋍  ⋍  reversed tilde equals  infix  265  5  5  
⋎  ⋎  curly logical or  infix</ 