2 Relation with other technologies
2.1 HTML5 Tree
2.1.1 DOM, HTML, SVG and Javascript
User agents must use a HTML5 [HTML5] parser to build a DOM tree [DOM1] from the source code of web pages. In particular, they must follow the rules describing when elements must be in the MathML namespace http://www.w3.org/1998/Math/MathML and must recognize the entity definitions from the HTML MathML entity set of [XMLEntities]. They must also take into account the following integration points between SVG, MathML and HTML as allowed by [ValidatorSchemas]:

1.
The $$ element can be used at any position permitted for phrasing content or inside SVG
elements. 
2.
The element can be used inside
elements with encoding SVG1.1 or image/svg+xml. 
3.
The element and flow content can be used inside
elements with encoding application/xhtml+xml or text/html. 
4.
Any phrasing element can be used inside
elements.
From this DOM tree, user agents must provide a visual representation of the document. The DOM tree may be dynamically modified using Javascript [ECMA262] and the user agents must keep the visual representation in synchronization with the DOM tree.
2.1.2 MathML
All MathML elements accept the id, class and style attributes [MathML3]. They must be interpreted as described in section 3.2.5 of the HTML5 specification [HTML5] and in particular they specify a unique identifier (to identify elements in links and scripting), affect CSS selectors, affect getElementsByClassName() and enable authors to do inline styling.
MathML 3 allows to use the href attribute on any MathML element [MathML3]. In the present document, it is only required to implement href on the mrow element with the behavior described in 4.8 of the HTML5 specification for the a element [HTML5]. It is recommended to make links visually distinguisable by default, for example by adding a rule in the user agent stylesheet (section 2.3.2) such as
mrow[href] { 
color: blue; 
} 
The toplevel math element accepts the altimg, altimgwidth, altimgheight, altimgvalign and alttext attributes. These attributes allow to specify fallback content and may just be ignored. User agents that do not fully implement this document may decide to render this fallback content in some situations e.g. when they are specified or under a preference option. In that case, an approximate implementation is to render the math element as a HTML img element with the value of altimg as an src attribute, the value of alttext as an alt attribute, the value of altimgwidth as the CSS width property, the value of altimgheight as the CSS height property and the value of altimgvalign as the CSS verticalalign property [HTML5] [CSS2]. Here is a partial implementation using the attr() function of [CSS3Values]:
math { 
display: inline; 
} 
math[display="block"] { 
display: block; 
textalign: center; 
} 
math { 
backgroundimage: attr(altimg url); 
width: attr(altimgwidth length); 
height: attr(altimgheight length); 
verticalalign: attr(altimgvalign length); 
} 
math > * { 
display: none; 
} 
The toplevel math element also accepts the display attribute, mathcolor, mathbackground attributes as well as other attributes from the mstyle element. These attributes must be supported and this may be achieved using specific rules in the user agent stylesheet as described in section 2.3.2.
In general MathML elements or attributes that are not mentioned in this document may just be ignored. This includes deprecated attributes or Content Markup described in chapter 4 of the MathML 3 specification [MathML3].
User agents must contain an operator dictionary describing the default properties of operators. For interoperability, it is recommended to use the one proposed in the nonnormative Appendix C of [MathML3].
2.2 Text and Math layout
2.2.1 Open Font Format
Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. This behavior is specified in math fonts using the USE_TYPO_METRICS flag from the OS/2 table [OpenFontFormat3] and user agents must honor that flag.
Mathematical formulas can be viewed as an extension of standard text layout and thus user agents must be able to perfom complex text layout [CTL] using fonts under the Open Font Format [OpenFontFormat3]. In particular, they must implement bidirectional rendering and shaping of Arabic scripts.
Mathematical formulas may mix standard text with other graphical outlines (e.g. fraction or top radical bars). For consistency, these outlines should be rendered the same way as normal text. In particular, user agents must be able to apply visibility and color CSS properties to them. They may also support similar CSS properties for text such as textshadow or opacity.
Good mathematical rendering requires use of nonUnicode glyphs. Mathematical fonts may only provide these glyphs when the math script tag is enabled and so user agents must ensure that the text within MathML token elements is rendered with that script tag. Some characters like primes already have script size by default and hence would be too small when used in a script position. Hence user agents must support glyph selections via the OpenType font feature ssty (Script Style) in order to display such “prescripted” characters with the appropriate size. For bidirectional layout, Unicode defines characterlevel mirroring to transform a character into its mirrored form, for example U+0028 LEFT PARENTHESIS into U+0029 RIGHT PARENTHESIS. User agents must also support the OpenType font feature rtlm (Righttoleft mirrored forms) to allow glyphlevel mirroring in cases where characterlevel is not enough [OpenFontFormat3]. At the time of writing, Unicode does not distinguish between Chancery and Spencerian style for the Unicode MATHEMATICAL SCRIPT characters. Some mathematical fonts rely on salt or ssXY properties to provide both styles. User agents may support the CSS fontvariantalternates property and corresponding OpenType font features to enable page authors to get access to these styles [CSS3Font] [OpenFontFormat3].
User agents must be able to read information from the OpenType MATH table [OpenFontFormat3]. In particular they must be able to read the values from the MathConstants subtable. They must also be able to use the MathVariants subtable to solve the following problem: given a particular default glyph shape and a certain width or height, find a variant shape glyph (or a construct created by putting several glyphs together) that has the required measurement. More information are provided in see section 3.2.4.
2.2.2 LaTeX
Mathematical rendering rules in this document are implicitly based on MathML, OpenType MATH table and the TeXBook [MathML3] [OpenFontFormat3] [TeXBook]. In this section, we describe more precisely some rules from the TeXBook.
In addition to concepts similar to MathML’s displaystyle and scriptlevel, LaTeX has a “cramped” property, which is involved in the determination of script shifts. It is initially unset on the math element and in general all the children inherits the “cramped” property from their parent. However, it is set to true in the following children:

