This specification defines a core subset of Mathematical Markup Language, or MathML, that is suitable for browser implementation. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.
Status of This DocumentThis section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Math Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation.
GitHub Issues are preferred for discussion of this specification.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 15 September 2020 W3C Process Document.
Table of ContentsMATH table
text-transform Mappings
bold-script mappingsbold-italic mappingstailed mappingsbold mappingsfraktur mappingsscript mappingsmonospace mappingsinitial mappingssans-serif mappingsdouble-struck mappingslooped mappingsstretched mappingsitalic mappingsbold-fraktur mappingssans-serif-bold-italic mappingssans-serif-italic mappingsbold-sans-serif mappingsThis section is non-normative.
The [MATHML3] specification has several shortcomings that make it hard to implement consistently across web rendering engines or to extend with user-defined constructions e.g.
This MathML Core specification intends to address these issues by being as accurate as possible on the visual rendering of mathematical formulas using additional rules from the TeXBook’s Appendix G [TEXBOOK] and from the Open Font Format [OPEN-FONT-FORMAT], [OPEN-TYPE-MATH-ILLUMINATED]. It also relies on modern browser implementations and web technologies [HTML] clarifying interactions with them when needed or introducing new low-level primitives to improve the web platform layering.
Parts of MathML3 that do not fit well in this framework or are less fundamental have been omitted. Instead, they are described in a separate and larger [MATHML4] specification. The details of which math feature will be included in future versions of MathML Core or implemented as polyfills is still open. This question and other potential improvements are tracked on GitHub.
By increasing the level of implementation details, focusing on a workable subset, following a browser-driven design and relying on automated web platform tests, this specification is expected to greatly improve MathML interoperability. Moreover, effort on MathML layering will enable users to implement the rest of the MathML 4 specification, or more generally to extend MathML Core, using modern web technologies such as shadow DOM, custom elements, CSS layout API or other Houdini APIs.
2. MathML Fundamentals 2.1 Elements and attributesThe term MathML element refers to any element in the MathML namespace. The MathML element defined in this specification are called the MathML Core elements and are listed below. Any MathML element that is not listed below is called an Unknown MathML element.
<annotation><annotation-xml><maction><math><merror><mfrac><mi><mmultiscripts><mn><mo><mover><mpadded><mphantom><mprescripts><mroot><mrow><ms><mspace><msqrt><mstyle><msub><msubsup><msup><mtable><mtd><mtext><mtr><munder><munderover><none><semantics>The grouping elements are <maction>, <math>, <merror> <mphantom>, <mprescripts>, <mrow>, <mstyle>, <none>, <semantics> and unknown MathML elements.
The scripted elements are <mmultiscripts>, <mover>, <msub>, <msubsup>, <msup>, <munder> and <munderover>.
The radical elements are <mroot> and <msqrt>.
The attributes defined in this specification have no namespace and are called MathML attributes:
maction attributesmo attributesmpadded attributesmspace attributesmunderover attributesmtd attributesencodingdisplaylinethickness<math> Element
MathML specifies a single top-level or root <math> element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a <math> element.
The <math> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attribute:
The display attribute, if present, must be an ASCII case-insensitive match to block or inline. The user agent stylesheet described in § A. User Agent Stylesheet contains rules for this attribute that affect the default values for the displayblock math or inline math) and math-stylenormal or compact) properties. If the display attribute is absent or has an invalid value, the User Agent stylesheet treats it the same as inline.
If the element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise the layout algorithm of the <mrow>display: block (if the computed value is block math) or display: inline (if the computed value is inline math). Additionally, if the computed display property is equal to block math then that MathML box is rendered horizontally centered within the content box.
Note
TEX's display mode $$...$$ and inline mode $...$ correspond to display="block" and display="inline" respectively.
In the following example, a <math> formula is rendered in display mode on a new line and taking full width, with the math content centered within the container:
As a comparison, the same formula would look as follows in inline mode. The formula is embedded in the paragraph of text without forced line breaking. The baselines specified by the layout algorithm of the <mrow>
Because good mathematical rendering requires use of mathematical fonts, the user agent stylesheet should set the font-family to the math value on the <math> element instead of inheriting it. Additionally, several CSS properties that can be set on a parent container such as font-style, font-weight, direction or text-indent etc are not expected to apply to the math formula and so the user agent stylesheet has rules to reset them by default.
<integer> value as defined in [CSS-VALUES-3], whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).
<length-percentage> value as defined in [CSS-VALUES-3]
<color> value as defined in [CSS-COLOR-3]
true or false.
The following attributes are common to and may be specified on all MathML elements:
classdata-*dirdisplaystyleidmathbackgroundmathcolormathsizemathvariantnoncescriptlevelstyletabindexon* event handler attributesThe id, class, style, data-*, nonce and tabindex attributes have the same syntax and semantic as defined for id, class, style, data-*, nonce and tabindex attributes on HTML elements.
The dir attribute, if present, must be an ASCII case-insensitive match to ltr or rtl. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's direction property to the corresponding value. More precisely, an ASCII case-insensitive match to rtl is mapped to rtl while an ASCII case-insensitive match to ltr is mapped to ltr.
Note
The
dir
attribute is used to set the directionality of math formulas, which is often
rtl
in Arabic speaking world. However, languages written from right to left often embed math written from left to right and so the
user agent stylesheetresets the
direction
property accordingly on the
<math>elements.
In the following example, the dir attribute is used to render "𞸎 plus 𞸑 raised to the power of (٢ over, 𞸟 plus ١)" from right-to-left.
All MathML elements support event handler content attributes, as described in event handler content attributes in HTML.
All event handler content attributes noted by HTML as being supported by all HTMLElements are supported by all MathML elements as well, as defined in the MathMLElement IDL.
2.1.5 Legacy MathML Style AttributesThe mathcolor and mathbackground attributes, if present, must have a value that is a color. In that case, the user agent is expected to treat these attributes as a presentational hint setting the element's color and background-color properties to the corresponding values. The mathcolor attribute describes the foreground fill color of MathML text, bars etc while the mathbackground attribute describes the background color of an element.
The mathsize attribute, if present, must have a value that is a valid length-percentage. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's font-sizemathsize property indicates indicates the desired height of glyphs in math formulas but also scale other parts (spacing, shifts, line thickness of bars etc) accordingly.
Note
The above attributes are implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
2.1.6 Themathvariant attribute
The mathvariant attribute, if present, must be an ASCII case-insensitive match to one of: normal, bold, italic, bold-italic, double-struck, bold-fraktur, script, bold-script, fraktur, sans-serif, bold-sans-serif, sans-serif-italic, sans-serif-bold-italic, monospace, initial, tailed, looped, or stretched. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's text-transformnormal is mapped to none while any other valid value is mapped to its ASCII lowercased value, prefixed with math-.
The mathvariant attribute defines logical classes of token elements. Each class provides a collection of typographically-related symbolic tokens with specific meaning within a given mathematical expression. For mathvariant values other than normal, this is done by using glyphs of Unicode's Mathematical Alphanumeric Symbols.
In the following example, the mathvariant attribute is used to render different A letters. Note that by default variables use mathematical italic.
Note
mathvariant
values other than
normal
are implemented for compatibility with full MathML and legacy editors that can't access characters in Plane 1 of Unicode. Authors are encouraged to use the corresponding Unicode characters. The
normal
value is still important to cancel automatic italic of the
<mi>element.
Note
Unicode does not distinguish between Chancery and Spencerian style for the Unicode MATHEMATICAL SCRIPT characters. However, some mathematical fonts rely on
salt
or
ssXY
properties from [
OPEN-FONT-FORMAT] to provide both styles. Page authors may use the
font-variant-alternates
property with corresponding OpenType font features to access these glyphs.
2.1.7 Thedisplaystyle and scriptlevel attributes
The displaystyle attribute, if present, must have a value that is a boolean. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's math-styletrue is mapped to normal while an ASCII case-insensitive match to false is mapped to compact. This attribute indicates whether formulas should try to minimize the logical height (value is false) or not (value is true) e.g. by changing the size of content or the layout of scripts.
The scriptlevel attribute, if present, must have value +<U>, -<U> or <U> where <U> is an unsigned-integer. In that case the user agent is expected to treat the scriptlevel attribute as a presentational hint setting the element's math-depth+<U>, -<U> and <U> are respectively mapped to add(<U>) add(<-U>) and <U>.
displaystylescriptlevelfont-size: math is specified to ensure that scriptlevel changes are taken into account.
In this example, a <munder> element is used to attach a script "A" to a base "∑". By default, the summation symbol is rendered with the font-size inherited from its parent and the A as a scaled down subscript. If displaystyle is true, the summation symbol is drawn bigger and the "A" becomes an underscript. If scriptlevel is reset to 0 on the "A", then it will use the same font-size as the top-level math root.
Note
T
EX's
\displaystyle
,
\textstyle
,
\scriptstyle
, and
\scriptscriptstyle
correspond to
displaystyleand
scriptlevelas
true
and
0
,
false
and
0
,
false
and
1
, and
false
and 2, respectively.
2.2 Integration in the Web Platform 2.2.1 HTML and SVGWhen parsing HTML documents user agents must treat any tag name corresponding to a MathML Core Element as belonging to the MathML namespace.
Users agents must allow mixing HTML, SVG and MathML elements as allowed by sections HTML integration point, MathML integration point, tree construction dispatcher, MathML and SVG from [HTML].
When evaluating the SVG requiredExtensions attribute, user agents must claim support for the language extension identified by the MathML namespace.
In this example, inline MathML and SVG elements are used inside a HTML document. SVG elements <switch> and <foreignObject> (with proper <requiredExtensions>) are used to embed a MathML formula with a text fallback, inside a diagram. HTML input element is used within the <mtext> include an interactive input field inside a mathematical formula.
User agents must support various CSS features mentioned in this specification, including new ones described in § 4. CSS Extensions for Math Layout. They must follow the computation rule for display: contents.
In this example, the MathML formula inherits the CSS color of its parent and uses the font-family specified via the style attribute.
All documents containing MathML Core elements must include CSS rules described in § A. User Agent Stylesheet as part of user-agent level style sheet defaults.
The following CSS features are not supported and must be ignored:
writing-mode is treated as horizontal-tb on all MathML elements.white-space is treated as nowrap on all MathML elements.width, height, inline-size and block-size are treated as auto on elements with computed display value block math or inline math.float and clear are treated as none on all MathML elements.align-content, justify-content, align-self, justify-self have no effect on MathML elements.Note
These features might be handled in future versions of this document. For now, authors are discouraged from setting a different value for these properties as that might lead to backward incompatibility issues.
2.2.3 DOM and JavascriptUser agents supporting Web application APIs must ensure that they keep the visual rendering of MathML synchronized with the [DOM] tree.
All the nodes representing MathML elements in the DOM must implement, and expose to scripts, the following MathMLElement interface.
The GlobalEventHandlers, DocumentAndElementEventHandlers and HTMLOrForeignElement interfaces are defined in [HTML].
Each IDL attribute of the MathMLElement
In the following example, a MathML formula is used to render the fraction "α over 2". When clicking the red α, it is changed into a blue β.
2.2.4 Text layoutBecause math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. As a consequence, user agents must take into account the USE_TYPO_METRICS flag from the OS/2 table [OPEN-FONT-FORMAT] when performing text layout.
2.2.5 FocusMathML provides the ability for authors to allow for interactivity in supporting interactive user agents using the same concepts, approach and guidance to Focus as described in HTML, with modifications or clarifications regarding application for MathML as described in this section.
When an element is focused, all applicable CSS focus-related pseudo-classes as defined in Selectors Level 3 apply, as defined in that specification.
The contents of embedded <math>
The default display property is described in § A. User Agent Stylesheet:
<math> root, it is equal to inline math or block math according to the value of the display attribute.<mtable><mtr><mtd>inline-table, table-row and table-cell.<maction> and <semantics> elements, it is equal to none.block math.In order to specify math layout in different writing modes, this specification uses concepts from [CSS-WRITING-MODES-3]:
Note
Unless specified otherwise, the figures in this specification use a
writing modeof
horizontal-lr
and
ltr
. See
Figure 4,
Figure 5and
Figure 6for examples of other writing modes that are sometimes used for math layout.
MathML boxes have several parameters in order to perform layout in a way that is compatible with CSS but also to take into account very accurate positions and spacing within math formulas. Each math box has the following parameters:
Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:
Note
For math layout, it is very important to rely on the ink extent when positioning text. This is not the case for more complex notations (e.g. square root). Although ink-ascent and ink-descent are defined for all MathML elements they are really only used for the token elements. In other cases, they just match normal ascent and descent.
Unless specified otherwise, the last baseline set is equal to the first baseline set for MathML boxes.Given a MathML box, the inline offset of a child box is the distance between the inline-start edge of the parent box and the inline-start edge of the child box. The block offset of a child box is the offset between block-start edge of the parent box and the block-start edge of the child box.
The line-left offset, line-right offset, line-over offset and line-under offset are defined similarly as offsets between the corresponding parent and child edges.
Figure 4 Box model for writing modehorizontal-tb and rtl that may be used in e.g. Arabic math. Figure 5 Box model for writing mode vertical-lr and ltr that may be used in e.g. Mongolian math. Figure 6 Box model for writing mode vertical-rl and ltr that may be used in e.g. Japanese math.
Note
The position of child boxes and graphical items inside a MathML box are expressed using the
inline offsetand
block offset. For convenience, the layout algorithms may describe offsets using flow-relative directions, line-relative directions or the
alphabetic baseline. It is always possible to pass from one description to the other because position of child boxes are always performed after the metrics of the box and of its child boxes are calculated.
Improve definition of ink ascent/descent?
3.1.2 Layout AlgorithmsThe layout algorithms described in this chapter for MathML boxes have the following structure:
During box layout, the following extra steps must be performed:
The box metrics and offsets of the padding box are obtained from the content box by taking into account the corresponding padding properties as described in CSS.
The baselines of the padding box are the same as the one of the content box.
If the content box has a top accent attachment then the padding box has the same property, increased by the inline-start padding. If the content box has an italic correction then the padding box has the same property, increased by the inline-end padding.
The box metrics and offsets of the border box are obtained from the padding box by taking into account the corresponding border-width property as described in CSS.
In general, the baselines of the border box are the same as the one of the padding box. However, if the line-over border is positive then the ink-over baseline is set to the line-over edge of the border box and if the line-under border is positive then the ink-under baseline is set to the line-under edge of the border box.
If the padding box has a top accent attachment then the border box has the same property, increased by the border-width of its inline-start egde. If the padding box has an italic correction then the border box has the same property, increased by the border-width of its inline-end egde.
The box metrics and offsets of the margin box are obtained from the border box by taking into account the corresponding margin properties as described in CSS.
The baselines of the margin box are the same as the one of the border box.
If the padding box has a top accent attachment then the margin box has the same property, increased by the inline-start margin. If the padding box has an italic correction then the margin box has the same property, increased by the inline-end margin.
During box layout, optional inline stretch size constraint and block stretch size constraint parameters may be used on embellished operators. The former indicates a target size that a core operator stretched along the inline axis should cover. The latter indicates an ink line-ascent and ink line-descent that a core operator stretched along the block axis should cover. Unless specified otherwise, these parameters are ignored during box layout and child boxes are laid out without any stretch size constraint.
Explain how out-of-flow elements are positioned.
Interpret width/height/inline-size/block-size?
Define what inline percentages resolve against
Define what block percentages resolve against
3.1.3 Stacking contextsMathML elements can overlap due to various spacing rules. They can as well contain extra graphical items (bars, radical symbol, etc). A MathML element with computed style display: block math or display: inline math generates a new stacking context. The painting order of in-flow children of such a MathML element is exactly the same as block elements. The extra graphical items are painted after text and background (right after step 7.2.4 for display: inline math and right after step 7.2 for display: block math).
Token elements in presentation markup are broadly intended to represent the smallest units of mathematical notation which carry meaning. Tokens are roughly analogous to words in text. However, because of the precise, symbolic nature of mathematical notation, the various categories and properties of token elements figure prominently in MathML markup. By contrast, in textual data, individual words rarely need to be marked up or styled specially.
Note
In practice, most MathML token elements just contain simple text for variables, numbers, operators etc and don't need sophisticated layout. However, it can contain contain text with line breaks or arbitrary HTML5 phrasing elements.
3.2.1 Text<mtext>
The <mtext> element is used to represent arbitrary text that should be rendered as itself. In general, the <mtext> element is intended to denote commentary text.
The <mtext> element accepts the attributes described in § 2.1.3 Global Attributes.
In the following example, <mtext> is used to put conditional words in a definition:
<mtext>
If the element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
The mtext element is laid out as a block box and the min-content inline size, max-content inline size, inline size, block size, first baseline set and last baseline set are determined accordingly.
If the <mtext> element contains only text content without forced line break or soft wrap opportunity then in addition:
<mtext> element.<mi>
The <mi> element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants.
The <mi> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mtext> element. The user agent stylesheet must contain the following property in order to implement automatic italic:
In the following example, <mi> is used to render variables and function names. Note that identifiers containing a single letter are italic by default.
<mn>
The <mn> element represents a "numeric literal" or other data that should be rendered as a numeric literal. Generally speaking, a numeric literal is a sequence of digits, perhaps including a decimal point, representing an unsigned integer or real number.
The <mn> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mtext>
In the following example, <mn> is used to write a decimal number.
<mo>
The <mo> element represents an operator or anything that should be rendered as an operator. In general, the notational conventions for mathematical operators are quite complicated, and therefore MathML provides a relatively sophisticated mechanism for specifying the rendering behavior of an <mo> element.
As a consequence, in MathML the list of things that should "render as an operator" includes a number of notations that are not mathematical operators in the ordinary sense. Besides ordinary operators with infix, prefix, or postfix forms, these include fence characters such as braces, parentheses, and "absolute value" bars; separators such as comma and semicolon; and mathematical accents such as a bar or tilde over a symbol. This chapter uses the term "operator" to refer to operators in this broad sense.
The <mo> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attributes:
This specification does not define any observable behavior that is specific to the fence and separator attributes.
In the following example, the <mo> element is used for the binary operator +. Default spacing is symmetric around that operator. A tigher spacing is used if you rely on the formlspacerspace
Another use case is for big operator such as summation. When displaystyle is true, such an operator are drawn larger but one can change that with the largeop attribute. When displaystyle is false, underscript are actually rendered as subscript but one can change that with the movablelimits attribute.
Operators are also used for stretchy symbols such as fences, accents, arrows etc. In the following example, the vertical arrow stretches to the height of the <mspace> element. One can override default stretch behavior with the stretchy attribute e.g. to force an unstretched arrow. The symmetric attribute allows to indicate whether the operator should stretchy symmetrically above and below the baseline. Finally the minsize and maxsize attributes add additional constraints over the stretch size.
Note that the default properties of operators are dictionary-based, as explained in § 3.2.4.2 Dictionary-based attributes. For example a binary operator typically has default symmetric spacing around it while a fence is generally stretchy by default.
3.2.4.1 Embellished operatorsA MathML Core element is an embellished operator if it is:
<mo><mfrac><mpadded>, whose in-flow children consist (in any order) of one embellished operator and zero or more space-like elements.The core operator of an embellished operator is the <mo> element defined recursively as follows:
<mo><mfrac><mpadded> is the core operator of its unique embellished operator in-flow child.The stretch axis of an embellished operator is inline if its core operator contains only text content made of a unique character c and that character has stretch axis inline per § B.2 Stretchy Operator Axis. Otherwise, stretch axis of the embellished operator is block.
The form property of an embellished operator is either infix, prefix or postfix. The corresponding form attribute on the <mo>
The algorithm for determining the form of an embellished operator is as follows:
form attribute is present and valid on the core operator, then its ASCII lowercased value is used;<mpadded> or <msqrt> with more than one in-flow child (ignoring all space-like children) then it has form prefix;<mpadded><msqrt>postfix;postfix;infix.The stretchy, symmetric, largeop, movablelimits, properties of an embellished operator are either false or true. In the latter case, it is said that the embellished operator has the property. The corresponding attributes on the <mo>
The lspace, rspace, minsize properties of an embellished operator are length-percentage. The maxsize property of an embellished operator is either a length-percentage or ∞. The lspace, rspace, minsize and maxsize attributes on the <mo>
The algorithm for determining the properties of an embellished operator is as follows:
stretchy, symmetric, largeop, movablelimits, lspace, rspace, maxsize or minsize attribute is present and valid on the core operator, then the ASCII lowercased value of this property is used;Content=T,Form=F where F is the formformF in the following order: infix, prefix, postfix;false for stretchy, symmetric, largeop and movablelimits properties ; 0.2777777777777778em for lspace and rspace properties ; 1em for the minsize property and ∞ for the maxsize property.Percentage values for lspace, rspace properties of an embellished operator are interpreted relative to the value read from the dictionary or to the fallback value above.
Interpretation of percentage values for minsize and maxsize are described in § 3.2.4.3 Layout of operators.
Font-relative lengths for lspace, rspace, minsize and maxsize rely on the font style of the core operator, not the one of the embellished operator.
If the <mo> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
The text of the operator must only be painted if the visibility of the <mo> element is visible. In that case, it must be painted with the color of the <mo> element.
Operators are laid out as follows:
<mo> element is not made of a single character c then fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.stretchy property:
c in the inline direction with the first available font then fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.<mtext>.Tinline then fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.Tinline.Tinline and at position determined by the previous box metrics.c in the block direction with the first available font then fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.(Uascent, Udescent) then fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.symmetric property then set the target sizes Tascent and Tdescent to Sascent and Sdescent respectively:
Sascent = max( Uascent − AxisHeight, Udescent + AxisHeight ) + AxisHeightSdescent = max( Uascent − AxisHeight, Udescent + AxisHeight ) − AxisHeightUascent and Udescent respectively.minsize and maxsize be the minsize and maxsize properties on the operator. Percentage values are intepreted relative to T = Tascent + Tdescent. If minsize < 0 then set minsize to 0. If maxsize < minsize then set maxsize to minsize. Then 0 ≤ minsize ≤ maxsize:
T ≤ 0 then set Tascent to minsize / 2 and then set Tdescent to minsize − TascentT < minsize then first multiply Tascent by minsize / T and then set Tdescent to minsize - Tascent.maxsize < T then first multiply Tascent by maxsize / T and then set Tdescent to maxsize − Tascent.Tascent + Tdescent. The inline size of the content is the width of the stretchy glyph. The stretchy glyph is shifted towards the line-under by a value Δ so that its center aligns with the center of the target: the ink ascent of the content is the ascent of the stretchy glyph − Δ and the ink descent of the content is the descent of the stretchy glyph + Δ. These centers have coordinates "½(ascent − descent)" so Δ = [(ascent of stretchy glyph − descent of stretchy glyph) − (Tascent − Tdescent)] / 2.Tascent + Tdescent and at position determined by the previous box metrics shifted by Δ towards the line-over.largeop property and if math-style<mo> element is normal, then:
Use the MathVariants table to try and find a glyph of height at least DisplayOperatorMinHeight If none is found, fallback to the largest non-base glyph. If none is found, fallback to the layout algorithm of § 3.2.1.1 Layout of <mtext>.
<mtext>.If the algorithm to shape a stretchy glyph has been used for one of the step above, then the italic correction of the content is set to the value returned by that algorithm.
Note
If maxsize is equal to its default value ∞ then minsize ≤ maxsize is satisfied but maxsize < T is not.
<mspace>
The <mspace> empty element represents a blank space of any desired size, as set by its attributes.
The <mspace> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attributes:
The mspace@width, mspace@height, mspace@depth, if present, must have a value that is a valid length-percentage. An unspecified attribute, a percentage value, or an invalid value is interpreted as 0. If one of the requested values calculated is negative then it is treated as 0.
In the following example, <mspace> is used to force spacing within the formula (a 1px blue border is added to easily visualize the space):
If the <mspace> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the <mspace> element is laid out as shown on Figure 9. The min-content inline size and max-content inline size of the content are equal to the requested inline size. The inline size, line-ascent and line-descent of the content are respectively the requested inline size, line-ascent and line-descent.
<mspace> element
Note
The terminology height/depth comes from [
MATHML3], itself inspired from [
TEXBOOK].
3.2.5.1 Definition of space-like elementsA number of MathML presentation elements are "space-like" in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions.
A MathML Core element is a space-like element if it is:
<mtext><mspace><mpadded> all of whose in-flow children are space-like.Note
Note that an
<mphantom>is not automatically defined to be space-like, unless its content is space-like. This is because operator spacing is affected by whether adjacent elements are space-like. Since the
<mphantom>
element is primarily intended as an aid in aligning expressions, operators adjacent to an
<mphantom>
should behave as if they were adjacent to the contents of the
<mphantom>
, rather than to an equivalently sized area of whitespace.
3.2.6 String Literal<ms>
<ms> element is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems containing "programming languages".
The <ms> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mtext>
In the following example, <ms> is used to write a literal string of characters:
Note
In MathML3, it was possible to use the
lquote
and
rquote
attributes to respectively specify the strings to use as opening and closing quotes. These are no longer supported and the quotes must instead be specified as part of the text of the
<ms>
element. One can add CSS rules to legacy documents in order to preserve visual rendering. For example, in left-to-right direction:
3.3 General Layout SchemataBesides tokens there are several families of MathML presentation elements. One family of elements deals with various "scripting" notations, such as subscript and superscript. Another family is concerned with matrices and tables. The remainder of the elements, discussed in this section, describe other basic notations such as fractions and radicals, or deal with general functions such as setting style properties and error handling.
3.3.1 Group Sub-Expressions<mrow>
The <mrow> element is used to group together any number of sub-expressions, usually consisting of one or more <mo> elements acting as "operators" on one or more other expressions that are their "operands".
In the following example, <mrow> is used to group a sum "1 + 2/3" as a fraction numerator (first child of <mfrac>) and to construct a fenced expression (first child of <msup>) that is raised to the power of 5. Note that <mrow> alone does not add visual fences around its grouped content, one has to explicitly specify them using the <mo> element.
Within the <mrow> elements, one can see that vertical alignment of children (according to the alphabetic baseline or the mathematical baseline) is properly performed, fences are vertically stretched and spacing around the binary + operator automatically calculated.
The <mrow> element accepts the attributes described in § 2.1.3 Global Attributes. An <mrow> element with in-flow children child1, child2, … childN is laid out as show on Figure 10. The child boxes are put in a row one after the other with all their alphabetic baselines aligned.
<mrow> element 3.3.1.1 Algorithm for stretching operators along the block axis Figure 11 Symmetric and non-symmetric stretching of operators along the block axis
The algorithm for stretching operators along the block axis consists in the following steps:
LToStretch containing embellished operators with a stretchy property and block stretch axis ; and a second list LNotToStretch.LNotToStretch. If LToStretch is empty then stop. If LNotToStretch is empty, perform layout with stretch size constraint 0 on all the items of LToStretch.Uascent and Udescent as respectively the maximum ink ascent and maximum ink descent of the margin boxes of in-flow children that have been laid out in the previous step.LToStretch with block stretch size constraint (Uascent, Udescent).<mrow>
If the element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
A child box is slanted if it is not an embellished operator and has nonzero italic correction.
The min-content inline size (respectively max-content inline size) are calculated using the following algorithm:
add-space to true if the element is a <math> or is not an embellished operator; and to false otherwise.inline-offset to 0.previous-italic-correction to 0.inline-offset by previous-italic-correction.add-space is true then increment inline-offset by its lspaceinline-offset by the min-content inline size (respectively max-content inline size) of the child's margin box.previous-italic-correction to its italic correction. Otherwise set it to 0.add-space is true then increment inline-offset by its rspaceinline-offset by previous-italic-correction.inline-offset.The in-flow children are laid out using the algorithm for stretching operators along the block axis.
The inline size of the content is calculated like the min-content inline size and max-content inline size of the content, using the inline size of the in-flow children's margin boxes instead.
The ink line-ascent (respectively line-ascent) of the content is the maximum of the ink line-ascents (respectively line-ascents) of all the in-flow children's margin boxes. Similarly, the ink line-descent (respectively line-descent) of the content is the maximum of the ink line-descents (respectively ink line-ascents) of all the in-flow children's margin boxes.
The in-flow children are positioned using the following algorithm:
add-space to true if the element is a <math> or is not an embellished operator; and to false otherwise.inline-offset to 0.previous-italic-correction to 0.inline-offset by previous-italic-correction.add-space is true then increment inline-offset by its lspaceinline-offset and its block offset such that the alphabetic baseline of the child is aligned with the alphabetic baseline.inline-offset by the inline size of the child's margin box.previous-italic-correction to its italic correction. Otherwise set it to 0.add-space is true then increment inline-offset by its rspaceThe italic correction of the content is set to the italic correction of the last in-flow child, which is the final value of previous-italic-correction.
<mfrac>
The <mfrac> element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols.
If the <mfrac> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
The <mfrac> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attribute:
The linethickness attribute indicates the fraction line thickness to use for the fraction bar. If present, it must have a value that is a valid length-percentage. If the attribute is absent or has an invalid value, FractionRuleThickness is used as the default value. A percentage is interpreted relative to that default value. A negative value is interpreted as 0.
The following example contains four fractions with different linethickness values. The bars are always aligned with the middle of plus and minus signs. The numerator and denominator are horizontally centered. The fractions that are not in displaystyle use smaller gaps and font-size.
The <mfrac> element sets displaystylefalse, or if it was already false increments scriptlevelmath-shift to compact within its second child. To avoid visual confusion between the fraction bar and another adjacent items (e.g. minus sign or another fraction's bar), a default 1-pixel space is added around the element. The user agent stylesheet must contain the following rules:
If the <mfrac> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
If the fraction line thickness is nonzero, the <mfrac> element is laid out as shown on Figure 12. The fraction bar must only be painted if the visibility of the <mfrac> element is visible. In that case, the fraction bar must be painted with the color of the <mfrac> element.
<mfrac> element
The min-content inline size (respectively max-content inline size) of content is the maximum between the min-content inline size (respectively max-content inline size) of the numerator's margin box and the min-content inline size (respectively max-content inline size) of the denominator's margin box.
If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.
The inline size of the content is the maximum between the inline size of the numerator's margin box and the inline size of the denominator's margin box.
NumeratorShift is the maximum between:
math-style is compact (respectively normal).math-style is compact (respectively normal) + the ink line-descent of the numerator's margin box.DenominatorShift is the maximum between:
math-style is compact (respectively normal).math-style is compact (respectively normal) + the ink line-ascent of the denominator's margin box − the AxisHeight.The line-ascent of the content is the maximum between:
Numerator Shift + the line-ascent of the numerator's margin box.Denominator Shift + the line-ascent of the denominator's margin boxThe line-descent of the content is the maximum between:
Numerator Shift + the line-descent of the numerator's margin box.Denominator Shift + the line-descent of the denominator's margin box.The inline offset of the numerator (respectively denominator) is the half the inline size of the content − half the inline size of the numerator's margin box (respectively denominator's margin box).
The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of NumeratorShift (respectively DenominatorShift ) towards the line-over (respectively line-under).
The inline size of the fraction bar is the inline size of the content and its inline offset is 0. The center of the fraction bar is shifted away from the alphabetic baseline by a distance of AxisHeight towards the line-over. Its block size is the fraction line thickness.
3.3.2.2 Fraction with zero line thicknessIf the fraction line thickness is zero, the <mfrac> element is instead laid out as shown on Figure 13.
<mfrac> element without bar
The min-content inline size, max-content inline size and inline size of the content are calculated the same as in § 3.3.2.1 Fraction with nonzero line thickness.
If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.
If the math-style is compact then TopShift and BottomShift are respectively set to StackTopShiftUp and StackBottomShiftDown. Otherwise math-style is normal and they are respectively set to StackTopDisplayStyleShiftUp and StackBottomDisplayStyleShiftDown.
The Gap is defined to be (BottomShift − the ink line-ascent of the denominator's margin box) + (TopShift − the ink line-descent of the numerator's margin box). If math-style is compact then GapMin is StackGapMin otherwise math-style is normal and it is StackDisplayStyleGapMin. If Δ = GapMin − Gap is positive then TopShift and BottomShift are respectively increased by Δ/2 and Δ − Δ/2.
The line-ascent of the content is the maximum between:
TopShift + the line-ascent of the numerator's margin box.BottomShift + the line-ascent of the denominator's margin box.The line-descent of the content is the maximum between:
TopShift + the line-descent of the numerator's margin box.BottomShift + the line-descent of the denominator's margin box.The inline offsets of the numerator and denominator are calculated the same as in § 3.3.2.1 Fraction with nonzero line thickness.
The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of TopShift (respectively − BottomShift) towards the line-over (respectively line-under).
<msqrt>, <mroot>
The <msqrt> and <mroot> elements construct radicals. The <msqrt> element is used for square roots, while the <mroot> element is used to draw radicals with indices, e.g. a cube root.
The <msqrt> and <mroot> elements accept the attributes described in § 2.1.3 Global Attributes.
The following example contains a square root written with <msqrt> and a cube root written with <mroot>. Note that <msqrt> has several children and the square root applies to all of them. <mroot> has exactly two children: it is a root of index the second child (the number 3), applied to the the first child (the square root). Also note these elements only change the font-size within the <mroot> index, but it is scaled down more than within the numerator and denumerator of the fraction.
The <msqrt> and <mroot> elements sets math-shift to compact. The <mroot> element sets increments scriptleveldisplaystyle
If the <msqrt> or <mroot> element do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
If the <mroot> has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
Note
In practice, an
<mroot>
element has two children that are
in-flow. Hence the CSS rules basically performs
scriptleveland
displaystylechanges for the index.
The children of the <msqrt> element are laid out using the algorithm of the <mrow>
The radical symbol must only be painted if the visibility of the <msqrt> or <mroot> element is visible. In that case, the radical symbol must be painted with the color of that element.
The radical glyph is the glyph obtained for the character U+221A SQUARE ROOT.
The radical gap is given by RadicalVerticalGap if the math-style is compact and RadicalDisplayStyleVerticalGap if the math-style is normal.
The radical target size for the stretchy radical glyph is the sum of RadicalRuleThickness, radical gap and the ink height of the base.
The box metrics of the radical glyph and painting of the surd are given by the algorithm to shape a stretchy glyph to block dimension the target size for the radical glyph.
3.3.3.2 Square rootThe <msqrt> element is laid out as shown on Figure 14.
<msqrt> element
The min-content inline size (respectively max-content inline size) of the content is the sum of the preferred inline size of a glyph stretched along the block axis for the radical glyph and of the min-content inline size (respectively max-content inline size) of the base's margin box.
The inline size of the content is the sum of the advance width of the box metrics of the radical glyph and of the inline size of the base's margin's box.
The line-ascent of the content is the maximum between:
The line-descent of the content is the maximum between:
The inline size of the overbar is the inline size of the base's margin's box. The inline offsets of the base and overbar are also the same and equal to the width of the box metrics of the radical glyph.
The alphabetic baseline of the base is aligned with the alphabetic baseline. The block size of the overbar is RadicalRuleThickness. Its vertical center is shifted away from the alphabetic baseline by a distance towards the line-over equal to the line-ascent of the content, minus the RadicalExtraAscender, minus half the RadicalRuleThickness.
Finally, the painting of the surd is performed:
The <mroot> element is laid out as shown on Figure 15. The root index is first ignored and the base and radical glyph are laid out as shown on figure Figure 14 using the same algorithm as in § 3.3.3.2 Square root in order to produce a margin box B (represented in green).
<mroot> element
The min-content inline size (respectively max-content inline size) of the content is the sum of max(0, RadicalKernBeforeDegree), the index's min-content inline size (respectively max-content inline size) of the index's margin box, max(−min-content inline size, RadicalKernAfterDegree) (respectively max(−max-content inline size, RadicalKernAfterDegree)) and of the min-content inline size (respectively max-content inline size) of B.
Using the same clamping, AdjustedRadicalKernBeforeDegree and AdjustedRadicalKernAfterDegree are respectively defined as max(0, RadicalKernBeforeDegree) and is max(−inline size of the index's margin box, RadicalKernAfterDegree).
The inline size of the content is the sum of AdjustedRadicalKernBeforeDegree, the inline size of the index's margin box, AdjustedRadicalKernAfterDegree and of the inline size of B.
The line-ascent of the content is the maximum between:
The line-descent of the content is the maximum between:
The inline offset of the index is AdjustedRadicalKernBeforeDegree. The inline-offset of the base is the same + the inline size of the index's margin box.
The alphabetic baseline of B is aligned with the alphabetic baseline. The alphabetic baseline of the index is shifted away from the line-under edge by a distance of RadicalDegreeBottomRaisePercent × the block size of B + the line-descent of the index's margin box.
Note
In general, the kerning before the root index is positive while the kerning after it is negative, which means that the root element will have some inline-start space and that the root index will overlap the surd.
3.3.4 Style Change<mstyle>
Historically, the <mstyle> element was introduced to make style changes that affect the rendering of its contents.
The <mstyle> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mrow>
Note
<mstyle> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
In the following example, <mstyle> is used to set the scriptlevel and displaystyle. Observe this is respectively affecting the font-size and placement of subscripts of their descendants. In MathML Core, one could just have used <mrow> elements instead.
<merror>
The <merror> element displays its contents as an ”error message”. The intent of this element is to provide a standard way for programs that generate MathML from other input to report syntax errors in their input.
In the following example, <merror> is used to indicate a parsing error for some LaTeX-like input:
The <merror> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mrow>
<mpadded>
The <mpadded> element renders the same as its in-flow child content, but with the size and relative positioning point of its content modified according to <mpadded>’s attributes.
The <mpadded> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attributes:
The mpadded@width, mpadded@height, mpadded@depth, mpadded@lspace and mpadded@voffset if present, must have a value that is a valid length-percentage.
In the following example, <mpadded> is used to tweak spacing around a fraction (a blue background is used to visualize it). Without attributes, it behaves like an <mrow> but the attributes allow to specify the size of the box (width, height, depth) and position of the fraction within that box (lspace and voffset).
In-flow children of the <mpadded> element are laid out using the algorithm of the <mrow><mpadded> parameters are determined as follows:
width (respectively height, depth, lspace, voffset) attribute is absent, invalid or a length-percentage then the requested width (respectively height, depth, lspace, voffset) is the inner inline size (respectively inner line-ascent, inner line-descent, 0, 0).width attribute (respectively height, depth, lspace, voffset attributes). If one of the requested width, depth, height or lspace values is negative then it is treated as 0.Note
Negative voffset values are not clamped to 0.
<mpadded>
If the <mpadded> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, it is laid out as shown on Figure 16.
<mpadded> element
The min-content inline size (respectively max-content inline size) of the content is the requested width calculated in § 3.3.6.1 Inner box and requested parameters but using the min-content inline size (respectively max-content inline size) of the mpadded inner box instead of the "inner inline size".
The inline size of the content is the requested width calculated in § 3.3.6.1 Inner box and requested parameters.
The line-ascent of the content is the requested height. The line-descent of the content is the requested depth.
The mpadded inner box is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by the requested voffset towards the line-over.
3.3.7 Making Sub-Expressions Invisible<mphantom>
Historically, the <mphantom> element was introduced to render its content invisibly, but with the same metrics size and other dimensions, including alphabetic baseline position that its contents would have if they were rendered normally.
In the following example, <mphantom> is used to ensure alignment of corresponding parts of the numerator and denominator of a fraction:
The <mphantom> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mrow>
Note
<mphantom> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.
The elements described in this section position one or more scripts around a base. Attaching various kinds of scripts and embellishments to symbols is a very common notational device in mathematics. For purely visual layout, a single general-purpose element could suffice for positioning scripts and embellishments in any of the traditional script locations around a given base. However, in order to capture the abstract structure of common notation better, MathML provides several more specialized scripting elements.
In addition to sub/superscript elements, MathML has overscript and underscript elements that place scripts above and below the base. These elements can be used to place limits on large operators, or for placing accents and lines above or below the base.
3.4.1 Subscripts and Superscripts<msub>, <msup>, <msubsup>
The <msub>, <msup> and <msubsup> elements are used to attach subscript and superscript to a MathML expression. They accept the attributes described in § 2.1.3 Global Attributes.
The following example, shows basic use of subscripts and superscripts. The font-size is automatically scaled down within the scripts.
If the <msub>, <msup> or <msubsup> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
<msub>, <msup>, <msubsup>
If the <msub> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
If the <msup> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
If the <msubsup> element has less or more than three in-flow children, its layout algorithm is the same as the <mrow>
The <msub> element is laid out as shown on Figure 17. LargeOpItalicCorrection is the italic correction of the base if it is an embellished operator with the largeop
<msub> element
The min-content inline size (respectively max-content inline size) of the content is the min-content inline size (respectively max-content inline size) inline size of the base's margin box − LargeOpItalicCorrection + min-content inline size (respectively max-content inline size) of the subscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
The inline size of the content is the inline size of the base's margin box − LargeOpItalicCorrection + the inline size of the subscript's margin box + SpaceAfterScript.
SubShift is the maximum between:
The line-ascent of the content is the maximum between:
SubShift.The line-descent of the content is the maximum between:
SubShift.The inline offset of the base is 0 and the inline offset of the subscript is the inline size of the base's margin box − LargeOpItalicCorrection.
The base is placed so that its alphabetic baseline matches the alphabetic baseline. The subscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SubShift towards the line-under.
The <msup> element is laid out as shown on Figure 18. ItalicCorrection is the italic correction of the base if it is not an embellished operator with the largeop
<msup> element
The min-content inline size (respectively max-content inline size) of the content is the min-content inline size (respectively max-content inline size) of the base's margin box + ItalicCorrection + the min-content inline size (respectively max-content inline size) of the superscript's margin box + SpaceAfterScript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
The inline size of the content is the inline size of the base's margin box + ItalicCorrection + the inline size of the superscript's margin box + SpaceAfterScript.
SuperShift is the maximum between:
math-shift property equal to compact, or SuperscriptShiftUp otherwise.The line-ascent of the content is the maximum between:
SuperShift.The line-descent of the content is the maximum between:
SuperShift.The inline offset of the base is 0 and the inline offset of superscript is the inline size of the base's margin box + ItalicCorrection.
The base is placed so that its alphabetic baseline matches the alphabetic baseline. The superscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SuperShift towards the line-over.
The <msubsup> element is laid out as shown on Figure 18. LargeOpItalicCorrection and SubShift are set as in § 3.4.1.2 Base with subscript. ItalicCorrection and SuperShift are set as in § 3.4.1.3 Base with superscript.
<msubsup> element
The min-content inline size (respectively max-content inline size and inline size) of the content is the maximum between the min-content inline size (respectively max-content inline size and inline size) of the content calculated in § 3.4.1.2 Base with subscript and § 3.4.1.3 Base with superscript.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
If there is an inline stretch size constraint or a block stretch size constraint then the base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.
SubSuperGap is the gap between the two scripts along the block axis and is defined by (SubShift − the ink line-ascent of the subscript's margin box) + (SuperShift − the ink line-descent of the superscript's margin box). If SubSuperGap is not at least SubSuperscriptGapMin then the following steps are performed to ensure that the condition holds:
SuperShift − the ink line-descent of the superscript's margin box). If Δ > 0 then set Δ to the minimum between Δ set SubSuperscriptGapMin − SubSuperGap and increase SuperShift (and so SubSuperGap too) by Δ.SubSuperGap. If Δ > 0 then increase SubscriptShift (and so SubSuperGap too) by Δ.The ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the content is set to the maximum of the ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the content calculated in in § 3.4.1.2 Base with subscript and § 3.4.1.3 Base with superscript but using the adjusted values SubShift and SuperShift above.
The inline offset and block offset of the base and scripts are performed the same as described in § 3.4.1.2 Base with subscript and § 3.4.1.3 Base with superscript.
Note
Even when the subscript (respectively superscript) is an empty box, <msubsup> does not generally render the same as § 3.4.1.3 Base with superscript (respectively § 3.4.1.2 Base with subscript) because of the additional constraint on SubSuperGap. Moreover, positioning the empty subscript (respectively superscript) may also change the total size.
In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.
3.4.2 Underscripts and Overscripts<munder>, <mover>, <munderover>
The <munder>, <mover> and <munderover> elements are used to attach accents or limits placed under or over a MathML expression.
The <munderover> element accepts the attribute described in § 2.1.3 Global Attributes as well as the following attributes:
Similarly, the <mover> element (respectively <munder> element) accepts the attribute described in § 2.1.3 Global Attributes as well as the accentaccentunder
accent, accentunder, attributes, if present, must have values that are booleans. If these attributes are absent or invalid, they are treated as equal to false. User agents must implement them as described in § 3.4.4 Displaystyle, scriptlevel and math-shift in scripts.
The following example, shows basic use of under and over scripts. The font-size is automatically scaled down within the scripts, unless they are meant to be accents.
If the <munder>, <mover> or <munderover> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
<munder>, <mover>, <munderover>
If the <munder> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
If the <mover> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow>
If the <munderover> element has less or more than three in-flow children, its layout algorithm is the same as the <mrow>
If the <munder>, <mover> or <munderover> elements have a computed math-style property equal to compact and their base is an embellished operator with the movablelimits<msub>, <msup> and <msubsup> in § 3.4.1.2 Base with subscript, § 3.4.1.3 Base with superscript and § 3.4.1.4 Base with subscript and superscript.
Otherwise, the <mover>, <mover> and <munderover> layout algorithms are respectively described in § 3.4.2.3 Base with underscript, § 3.4.2.4 Base with overscript and § 3.4.2.5 Base with underscript and overscript
The algorithm for stretching operators along the inline axis is as follows.
LToStretch containing embellished operators with a stretchy property and inline stretch axis ; and a second list LNotToStretch.LNotToStretch. If LToStretch is empty then stop. If LNotToStretch is empty, perform layout with stretch size constraint 0 on all the items of LToStretch.T to the maximum inline size of the margin boxes of child boxes that have been laid out in the previous step.LToStretch with inline stretch size constraint T.The <munder> element is laid out as shown on Figure 20. LargeOpItalicCorrection is the italic correction of the base if it is an embellished operator with the largeop
<munder> element
The min-content inline size (respectively max-content inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the min-content inline size (respectively max-content inline size) of the base's margin box and underscript's margin box.
The in-flow children are laid out using the algorithm for stretching operators along the inline axis.
The inline size of the content is calculated by determining the absolute difference between:
LargeOpItalicCorrection.LargeOpItalicCorrection.If m is the minimum calculated in the second item above then the inline offset of the base is −m − half the inline size of the base's margin box. The inline offset of the underscript is −m − half the inline size of the underscript's margin box − half LargeOpItalicCorrection.
Parameters UnderShift and UnderExtraDescender are determined by considering three cases in the following order:
The base is an embellished operator with the largeopUnderShift is the maximum of
UnderExtraDescender is 0.
The base is an embellished operator with the stretchyUnderShift is the maximum of:
UnderExtraDescender is 0.UnderShift is equal to UnderbarVerticalGap if the accentunder attribute is not an ASCII case-insensitive match to true and to zero otherwise. UnderExtraAscender is UnderbarExtraDescender.The line-ascent of the content is the maximum between:
UnderShift.The line-descent of the content is the maximum between:
UnderShift + UnderExtraAscender.The alphabetic baseline of the base is aligned with the alphabetic baseline. The alphabetic baseline of the underscript is shifted away from the alphabetic baseline and towards the line-under by a distance equal to the ink line-descent of the base's margin box + UnderShift.
The <mover> element is laid out as shown on Figure 21. LargeOpItalicCorrection is the italic correction of the base if it is an embellished operator with the largeop
<mover> element
The min-content inline size (respectively max-content inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the base's margin box and underscript's margin box with the min-content inline size (respectively max-content inline size) of the base's margin box and underscript's margin box.
The in-flow children are laid out using the algorithm for stretching operators along the inline axis.
The TopAccentAttachment is the top accent attachment of the overscript or half the inline size of the overscript's margin box if it is undefined.
The inline size of the content is calculated by applying the algorithm for stretching operators along the inline axis for layout and determining the absolute difference between:
TopAccentAttachment + half LargeOpItalicCorrection.TopAccentAttachment + half LargeOpItalicCorrection.If m is the minimum calculated in the second item above then the inline offset of the base is −m − half the inline size of the base's margin. The inline offset of the overscript is −m − half the inline size of the overscript's margin box + half LargeOpItalicCorrection.
Parameters OverShift and OverExtraDescender are determined by considering three cases in the following order:
The base is an embellished operator with the largeopOverShift is the maximum of
OverExtraAscender is 0.
The base is an embellished operator with the stretchyOverShift is the maximum of:
OverExtraDescender is 0.Otherwise, OverShift is equal to
accent attribute is not an ASCII case-insensitive match to true.OverExtraAscender is OverbarExtraAscender.
Note
For accent overscripts and bases with
line-ascentsthat are at most
AccentBaseHeight, the rule from [
OPEN-FONT-FORMAT] [
TEXBOOK] is actually to align the
alphabetic baselinesof 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
AccentBaseHeightabove their
alphabetic baselines. Hence, the previous rule will guarantee that all the overscript bottoms are aligned while still avoiding collision with the bases. However, MathML can have arbitrary accent overscripts a more general and simpler rule is provided above: Ensure that the bottom of overscript is at least
AccentBaseHeightabove the
alphabetic baselineof the base.
The line-ascent of the content is the maximum between:
OverShift + OverExtraAscender.The line-descent of the content is the maximum between:
OverShift.The alphabetic baseline of the base is aligned with the alphabetic baseline. The alphabetic baseline of the overscript is shifted away from the alphabetic baseline and towards the line-over by a distance equal to the ink line-ascent of the base + OverShift.
The general layout of <munderover> is shown on Figure 22. The LargeOpItalicCorrection, UnderShift, UnderExtraDescender, OverShift, OverExtraDescender parameters are calculated the same as in § 3.4.2.3 Base with underscript and § 3.4.2.4 Base with overscript.
<munderover> element
The min-content inline size, max-content inline size and inline size of the content are calculated as an absolute difference between a maximum inline offset and minimum inline offset. These extrema are calculated by taking the extremum value of the corresponding extrema calculated in § 3.4.2.3 Base with underscript and § 3.4.2.4 Base with overscript. The inline offsets of the base, underscript and overscript are calculated as in these sections but using the new minimum m (minimum of the corresponding minima).
Like in these sections, the in-flow children are laid out using the algorithm for stretching operators along the inline axis.
The line-ascent and line-descent of the content are also calculated by taking the extremum value of the extrema calculated in § 3.4.2.3 Base with underscript and § 3.4.2.4 Base with overscript.
Finally, the alphabetic baselines of the base, undescript and overscript are calculated as in sections § 3.4.2.3 Base with underscript and § 3.4.2.4 Base with overscript.
Note
When the underscript (respectively overscript) is an empty box, the base and overscript (respectively underscript) are laid out similarly to § 3.4.2.4 Base with overscript (respectively § 3.4.2.3 Base with underscript) but the position of the empty underscript (respectively overscript) may add extra space. In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.
3.4.3 Prescripts and Tensor Indices<mmultiscripts>
Presubscripts and tensor notations are represented the <mmultiscripts> with hints given by the <mprescripts> (to distinguish postscripts and prescripts) and <none> elements (to indicate empty scripts). These element accept the attributes described in § 2.1.3 Global Attributes.
The following example, shows basic use of prescripts and postscripts, involving <none> and <mprescripts>. The font-size is automatically scaled down within the scripts.
If the <mmultiscripts>, <mprescripts> or <none> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.
The empty <mprescripts> and <none> elements are laid out as an <mrow>
A valid <mmultiscripts> element contains the following in-flow children:
<mprescripts><mprescripts><mprescripts><mprescripts>If an <mmultiscripts> element is not valid then it is laid out the same as the <mrow>
Note
The <none> element is preserved for backward compatibility reasons but is actually not taken into account in the layout algorithm.
The <mmultiscripts> element is laid out as shown on Figure 23. For each postscript pair, the ItalicCorrection LargeOpItalicCorrection are defined as in § 3.4.1.2 Base with subscript and § 3.4.1.3 Base with superscript.
<mmultiscripts> element
The min-content inline size (respectively max-content inline size) of the content is calculated the same as the inline size of the content below, but replacing "inline size" with "min-content inline size" (respectively "max-content inline size") for the base's margin box and scripts's margin boxes.
If there is an inline stretch size constraint or a block stretch size constraint the base is also laid out with the same stretch size constraint. Otherwise it is laid out without any stretch size constraint. The other elements are always laid out without any stretch size constraint.
The inline size of the content is calculated with the following algorithm:
inline-offset to 0.For each prescript pair, increment inline-offset by SpaceAfterScript + the maximum of
inline-offset by the inline size of the base's margin box and set inline-size to inline-offset.For each postscript pair, modify inline-size to be at least:
LargeOpItalicCorrection.ItalicCorrection.Increment inline-offset to the maximum of:
Increment inline-offset by SpaceAfterScript.
inline-sizeSubShift (respectively SuperShift) is calculated by taking the maximum of all subshifts (respectively supershifts) of each subscript/superscript pair as described in § 3.4.1.4 Base with subscript and superscript.
The line-ascent of the content is calculated by taking the maximum of all the line-ascent of each subscript/superscript pair as described in § 3.4.1.4 Base with subscript and superscript but using the SubShift and SuperShift values calculated above.
The line-descent of the content is calculated by taking the maximum of all the line-descent of each subscript/superscript pair as described in § 3.4.1.4 Base with subscript and superscript but using the SubShift and SuperShift values calculated above.
Finally, the placement of the in-flow children is performed using the following algorithm:
inline-offset to 0.For each prescript pair:
inline-offset by SpaceAfterScript.pair-inline-size to the maximum of
inline-offset + pair-inline-size − the inline size of the subscript's margin box.inline-offset + pair-inline-size − the inline size of the superscript's margin box.SubShift (respectively SuperShift) towards the line-under (respectively line-over).inline-offset by pair-inline-size.<mprescripts> boxes at inline offsets inline-offset and with their alphabetic baselines aligned with the alphabetic baseline.For each postscript pair:
pair-inline-size to the maximum of
inline-offset − LargeOpItalicCorrection.inline-offset + ItalicCorrection.SubShift (respectively SuperShift) towards the line-under (respectively line-over).inline-offset by pair-inline-sizeinline-offset by SpaceAfterScript.Note
An <mmultiscripts> with only one postscript pair is laid out the same as a <msubsup> with the same in-flow children. However, as noticed for <msubsup>, if additionally the subscript (respectively superscript) is an empty box then it is not necessarily laid out the same as an <msub> (respectively <msup>) element. In order to keep the algorithm simple, no attempt is made to handle empty or <none> scripts in a special way.
For all scripted elements, the rule of thumb is to set displaystylefalse and to increment scriptlevel<mover><munderover>accenttrue does not increment scriptlevel within its second child (respectively third child). Similarly, <mover><munderover>accentundertrue do not increment scriptlevel within their second child.
<mmultiscripts> sets math-shiftcompact on its children at even position if they are before an <mprescripts>, and on those at odd position if they are after an <mprescripts>. The <msub> and <msubsup> elements set math-shiftcompact on their second child. An <mover><munderover>accenttrue also sets math-shiftcompact within their first child.
The § A. User Agent Stylesheet must contain the following style in order to implement this behavior:
Note
In practice, all the children of the MathML elements described in this section are
in-flowand the
<mprescripts>
is empty. Hence the CSS rules essentially performs automatic
displaystyleand
scriptlevelchanges for the scripts ; and
math-shiftchanges for subscripts and sometimes the base.
3.5 Tabular MathMatrices, arrays and other table-like mathematical notation are marked up using <mtable><mtr><mtd><table>, <tr> and <td> elements of [HTML].
The following example, how tabular layout allows to write a matrix. Note that it is vertically centered with the fraction bar and the middle of the equal sign.
3.5.1 Table or Matrix<mtable>
The <mtable> is laid out as an inline-table and sets displaystyle to false. The user agent stylesheet must contain the following rules in order to implement these properties:
The mtable element is as a CSS table and the min-content inline size, max-content inline size, inline size, block size, first baseline set and last baseline set sets are determined accordingly. The center of the table is aligned with the math axis.
<mtr>
The <mtr> is laid out as table-row. The user agent stylesheet must contain the following rules in order to implement that behavior:
The <mtr> accepts the attributes described in § 2.1.3 Global Attributes.
<mtd>
The <mtd> is laid out as a table-cell with content centered in the cell and a default padding. The user agent stylesheet must contain the following rules:
The <mtd> accepts the attributes described in § 2.1.3 Global Attributes as well as the following attributes:
The columnspan (respectively rowspan) attribute has the same syntax and semantic as the colspan (respectively rowspan) attribute on the <td> element from [HTML].
Note
The name for the column spanning attribute is
columnspan
as in [
MathML3] and not
colspan
as in [
HTML].
3.6 Enlivening ExpressionsHistorically, the <maction> element provides a mechanism for binding actions to expressions.
The <maction> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attributes:
This specification does not define any observable behavior that is specific to the actiontype and selection attributes.
The following example, shows the "toggle" action type from [MathML3] where the renderer alternately displays the selected subexpression, starting from "one third" and cycling through them when there is a click on the selected subexpression ("one quarter", "one half", "one third", etc). This is not part of MathML Core but can be implemented using JavaScript and CSS polyfills. The default behavior is just to render the first child.
The layout algorithm of the <maction> element the same as the <mrow> element. The user agent stylesheet must contain the following rules in order to hide all but its first child element, which is the default behavior for the legacy actiontype values:
Note
<maction>
is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use other HTML, CSS and JavaScript mechanisms to implement custom actions. They may rely on maction attributes defined in [
MathML3].
3.7 Semantics and PresentationThe <semantics> element is the container element that associates annotations with a MathML expression. Typically, the <semantics> element has as its first child element a MathML expression to be annotated while subsequent child elements represent text annotations within an <annotation> element, or more complex markup annotations within an <annotation-xml> element.
The following example, shows how the fraction "one half" can be annotated with a textual annotation (LaTeX) or an XML annotation (content MathML). These annotations are not intended to be rendered by the user agent.
The <semantics> element accepts the attributes described in § 2.1.3 Global Attributes. Its layout algorithm is the same as the <mrow>
The <annotation-xml> and <annotation> element accepts the attributes described in § 2.1.3 Global Attributes as well as the following attribute:
This specification does not define any observable behavior that is specific to the encoding attribute.
The layout algorithm of the <annotation-xml> and <annotation> element is the same as the <mtext>
Note
Authors can use the
encodingattribute to distinguish annotations for
HTML integration point, clipboard copy, alternative rendering, etc. In particular, CSS can be used to render alternative annotations e.g.
semantics > :first-child { display: none; }
semantics > annotation { display: inline; }
semantics > annotation-xml[encoding="text/html" i],
semantics > annotation-xml[encoding="application/xhtml+xml" i] {
display: inline-block;
}display: block math and display: inline math value
The display property from CSS Display Module Level 3 is extended with a new inner display type:
<display> = <display-inside-old> | math
For elements that are not MathML elements, if the specified value of display is inline math or block math then the computed value is block flow and inline flow respectively. For the <mtable>block table and inline table respectively. For the <mtr>table-row. For the <mtd>table-cell.
MathML elements with a computed display value equal to block math or inline math control box generation and layout according to their tag name, as described in the relevant sections. Unknown MathML elements behave the same as the <mrow>
Note
The
display: block math
and
display: inline math
values provide a default layout for MathML elements while at the same time allowing to override it with either native display values or
custom values. This allows authors or polyfills to define their own custom notations to tweak or extend MathML Core.
In the following example, the default layout of the MathML <mrow> element is overriden to render its content as a grid.
text-transform values
The text-transform property from CSS Text Module Level 3 is extended with new values:
<text-transform> = <text-transform-old> | math-auto | math-bold | math-italic | math-bold-italic | math-double-struck | math-bold-fraktur | math-script | math-bold-script | math-fraktur | math-sans-serif | math-bold-sans-serif | math-sans-serif-italic | math-sans-serif-bold-italic | math-monospace | math-initial | math-tailed | math-looped | math-stretched
If the specified value of text-transform is math-auto and the inherited value is not none then the computed value is the inherited value.
On text nodes containing a unique character, math-auto has the same effect as math-italic, otherwise it has no effects.
For the math-bold, math-italic, math-bold-italic, math-double-struck, math-bold-fraktur, math-script, math-bold-script, math-fraktur, math-sans-serif, math-bold-sans-serif, math-sans-serif-italic, math-sans-serif-bold-italic, math-monospace, math-initial, math-tailed, math-looped and math-stretched values, the transformed text is obtained by performing conversion of each character according to the corresponding bold, italic, bold-italic, double-struck, bold-fraktur, script, bold-script, fraktur, sans-serif, bold-sans-serif, sans-serif-italic, sans-serif-bold-italic, monospace, initial, tailed, looped, stretched tables.
User agents may decide to rely on italic, bold and bold-italic font-level properties when available fonts lack the proper glyphs to perform math-auto, math-italic, math-bold, math-bold-italic character-level transforms.
The following example shows a mathematical formula where "exp" is rendered with normal variant, "A" with bold variant, "gl" with fraktur variant, "n" using italic variant and and "R" using double-struck variant.
Values other than math-auto are intended to infer specific context-dependent mathematical meaning. In the previous example, one can guess that the author decided to use the convention of bold variables for matrices, fraktur variables for Lie algebras and double-struck variables for set of numbers. Although the corresponding Unicode characters could have been used directly in these cases, it may be helpful for authoring tools or polyfills to support these transformations via the text-transform property.
A common style convention is to render identifiers with multiple letters (e.g. the function name "exp") with normal style and identifiers with a single letter (e.g. the variable "n") with italic style. The math-auto property is intended to implement this default behavior, which can be overriden by authors if necessary. Note that mathematical fonts are designed with special kind of italic glyphs located at the Unicode positions of § C.13 italic mappings, which differ from the shaping obtained via italic font style. Compare this mathematical formula rendered with the Latin Modern Math font using font-style: italic (left) and text-transform: math-auto (right):
math-style property Name: math-style Value: normal | compact Initial: normal Applies to: All elements Inherited: yes Percentages: n/a Media: visual Computed value: specified keyword Canonical order: n/a Animation type: not animatable
When math-style is compact, the math layout on descendants try to minimize the logical height by applying the following rules:
font-sizemath and the computed value of math-depthauto-add (default for <mfrac>) as described in § 4.5 New value math-depth property and font-size: math value.largeop property do not follow rules from § 3.2.4.3 Layout of operators to make them bigger.movablelimits property are actually drawn as sub/super scripts as described in § 3.4.2.1 Children of <munder>, <mover>, <munderover>.The following example shows a mathematical formula renderered with its <math>math-style: compact (left) and math-style: normal (right). In the former case, the font-size is automatically scaled down within the fractions and the summation limits are rendered as subscript and superscript of the ∑. In the latter case, the ∑ is drawn bigger than normal text and vertical gaps within fractions (even relative to current font-size) is larger.
These two math-style values typically correspond to mathematical expressions in inline and display mode respectively [TeXBook]. A mathematical formula in display mode may automatically switch to inline mode within some subformulas (e.g. scripts, matrix elements, numerators and denominators, etc) and it is sometimes desirable to override this default behavior. The math-style property allows to easily implement these features for MathML in the User Agent Stylesheet and with the displaystyle attribute ; and also exposes them to polyfills.
math-shift property Name: math-shift Value: normal | compact Initial: normal Applies to: All elements Inherited: yes Percentages: n/a Media: visual Computed value: specified keyword Canonical order: n/a Animation type: not animatable
If the value of math-shift is compact, the math layout on descendants will use the superscriptShiftUpCramped parameter to place superscript. If the value of math-shift is normal, the math will use the superscriptShiftUp parameter instead.
This property is used for positioning superscript during the layout of MathML scripted elements. See § § 3.4.1 Subscripts and Superscripts <msub>, <msup>, <msubsup> § 3.4.3 Prescripts and Tensor Indices <mmultiscripts> and § 3.4.2 Underscripts and Overscripts <munder>, <mover>, <munderover>.
In the following example, the two "x squared" are rendered with compact math-style and the same font-size. However, the one within the square root is rendered with compact math-shift while the other one is rendered with normal math-shift, leading to subtle different shift of the superscript "2".
Per [TeXBook], a mathematical formula uses normal style by default but may switch to compact style ("cramped" in TeX's terminology) within some subformulas (e.g. radicals, fraction denominators, etc). The math-shift property allows to easily implement these rules for MathML in the User Agent Stylesheet. Page authors or developers of polyfills may also benefit from having access to this property to tweak or refine the default implementation.
math-depth property and font-size: math value
The font-size property from CSS Fonts Module Level 4 is extended with a new value math value, indicating that special mathematical scaling rules must be applied when determining the computed value of the font-size property:
<font-size> = <font-size-old> | math
A new math-depth property is introduced to describe a notion of "depth" for each element of a mathematical formula, with respect to the top-level container of that formula. Concretely, this is used to determine the computed value of the font-size property when its specified value is math.
math-depth Value: auto-add | add(<integer>) | <integer> Initial: 0 Applies to: All elements Inherited: yes Percentages: n/a Media: visual Computed value: an integer, see below Canonical order: n/a Animation type: not animatable
The computed value of the math-depth value is determined as follows:
math-depth is auto-add and the inherited value of math-style is compact then the computed value of math-depth of the element is its inherited value plus one.math-depth is of the form add(<integer>) then the computed value of math-depth of the element is its inherited value plus the specified integer.math-depth is of the form <integer> then the computed value of math-depth of the element is the specified integer.math-depth of the element is the inherited one.If the specified value font-size is math then the computed value of font-size is obtained by multiplying the inherited value of font-size by a nonzero scale factor calculated by the following procedure:
math-depth value, B the computed math-depth value, C be 0.71 and S be 1.0InvertScaleFactor to true.InvertScaleFactor to false.InvertScaleFactor is false and 1/S otherwise.The following example shows a mathematical formula with normal math-style rendered with the Latin Modern Math font. When entering subexpressions like scripts or fractions, the font-size is automatically scaled down according to the values of MATH table contained in that font. Note that font-size is scaled down when entering the superscripts but even faster when entering a root's prescript. Also it is scaled down when entering the inner fraction but not when entering the outer one, due to automatic change of math-style in fractions.
These rules from [TeXBook] are subtle and it's worth having a separate math-depth mechanism to express and handle them. They can be implemented in MathML using the User Agent Stylesheet. Page authors or developers of polyfills may also benefit from having access to this property to tweak or refine the default implementation. In particular, the scriptlevel attribute from MathML provides a way to perform math-depth changes.
MATH table
This chapter describes features provided by MATH table of an OpenType font [OPEN-FONT-FORMAT]. Throughout this chapter, a C-like notation Table.Subtable1[index].Subtable2.Parameter is used to denote OpenType parameters. Such parameters may not be available (e.g. if the font lack one of the subtable, has an invalid offset, etc) and so fallback options are provided.
Note
It is strongly encouraged to render MathML with a math font with the proper OpenType features. There is no guarantee that the fallback options provided will provide good enough rendering.
OpenType values expressed in design units (perhaps indirectly via a MathValueRecord entry) are scaled to appropriate values for layout purpose, taking into account head.unitsPerEm, CSS font-size
MathConstants)
These are global layout constants for the first available font:
post.underlineThickness or Default fallback constant if the constant is not available.
MATH.MathConstants.scriptPercentScaleDown / 100 or 0.71 if MATH.MathConstants.scriptPercentScaleDown is null or not available.
MATH.MathConstants.scriptScriptPercentScaleDown / 100 or 0.5041 if MATH.MathConstants.scriptScriptPercentScaleDown is null or not available.
MATH.MathConstants.displayOperatorMinHeight or Default fallback constant if the constant is not available.
MATH.MathConstants.axisHeight or half OS/2.sxHeight if the constant is not available.
MATH.MathConstants.accentBaseHeight or OS/2.sxHeight if the constant is not available.
MATH.MathConstants.subscriptShiftDown or OS/2.ySubscriptYOffset if the constant is not available.
MATH.MathConstants.subscriptTopMax or ⅘ × OS/2.sxHeight if the constant is not available.
MATH.MathConstants.subscriptBaselineDropMin or Default fallback constant if the constant is not available.
MATH.MathConstants.superscriptShiftUp or OS/2.ySuperscriptYOffset if the constant is not available.
MATH.MathConstants.superscriptShiftUpCramped or Default fallback constant if the constant is not available.
MATH.MathConstants.superscriptBottomMin or ¼ × OS/2.sxHeight if the constant is not available.
MATH.MathConstants.superscriptBaselineDropMax or Default fallback constant if the constant is not available.
MATH.MathConstants.subSuperscriptGapMin or 4 × default rule thickness if the constant is not available.
MATH.MathConstants.superscriptBottomMaxWithSubscript or ⅘ × OS/2.sxHeight if the constant is not available.
MATH.MathConstants.spaceAfterScript or 1/24em if the constant is not available.
MATH.MathConstants.upperLimitGapMin or Default fallback constant if the constant is not available.
MATH.MathConstants.upperLimitBaselineRiseMin or Default fallback constant if the constant is not available.
MATH.MathConstants.lowerLimitGapMin or Default fallback constant if the constant is not available.
MATH.MathConstants.lowerLimitBaselineDropMin or Default fallback constant if the constant is not available.
MATH.MathConstants.stackTopShiftUp or Default fallback constant if the constant is not available.
MATH.MathConstants.stackTopDisplayStyleShiftUp or Default fallback constant if the constant is not available.
MATH.MathConstants.stackBottomShiftDown or Default fallback constant if the constant is not available.
MATH.MathConstants.stackBottomDisplayStyleShiftDown or Default fallback constant if the constant is not available.
MATH.MathConstants.stackGapMin or 3 × default rule thickness if the constant is not available.
MATH.MathConstants.stackDisplayStyleGapMin or 7 × default rule thickness if the constant is not available.
MATH.MathConstants.stretchStackTopShiftUp or Default fallback constant if the constant is not available.
MATH.MathConstants.stretchStackBottomShiftDown or Default fallback constant if the constant is not available.
MATH.MathConstants.stretchStackGapAboveMin or Default fallback constant if the constant is not available.
MATH.MathConstants.stretchStackGapBelowMin or Default fallback constant if the constant is not available.
MATH.MathConstants.fractionNumeratorShiftUp or Default fallback constant if the constant is not available.
MATH.MathConstants.fractionNumeratorDisplayStyleShiftUp or Default fallback constant if the constant is not available.
MATH.MathConstants.fractionDenominatorShiftDown or Default fallback constant if the constant is not available.
MATH.MathConstants.fractionDenominatorDisplayStyleShiftDown or Default fallback constant if the constant is not available.
MATH.MathConstants.fractionNumeratorGapMin or default rule thickness if the constant is not available.
MATH.MathConstants.fractionNumDisplayStyleGapMin or 3 × default rule thickness if the constant is not available.
MATH.MathConstants.fractionRuleThickness or default rule thickness if the constant is not available.
MATH.MathConstants.fractionDenominatorGapMin or default rule thickness if the constant is not available.
MATH.MathConstants.fractionDenomDisplayStyleGapMin or 3 × default rule thickness if the constant is not available.
MATH.MathConstants.overbarVerticalGap or 3 × default rule thickness if the constant is not available.
MATH.MathConstants.overbarRuleThickness or default rule thickness if the constant is not available.
MATH.MathConstants.overbarExtraAscender or default rule thickness if the constant is not available.
MATH.MathConstants.underbarVerticalGap or 3 × default rule thickness if the constant is not available.
MATH.MathConstants.underbarRuleThickness or default rule thickness if the constant is not available.
MATH.MathConstants.underbarExtraDescender or default rule thickness if the constant is not available.
MATH.MathConstants.radicalVerticalGap or 1¼ × default rule thickness if the constant is not available.
MATH.MathConstants.radicalDisplayStyleVerticalGap or default rule thickness + ¼ OS/2.sxHeight if the constant is not available.
MATH.MathConstants.radicalRuleThickness or default rule thickness if the constant is not available.
MATH.MathConstants.radicalExtraAscender or default rule thickness if the constant is not available.
MATH.MathConstants.radicalKernBeforeDegree or 5/18em if the constant is not available.
MATH.MathConstants.radicalKernAfterDegree or −10/18em if the constant is not available.
MATH.MathConstants.radicalDegreeBottomRaisePercent / 100.0 or 0.6 if the constant is not available.
MathGlyphInfo)
Note
MathTopAccentAttachment is at risk.
These are per-glyph tables for the first available font:
MATH.MathGlyphInfo.MathItalicsCorrectionInfo of italics correction values. Use the corresponding value in MATH.MathGlyphInfo.MathItalicsCorrectionInfo.italicsCorrection if there is one for the requested glyph or or 0 otherwise.
MATH.MathGlyphInfo.MathTopAccentAttachment of positioning top math accents along the inline axis. Use the corresponding value in MATH.MathGlyphInfo.MathTopAccentAttachment.topAccentAttachment if there is one for the requested glyph or or half the advance width of the glyph otherwise.
MathVariants)
This section describes how to handle stretchy glyphs of arbitrary size using the MATH.MathVariants table.
GlyphAssembly table
This section is based on [OPEN-TYPE-MATH-IN-HARFBUZZ]. For convenience, the following definitions are used:
MATH.MathVariant.minConnectorOverlap.GlyphPartRecord is an extender if and only if GlyphPartRecord.partFlags has the fExtender flag set.GlyphAssembly is horizontal if it is obtained from MathVariant.horizGlyphConstructionOffsets. Otherwise it is vertical (and obtained from MathVariant.vertGlyphConstructionOffsets).GlyphAssembly table, NExt (respectively NNonExt) is the number of extenders (respectively non-extenders) in GlyphAssembly.partRecords.GlyphAssembly table, SExt (respectively SNonExt) is the sum of GlyphPartRecord.fullAdvance for all extenders (respectively non-extenders) in GlyphAssembly.partRecords.User agents must treat the GlyphAssembly as invalid if the following conditions are not satisfied:
GlyphPartRecord in GlyphAssembly.partRecords, the values of GlyphPartRecord.startConnectorLength and GlyphPartRecord.endConnectorLength must be at least omin. Otherwise, it is not possible to satisfy the condition of MathVariant.minConnectorOverlap.In this specification, a glyph assembly is built by repeating each extender r times and using the same overlap value o between each glyph. The number of glyphs in such an assembly is AssemblyGlyphCount(r) = NNonExt + r NExt while the stretch size is AssembySize(o, r) = SNonExt + r SExt − o (AssemblyGlyphCount(r) − 1).
rmin is the minimal number of repetitions needed to obtain an assembly of size at least T i.e. the minimal r such that AssembySize(omin, r)) ≥ T. It is defined as the maximum between 0 and the ceiling of ((T − SNonExt + omin (NNonExt − 1)) / SExt,NonOverlapping).
omax is the maximum overlap possible to build an assembly of size at least T by repeating each extender rmin times. If AssemblyGlyphCount(rmin) ≤ 1, then the actual overlap value is irrelevant. Otherwise, omax is defined to be the minimum of:
GlyphPartRecord.startConnectorLength for all the entries in GlyphAssembly.partRecords, excluding the last one if it is not an extender.GlyphPartRecord.endConnectorLength for all the entries in GlyphAssembly.partRecords, excluding the first one if it is not an extender.The glyph assembly stretch size for a target size T is AssembySize(omax, rmin).
The glyph assembly width, glyph assembly ascent and glyph assembly descent are defined as follows:
GlyphAssembly is vertical, the width is the maximum advance width of the glyphs of id GlyphPartRecord.glyphID for all the GlyphPartRecord in GlyphAssembly.partRecords, the ascent is the glyph assembly stretch size for a given target size T and the descent is 0.GlyphAssembly is horizontal, the width is glyph assembly stretch size for a given target size T while the ascent (respectively descent) is the the maximum ascent (respectively descent) of the glyphs of id GlyphPartRecord.glyphID for all the GlyphPartRecord in GlyphAssembly.partRecords.The glyph assembly height is the sum of the glyph assembly ascent and glyph assembly descent.
Note
The horizontal (respectively vertical) metrics for a vertical (respectively horizontal) glyph assembly do not depend on the target size T.
The shaping of the glyph assembly is performed with the following algorithm:
(x, y) to (0, 0), RepetitionCounter to 0 and PartIndex to -1.RepetitionCounter is 0, then
PartIndex.PartIndex is GlyphAssembly.partCount then stop.Part to GlyphAssembly.partRecords[PartIndex]. Set RepetitionCounter to rmin if Part is an extender and to 1 otherwise.Part.glyphID so that its (left, baseline) coordinates are at position (x, y). Set x to x + Part.fullAdvance − omaxPart.glyphID so that its (left, bottom) coordinates are at position (x, y). Set y to y − Part.fullAdvance + omaxRepetitionCounter.The preferred inline size of a glyph stretched along the block axis is calculated using the following algorithm:
S to the glyph's advance width.MathGlyphConstruction table in the MathVariants.vertGlyphConstructionOffsets table for the given glyph:
MathGlyphVariantRecord in MathGlyphConstruction.mathGlyphVariantRecord, ensure that S is at least the advance width of the glyph of id MathGlyphVariantRecord.variantGlyph.GlyphAssembly subtable, then ensure that S is at least the glyph assembly width.S.The algorithm to shape a stretchy glyph to inline (respectively block) dimension T is the following:
MathGlyphConstruction table in the MathVariants.horizGlyphConstructionOffsets table (respectively MathVariants.vertGlyphConstructionOffsets table) for the given glyph the exit with failure.T then use normal shaping and bounding box for that glyph, the MathItalicsCorrectionInfo for that glyph as italic correction and exit with success.MathGlyphVariantRecord in MathGlyphConstruction.mathGlyphVariantRecord. If one MathGlyphVariantRecord.advanceMeasurement is at least T then use normal shaping and bounding box for MathGlyphVariantRecord.variantGlyph, the MathItalicsCorrectionInfo for that glyph as italic correction and exit with success.GlyphAssembly subtable then use the bounding box given by glyph assembly width, glyph assembly ascent, the value GlyphAssembly.italicsCorrection as italic correction, perform shaping of the glyph assembly and exit with success.T, then choose last one that was tried and exit with success.Note
If a font does not provide tables for stretchy constructions, User Agents may use their own internal constructions as a fallback such that the one suggested in
§ B.5 Unicode-based Glyph Assemblies.
A. User Agent Stylesheet@namespace url(http://www.w3.org/1998/Math/MathML);
The following dictionary for default values of § 3.2.4.2 Dictionary-based attributes of operators when they are not specified via explicit attributes or equal to the generic default values. Please refer to § 3.2.4.2 Dictionary-based attributes for explanation about how to use this dictionary and how to determine the values Content and Form indexing it. Tables below are suitable for computer manipulation, see § B.3 Operator Dictionary (human-readable) for an alternative presentation.
This compact form removes about 800 entries from the original operator dictionary that actually correspond to default values. They are not necessary since they are handled by the fallback case of § 3.2.4.2 Dictionary-based attributes anyway. For other (Content, Form) key, the search is done as follows:
stretchy, symmetric largeop, movablelimits to false.Content as an UTF-16 string does not have length or 1 or 2 then exit with NotFound status.Content is a single character in the range U+0320–U+03FF then exit with NotFound status. Otherwise, if it has two characters:
Content is the surrogate pairs corresponding to U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL or U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL and Form is postfix, then set properties according to category I of #operator-dictionary-categories-values and move to the last step.Content with the first character.Content it is listed in Operators_2_ascii_chars then replace Content with the Unicode character "U+0320 plus the index of Content in Operators_2_ascii_chars".NotFound status.Content, Form) from #operator-dictionary-category-table and either exit with NotFound status or and move to the next point. More precisely, this can be done as follows:
Content, Form) according to #operator-dictionary-category-table. If a result is found then set the properties according to #operator-dictionary-categories-values. Otherwise exit with NotFound status.Key to Content if it is in range U+0000–U+03FF ; or to Content − 0x1C00 if it is in range U+2000–U+2BFF. Otherwise, exit with NotFound status. Key is at most 0x0FFF.Key according to whether Form is infix, prefix, postfix respectively. Key is at most 0x2FFF.Entry in table #operator-dictionary-categories-hexa-table such Entry % 0x4000 is equal to Key. Either exit with NotFound status or set the properties corresponding to the category with encoding Entry / 0x1000 in #operator-dictionary-categories-values.lspace, rspace, stretchy, symmetric largeop, movablelimits) value.Note
When encoded as ranges, one can perform a binary search by looking for the range start, followed by an extra check on the range length. Since log is concave, it is worse to do one binary search on each large subtable of #operator-dictionary-category-table than one binary search on the whole table of #operator-dictionary-categories-hexa-table. One can see that there are several contiguous Unicode blocks, so encoding tables as ranges allow to get almost 8 bits per entry.
Alternatively, it is possible to use a perfect hash function to implement table lookup in constant time [gperf] [CMPH]. This would instead take 16 bits per entry, plus 16 bits per extra empty entry (for non-minimal perfect hash function) as well as extra data to store the hash function parameters. For minimal perfect hash function, the theorical lower bound for storing these parameters is 1.44bits/entry and existing algorithms range from close to that limit up to 4bits/entry.
B.2 Stretchy Operator AxisThe default stretch axis for all characters is block. However, the stretch axis for the following characters is inline:
Note
The stretch axis can be included as a boolean property of the
operator dictionary. But since it does not depend on the form and since very few operators can stretch along the
inline axis, it might be better implemented as a separate sorted array.
B.3 Operator Dictionary (human-readable)This section is non-normative.
The following dictionary provides a human-readable version of § B.1 Operator Dictionary. Please refer to § 3.2.4.2 Dictionary-based attributes for explanation about how to use this dictionary and how to determine the values Content and Form indexing together the dictionary.
The values for rspace and lspace are indicated in the corresponding columns. The values of stretchysymmetriclargeopmovablelimitstrue if they are listed in the "properties" column.
This section is non-normative.
The following table gives mappings between spacing and non spacing characters when used in MathML accent constructs.
B.5 Unicode-based Glyph AssembliesThis section is non-normative.
The following table provide fallback that user agents may use for stretching a given base character when the font does not provide a MATH.MathVariants table. The algorithms of § 5.3 Size variants for operators (MathVariants) works the same except with some adjustments:
MathVariants.horizGlyphConstructionOffsets[] item ; if it is vertical it corresponds to a MathVariants.vertGlyphConstructionOffsets[] item.MathGlyphConstruction.mathGlyphVariantRecord is always empty.MathVariants.minConnectorOverlap, GlyphPartRecord.startConnectorLength and GlyphPartRecord.endConnectorLength are treated as 0.MathGlyphConstruction.GlyphAssembly.partRecords is built from each table row as follows:
text-transform Mappings C.1 bold-script mappings C.2 bold-italic mappings C.3 tailed mappings C.4 bold mappings C.5 fraktur mappings C.6 script mappings C.7 monospace mappings C.8 initial mappings C.9 sans-serif mappings C.10 double-struck mappings C.11 looped mappings C.12 stretched mappings C.13 italic mappings C.14 bold-fraktur mappings C.15 sans-serif-bold-italic mappings C.16 sans-serif-italic mappings C.17 bold-sans-serif mappings D. Acknowledgments
This section is non-normative.
MathML Core is based on MathML3. See the appendix E of [MathML3] for the people that contributed to that specification.
We would like to thank the people who, through their input and feedback on public communication channels have helped us with the creation of this specification: André Greiner-Petter, Anne van Kesteren, Boris Zbarsky, Brian Smith, Daniel Marques, David Carlisle, Deyan Ginev, Elika Etemad, Emilio Cobos Álvarez, ExE Boss, Ian Kilpatrick, Koji Ishii, L. David Baron, Michael Kohlhase, Michael Smith, Moritz Schubotz, Murray Sargent, Ryosuke Niwa, Sergey Malkin, Tab Atkins Jr., Viktor Yaffle and frankvel.
In addition, we would like to extend special thanks to Brian Kardell, Neil Soiffer and Rob Buis for help with the editing.
Many thanks also to the following people for their help with the test suite: Brian Kardell, Frédéric Wang, Neil Soiffer and Rob Buis. Several tests are also based on MathML tests from browser repositories and we are grateful to the Mozilla and WebKit contributors.
Community Group members who have regularly participated to MathML Core meetings during the development of this specification: Brian Kardell, Bruce Miller, David Carlisle, Murray Sargent, Frédéric Wang, Neil Soiffer (Chair), Patrick Ion, Rob Buis, David Farmer, Steve Noble, Daniel Marques, Sam Dooley.
E. Privacy and Security ConsiderationsThis section is non-normative.
As explained in § 2.2.1 HTML and SVG, MathML can be embedded into an SVG image via the <foreignObject> element which can thus be used in a <canvas> element. UA may decide to implement any measure to prevent potential information leakage such as tainting the canvas and returning a "SecurityError" DOMException when one tries to access the canvas' content via JavaScript APIs.
This specification only adds script execution mechanisms in the the MathML event handler attributes described in § 2.1.3 Global Attributes. UAs may decide to apply the same security restrictions as HTML and SVG to prevent execution of scripts in these attributes.
This specification describes layout of a DOM elements which may involve system fonts. Like for HTML/CSS layout, it is thus possible to use JavaScript APIs to measure box sizes and positions and infer data from system fonts (e.g. default fonts, available glyphs, font layout parameters...). The only font informations that are not exposed by other existing Web APIs are the math layout data described in § 5. OpenType MATH table.
Note
In MathML3, it was possible to use the
<maction>element with the
actiontype
value set to
"statusline"
in order to override the text of the browser statusline. In particular, this could be used to hide the URL text of an untrusted link. This has been removed in MathML Core and the
<maction>element essentially behaves like an
<mrow>container with extra style.
F. ConformanceAs well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Conformance F.1 Document conventionsConformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119].
Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:
Note
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4