1.
The denominator of an mfrac element. See section 3.3.2.

2.
The subscripts of the msub, msubsup, munder and munderover elements. See section 3.4.

3.
The overscript of the mover and munderover elements when it is an accent per the MathML specification. See section 3.4.

4.
The children of the msqrt and mroot elements as well as the menclose element that have radical notation.
To implement math spacing, the TeXBook defines eight basic types (Ord for ordinary atoms, Op for large operators, Bin for binary operations, Rel for relations, Open for opening fences, Close for closing fences, Punct for punctuations and Inner for a delimited subformula) and define an inter space for each pair of such types. In the present document, we only follow the spacing algorithm of MathML 3: by default the inter space is always zero and the spacing is produced by spacing elements like mspace, mphantom or mpadded or by the leading and trailing space around embellished operators.
2.3 CSS Styling
2.3.1 Properties
User agents must support the CSS language [CSS2] and must take special styling into account when building the visual representation of the document. Many of the MathML elements accept attributes with length value whose general syntax is described in section 2.1.5.2 of the MathML specification [MathML3]. In general, the syntax is compatible with [CSS2] but user agents must handle specificities of the MathML specification. In particular, the keywords veryverythinmathspace, verythinmathspace, thinmathspace, mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace, negativeveryverythinmathspace, negativeverythinmathspace, negativethinmathspace, negativemediummathspace, negativethickmathspace, negativeverythickmathspace and negativeveryverythickmathspace must be interpreted as their equivalent em value. Also, percent and unitless values must be interpreted with respect to the appropriate reference value. Note that the mpadded element also accepts more general length values as discussed in section 3.3.6.
User agents must support at least the following properties:

1.
display: at least inline, block, inlinetable, tablerow, tablecell and none. It is used for the math and tabular elements. Appropriate values may be specified in the user agent stylesheet as described in section 2.3.2.

2.
direction. The dir attribute on the math, mstyle, mrow and token elements must be mapped to that property.

3.
font property and its shorthands. The mathsize attribute on the math, mstyle and token elements must mapped to that property.

4.
background and color. The mathcolor and mathbackground attributes on presentation MathML elements must be mapped to these properties.

5.
visibility. It is is used for the mphantom element and may be specified in the user agent stylesheet as described in section 2.3.2.
User agents must support the displaystyle attribute. This may be implemented using a new mathmlmathstyle property described in table 2.3.1. The expected behavior may be completely specified in the user agent stylesheet as described in section 2.3.2.
Name:  'mathmlmathstyle' 

Value:  display — inline 
Initial:  inline 
Applies to:  all elements 
Inherited:  yes 
Percentages:  N/A 
Media:  visual 
Computed value:  as specified 
Animatable:  no 
Description:  This value indicates the style to use for mathematical formulas. Formulas in display mode will typically make more generous use of vertical space than inline formulas. Detailed rules are provided in section 3. 
User agents must support the mathvariant attribute. This may be implemented using a new mathmlmathvariant property described in table 2.3.1. The expected behavior may be implemented by mapping mathvariant attributes on the math, mstyle and token elements to mathmlmathvariant. Then during the rendering of text nodes, the mathmlmathvariant value must be taken into account to remap some characters to their equivalent code points, as specified by the MathML specification. However, as indicated in section 3.2.2, when mathmlmathvariant is none on an mi element with a single character, it must actually be treated as if the mathvariant was italic ; this can not be handled via CSSonly.
Name:  'mathmlmathvariant' 

Value:  "none"  "normal"  "bold"  "italic"  "bolditalic"  "doublestruck"  "boldfraktur"  "script"  "boldscript"  "fraktur"  "sansserif"  "boldsansserif"  "sansserifitalic"  "sansserifbolditalic"  "monospace"  "initial"  "tailed"  "looped"  "stretched" 
Initial:  none 
Applies to:  All elements 
Inherited:  yes 
Percentages:  N/A 
Media:  visual 
Computed value:  as specified 
Animatable:  no 
Description:  When not none, characters in text nodes should be rendered using the equivalent Unicode characters of specified mathvariant, taken from the Arabic Mathematical Alphabetic Symbols block (U+1EE00 to U+1EEFF), the Mathematical Alphanumeric Symbols block (U+1D400 to U+1D7FF), or the Letterlike Symbols block (U+2100 to U+214F) that represent ”holes” in the alphabets in the Mathematical Alphanumeric Symbols block. If no such Unicode character exists for the specified mathvariant or if that property is none then no transformations are performed and the original character is used for the rendering. 
User agents must implement the scriptlevel attributes and support automatic incrementation of the scriptlevel described in the MathML specification. They may implement the scriptsizemultiplier and scriptminsize attributes or instead just use the default values (respectively 0.71 and 8pt). These parameters affect the fontsize property as follows: If the parent fontsize is not already below the scriptminsize, then the child fontsize is computed by the following formula:
$\text{FontSize}_{\text{Child}}={\max\left(\text{ScriptMinSize}_{\text{Parent}}% ,{\text{FontSize}_{\text{Parent}}\times{\text{ScriptSizeMultiplier}_{\text{% Parent}}^{\left(\text{FontSize}_{\text{Child}}\text{FontSize}_{\text{Parent}}% \right)}}}\right)}$  (1) 
Since the fontsize change is typically done in a dedicated CSS module of user agents, it may be convenient to introduce a new mathmlscriptlevel property described in table 2.3.1. User agents may then implement the expected behavior by mapping the scriptlevel attribute on the math and mstyle elements to that property and adding appropriate rules in the user agent stylesheet (section 2.3.2). However as indicated in section 3.4.2, the scriptlevel change for underscripts and overscripts can not be handled via CSSonly.
If scriptsizemultiplier and scriptminsize are supported, then they may also be implemented using new CSS properties mathmlscriptsizemultiplier and mathmlscriptminsize described in tables 2.3.1 and 2.3.1 respectively. User agents may then implement the expected behavior by mapping the scriptsizemultiplier and scriptminsize attributes on the math and mstyle elements to these properties.
Name:  'mathmlscriptlevel' 

Value:  
Initial:  0 
Applies to:  all elements 
Inherited:  yes 
Percentages:  N/A 
Media:  visual 
Computed value:  If the specified value is auto, the computed value is obtained by
incrementing the parent mathmlscriptlevel if and only if
mathmlmathstyle is inline.
If the specified value is incrementby 
Animatable:  no 
Description:  This describes the scriptlevel of a mathematical formulas and affects the computation of fontsize as specified by equation 1. 
Name:  'mathmlscriptsizemultiplier' 

Value:  
Initial:  0.71 
Applies to:  All elements 
Inherited:  yes 
Percentages:  N/A 
Media:  visual 
Computed value:  as specified 
Animatable:  no 
Description:  Specifies the multiplier to be used to adjust fontsize due to changes in scriptlevel as specified by equation 1. 
Name:  'mathmlscriptminsize' 

Value:  
Initial:  8pt 
Applies to:  All elements 
Inherited:  yes 
Percentages:  N/A 
Media:  visual 
Computed value:  as specified 
Animatable:  no 
Description:  Specifies the minimum font size allowed due to changes in scriptlevel as specified by equation 1. 
2.3.2 User Agent Stylesheet for MathML
Because mathematical formulas are generally written with special fonts, the default user agent stylesheet must reset the CSS fontfamily on the math element to serif. User agents should then use their own mechanism to try and interpret this serif value on the math element as a font with an OpenType MATH table.
Below is an example on a stylesheet to style MathML elements on which the User Agents may rely. Unfortunately, some rendering engines do not allow universal selectors in their user agent stylesheets and so rules must be expanded to list all possible MathML elements described in the present document. For example mfrac > * can be converted into mfrac > mi, mfrac > mn, mfrac > mo, mfrac > mtext, mfrac > mspace, mfrac > ms, mfrac > mrow, mfrac > mfrac, mfrac > msqrt, mfrac > mroot, mfrac > mstyle, mfrac > merror, mfrac > mpadded, mfrac > mphantom, mfrac > menclose, mfrac > msub, mfrac > msubsup, mfrac > munder, mfrac > mover, mfrac > munderover, mfrac > mmultiscripts, mfrac > mtable, mfrac > maction.
@namespace url(http://www.w3.org/1998/Math/MathML); 
/* The $$ element */ 
math { 
direction: ltr; 
display: inline; 
fontsize: inherit; 
fontstyle: normal; 
fontfamily: serif; 
mathmlmathstyle: inline; 
} 
math[display="block"] { 
display: block; 
textalign: center; 
mathmlmathstyle: display; 
} 
math[display="inline"] { 
display: inline; 
mathmlmathstyle: inline; 
} 
math[displaystyle="false"] { 
mathmlmathstyle: inline; 
} 
math[displaystyle="true"] { 
mathmlmathstyle: display; 
} 
/* Links */ 
mrow[href] { 
color: blue; 
} 
/* Tabular elements */ 
mtable { 
display: inlinetable; 
mathmlmathstyle: inline; 
} 
mtable[displaystyle="true"] { 
mathmlmathstyle: display; 
} 
mtable[frame="none"] { 
border: none; 
} 
mtable[frame="solid"] { 
border: solid thin; 
} 
mtable[frame="dashed"] { 
border: dashed thin; 
} 
mtr, mlabeledtr { 
display: tablerow; 
verticalalign: baseline; 
} 
mlabeledtr > mtd:firstchild { 
display: none; 
} 
mtd { 
display: tablecell; 
verticalalign: inherit; 
textalign: center; 
padding: 0.5ex 0.4em; 
} 
/* The 
ms { 
display: inline; 
} 
ms:before, ms:after { 
content: "\0022" 
} 
ms[lquote]:before { 
content: attr(lquote) 
} 
ms[rquote]:after { 
content: attr(rquote) 
} 
/* The 
merror { 
outline: solid thin red; 
backgroundcolor: lightYellow; 
} 
/* The 
mphantom { 
visibility: hidden; 
} 
/* Scriptlevel and displaystyle for other elements */ 
mstyle[displaystyle="false"] { 
mathmlmathstyle: inline; 
} 
mstyle[displaystyle="true"] { 
mathmlmathstyle: display; 
} 
mfrac > * { 
mathmlscriptlevel: auto; 
mathmlmathstyle: inline; 
} 
mroot > :not(:firstchild) { 
mathmlscriptlevel: incrementby 2; 
mathmlmathstyle: inline; 
} 
msub > :not(:firstchild), 
msup > :not(:firstchild), 
msubsup > :not(:firstchild), 
mmultiscripts > :not(:firstchild) { 
mathmlscriptlevel: incrementby 1; 
mathmlmathstyle: inline; 
} 
munder > :not(:firstchild), 
mover > :not(:firstchild), 
munderover > :not(:firstchild) { 
mathmlmathstyle: inline; 
} 