| Up: Table of Contents | Proposed Recommendation 24-Feb-98 |
Token elements can contain any sequence of 0 or more characters, or extended characters represented by entity references. In particular, tokens with empty content are allowed, and should typically render invisibly, with no width except for the normal extra spacing for that kind of token element. The allowed set of entity references for extended characters is given in Chapter 6.
In MathML, characters and MathML entity references are only allowed to occur as part of the content of a token element. The only exception is whitespace between elements, which is ignored.
The <malignmark/> element (see Section 3.5.4) is the only element allowed in the
content of tokens. It marks a place which can be vertically aligned
with other objects, as explained in that section.
Several attributes related to text formatting are provided on all token elements except <mspace/>, but on no other elements except <mstyle>. These are:
| Name | values | default | |
| fontsize | number v-unit | inherited | |
| fontweight | normal | bold | inherited | |
| fontstyle | normal | italic | normal (except on <mi>) | |
| fontfamily | string | css-fontfamily | inherited | |
| color | #rgb | #rrggbb | html-color-name | inherited |
(See Section 2.3.3 for terminology and notation used in attribute value descriptions.)
Token elements (other than <mspace/>) should be rendered as their content (i.e., in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters in their content) using the attributes listed above, with surrounding spacing modified by rules or attributes specific to each type of token element. Some of the individual attributes are further discussed below.
Recall that all MathML elements, including tokens, accept class, style, and id attributes for compatibility with style sheet mechanisms, as described in Section 2.3.4. In principle, the font properties controlled by the attributes listed above might be better handled using style sheets. When style sheet support becomes available for XML, future revisions of MathML will likely revisit the issue of font control.
MathML expressions are often embedded in a textual data format such as HTML, and their renderings are likewise embedded in a rendering of the surrounding text. The renderer of the surrounding text (e.g. a browser) should provide the MathML renderer with information about the rendering environment, including attributes of the surrounding text such as its font size, so that the MathML can be rendered in a compatible style. For this reason, most attribute values affecting text rendering are inherited from the rendering environment, as shown in the "default" column in the table above. (Note that it is also important for the rendering environment to provide the renderer with additional information, such as the baseline position of surrounding text, which is not specified by any MathML attributes.)
The exception to the general pattern of inheritance is the fontstyle attribute, whose default value is "normal" (non-slanted) for most tokens, but for <mi> depends on the content in a way described in the section about <mi>, Section 3.2.2. Note that fontstyle is not inherited in MathML, even though the corresponding CSS1 property "font-style" is inherited in CSS.
The fontsize attribute specifies the desired font size.
v-unit represents a unit of vertical length (see Section
2.3.3). The most common unit for specifying font sizes in typesetting
is pt (points).
If the requested size of the current font is not available, the renderer should approximate it in the manner likely to lead to the most intelligible, highest quality rendering.
Many MathML elements automatically change fontsize in some of their children; see the discussion of scriptlevel in the section on <mstyle>, Section 3.3.4.
The value of the fontfamily attribute should be the name of a font which may be available to a MathML renderer, or information which permits the renderer to select a font in some manner; acceptable values and their meanings are dependent on the specific renderer and rendering environment in use, and are not specified by MathML (but see the note about css-fontfamily below). (Note that the renderer's mechanism for finding fonts by name may be case-sensitive.)
If the value of fontfamily is not recognized by a particular MathML renderer, this should never be interpreted as a MathML error; rather, the renderer should either use a font which it considers to be a suitable substitute for the requested font, or ignore the attribute and act as if no value had been given.
Note that any use of the fontfamily attribute is unlikely to be portable across all MathML renderers. In particular, it should never be used to try to achieve the effect of a reference to an extended character (for example, by using a reference to a character in some symbol font which maps ordinary characters to glyphs for extended characters). As a corollary to this principle, MathML renderers should attempt to always produce intelligible renderings for the extended characters listed in Chapter 6, even when these characters are not available in the font family indicated. Such a rendering is always possible -- as a last resort, a character can be rendered to appear as an XML-style entity reference using one of the entity names given for the same character in Chapter 6.
The symbol css-fontfamily refers to a legal value for the "font-family" property in CSS1, which is a comma-separated list of alternative font family names or generic font types in order of preference, as documented in more detail in CSS1. MathML renderers are encouraged to make use of the CSS syntax for specifying fonts when this is practical in their rendering environment, even if they do not otherwise support CSS. (See also the subsection CSS-compatible attributes within Section 2.3.3.)
The syntax and meaning of the color attribute are as described for the same attribute of <mstyle> (Section 3.3.4).
An <mi> element represents a symbolic name or arbitrary text which should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants.
Not all "mathematical identifers" are represented by <mi> elements -- for example, subscripted or primed variables should be represented using <msub> or <msup> respectively. Conversely, arbitrary text playing the role of a "term" (such as an ellipsis in a summed series) can be represented using an <mi> element, as shown in an example under the subheading Mixing text and math in Section 3.2.5.
It should be stressed that <mi> is a presentation element, and as such, it only indicates that its content should be rendered as an identifier. In the majority of cases, the contents of an <mi> will actually represent a mathematical identifier such as a variable or function name. However, as the preceding paragraph indicates, the correspondence between notations which should render like identifiers and notations which are actually intended to represent mathematical identifiers is not perfect. For an element whose semantics is guaranteed to be that of an identifier, see the description of <ci> in Chapter 4.
| Name | values | default | |
| fontstyle | normal | italic | (depends on content; described below) |
A typical graphical renderer would render an <mi> element as the characters in its content, with no extra spacing around the characters (except spacing associated with neighboring elements). The default fontstyle would (typically) be "normal" (non-slanted) unless the content is a single character, in which case it would be "italic". Note that this rule for fontstyle is specific to <mi> elements; the default value for the fontstyle attribute of other MathML token elements is "normal".
<mi> x </mi> <mi> D </mi> <mi> sin </mi> <mi></mi>
An <mi> element with no content is allowed;
<mi></mi> might, for example, be used by an
"expression editor" to represent a location in a MathML expression
which requires a "term" (according to conventional syntax for
mathematics) but does not yet contain one.
Identifiers include function names such as "sin". Expressions such as "sin x" should be written using the "⁡" operator (which also has the short name "⁡") as shown below; see also the discussion of invisible operators in Section 3.2.4.
<mrow> <mi> sin </mi> <mo> ⁡ </mo> <mi> x </mi> </mrow>
Miscellaneous text that should be treated as a "term" can also be represented by an <mi> element, as in:
<mrow> <mn> 1 </mn> <mo> + </mo> <mi> ... </mi> <mo> + </mo> <mi> n </mi> </mrow>
When an <mi> is used in such exceptional situations, explicitly setting the fontstyle attribute may give better results than the default behavior of some renderers.
The names of symbolic constants should be represented as <mi> elements:
<mi> π </mi> <mi> ⅈ </mi> <mi> ⅇ </mi>
Use of special entity references for such constants can simplify
the interpretation of MathML presentation elements. See Chapter 6 for a complete list of character
entity references in MathML.
An <mn> element represents a "numeric literal" or other data which 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 concept of a mathematical "number" depends on the context, and is not well-defined in the abstract. As a consequence, not all mathematical numbers should be represented using <mn>; examples of mathematical numbers which should be represented differently are shown below, and include negative numbers, complex numbers, ratios of numbers shown as fractions, and names of numeric constants.
Conversely, since <mn> is a presentation element, there are a few situations where it may desirable to include arbitrary text in the content of an <mn> which should merely render as a numeric literal, even though that content may not be unambiguously interpretable as a number according to any particular standard encoding of numbers as character sequences. As a general rule, however, the <mn> element should be reserved for situations where its content is actually intended to represent a numeric quantity in some fashion. For an element whose semantics are guaranteed to be that of a particular kind of mathematical number, see the description of <cn> in Chapter 4.
A typical graphical renderer would render an <mn> element as the characters of its content, with no extra spacing around them (except spacing from neighboring elements such as <mo>). Unlike <mi>, <mn> elements are (typically) rendered in an unslanted font by default, regardless of their content.
<mn> 2 </mn> <mn> 0.123 </mn> <mn> 1,000,000 </mn> <mn> 2.1e10 </mn> <mn> 0xFFEF </mn> <mn> MCMLXIX </mn> <mn> twenty one </mn>
Many mathematical numbers should be represented using presentation elements other than <mn> alone; this includes negative numbers, complex numbers, ratios of numbers shown as fractions, and names of numeric constants. Examples of MathML representations of such numbers include:
<mrow> <mo> - </mo> <mn> 1 </mn> </mrow>
<mrow>
<mn> 2 </mn>
<mo> + </mo>
<mrow>
<mn> 3 </mn>
<mo> ⁢ </mo>
<mi> ⅈ </mi>
</mrow>
</mrow>
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
<mi> π </mi>
<mi> ⅇ </mi>
An <mo> element represents an operator or anything which 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 which should "render as an operator" includes a number of notations which 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.
The term "operator" as used in Chapter 3 means any symbol or notation which should render as an operator, and which is therefore representable by an <mo> element. That is, the term "operator" includes any ordinary operator, fence, separator, or accent unless otherwise specified or clear from the context.
All such symbols are represented in MathML with <mo> elements since they are subject to essentially the same rendering attributes and rules; subtle distinctions in the rendering of these classes of symbols, when they exist, are supported using the boolean attributes fence, separator and accent which can be used to distinguish these cases.
A key feature of the <mo> element is that its default attribute values are set on a case-by-case basis from an "operator dictionary" as explained below. In particular, default values for fence, separator and accent can usually be found in the operator dictionary and therefore need not be specified on each <mo> element.
Note that some mathematical operators are represented not by <mo> elements alone, but by <mo> elements "embellished" with (for example) surrounding superscripts; this is further described below. Conversely, as presentation elements, <mo> elements can contain arbitrary text, even when that text has no standard interpretation as an operator; for an example, see the discussion Mixing text and math in Section 3.2.5. See also Chapter 4 for definitions of MathML content elements which are guaranteed to have the semantics of specific mathematical operators.
<mo> elements accept the attributes listed in Section 3.2.1, and the additional attributes listed here. Most attributes get their default values from the "operator dictionary", as described later in this section. When a dictionary entry is not found for a given <mo> element, the default value shown here in parentheses is used.
| Name | values | default | |
| form |
prefix | infix | postfix |
set by position of operator in an <mrow> (rule given below); used with <mo> content to index operator dictionary | |
| fence | true | false | set by dictionary (false) | |
| separator | true | false | set by dictionary (false) | |
| lspace | number h-unit | set by dictionary (.27777em) | |
| rspace | number h-unit | set by dictionary (.27777em) | |
| stretchy | true | false | set by dictionary (false) | |
| symmetric | true | false | set by dictionary (true) | |
| maxsize | number [ v-unit | h-unit ] | infinity | set by dictionary (infinity) | |
| minsize | number [ v-unit | h-unit ] | set by dictionary (1) | |
| largeop | true | false | set by dictionary (false) | |
| movablelimits | true | false | set by dictionary (false) | |
| accent | true | false | set by dictionary (false) |
h-unit represents a unit of horizontal length (see Section 2.3.3). v-unit represents a unit of vertical length. If no unit is given with maxsize or minsize, the number is a multiplier of the normal size of the operator in the direction (or directions) in which it stretches. These attributes are further explained below.
Typical graphical renderers show all <mo> elements as the characters of their content, with additional spacing around the element determined from the attributes listed above. Detailed rules for determining operator spacing in visual renderings are described in a subsection below. As always, MathML does not require a specific rendering, and these rules are provided as suggestions for the convenience of implementors.
Renderers without access to complete fonts for the MathML character
set may choose not to render an <mo> element as precisely
the characters in
its content in some cases. For example, <mo> ≤
</mo> might be rendered as <= to a terminal.
However, as a general rule, renderers should attempt to render the
content of an <mo> element as literally as possible. That is,
<mo> ≤ </mo> and <mo> <=
</mo> should render differently. (The first one should
render as a single extended character representing a
less-than-or-equal-to sign, and the second one as the two-character
sequence <=.)
<mo> + </mo> <mo> < </mo> <mo> ≤ </mo> <mo> <= </mo> <mo> ++ </mo> <mo> ∑ </mo> <mo> .NOT. </mo> <mo> and </mo> <mo> ⁢ </mo>
Note that the <mo> elements in these examples don't need explicit fence or separator attributes, since these can be found using the operator dictionary as described below. Some of these examples could also be encoded using the <mfenced> element described in Section 3.3.8.
(a+b)
<mrow>
<mo> ( </mo>
<mrow>
<mi> a </mi>
<mo> + </mo>
<mi> b </mi>
</mrow>
<mo> ) </mo>
</mrow>
[0,1)
<mrow>
<mo> [ </mo>
<mrow>
<mn> 0 </mn>
<mo> , </mo>
<mn> 1 </mn>
</mrow>
<mo> ) </mo>
</mrow>
f(x,y)
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mrow>
<mi> x </mi>
<mo> , </mo>
<mi> y </mi>
</mrow>
<mo> ) </mo>
</mrow>
</mrow>
Certain operators which are "invisible" in traditional mathematical notation should be represented using specific entity references within <mo> elements, rather than simply by nothing. The entity references used for these "invisible operators" are:
| Full name | Short name | Examples of use | |
| ⁢ | ⁢ | xy | |
| ⁡ | ⁡ | f(x) sin x | |
| ⁣ | ⁣ | m12 |
The MathML representations of the examples in the above table are:
<mrow>
<mi> x </mi>
<mo> ⁢ </mo>
<mi> y </mi>
</mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mrow>
<mi> sin </mi>
<mo> ⁡ </mo>
<mi> x </mi>
</mrow>
<msub>
<mi> m </mi>
<mrow>
<mn> 1 </mn>
<mo> ⁣ </mo>
<mn> 2 </mn>
</mrow>
</msub>
The reasons for using specific <mo> elements for invisible operators include:
For example, an audio renderer might render f(x) (represented as in the above examples) by speaking "f of x", but use the word "times" in its rendering of xy. Although its rendering must still be different depending on the structure of neighboring elements (sometimes leaving out "of" or "times" entirely), its task is made much easier by the use of a different <mo> element for each invisible operator.
For reasons like those for including special entities for invisible operators,
MathML also includes "ⅆ" for use in an <mo> element
representing the differential operator symbol usually denoted by "d".
Typical visual rendering behaviors for <mo> elements are more complex than for the other MathML token elements, so the rules for rendering them are described in this separate subsection.
Note that, like all rendering
rules in MathML, these rules are suggestions rather than requirements.
Furthermore, no attempt is made to specify the rendering completely; rather,
enough information is given to make the intended effect of the various
rendering attributes as clear as possible.
Many mathematical symbols, such as an integral sign, a plus sign, or a parenthesis, have a well-established, predictable, traditional notational usage. Typically, this usage amounts to certain default attribute values for <mo> elements with specific contents and a specific form attribute. Since these defaults vary from symbol to symbol, MathML anticipates that renderers will have an "operator dictionary" of default attributes for <mo> elements (see Appendix C) indexed by each <mo> element's content and form attribute. If an <mo> element is not listed in the dictionary, the default values shown in parentheses in the table of attributes for <mo> should be used, since these values are typically acceptable for a generic operator.
Some operators are "overloaded", in the sense that they can occur
in more than one form (prefix, infix, or postfix), with possibly
different rendering properties for each form. For example, "+" can be
either a prefix or an infix operator. Typically, a visual renderer
would add space around both sides of an infix operator, while only on
the left of a prefix operator. The form attribute allows
specification of which form to use, in case more than one form is
possible according to the operator dictionary and the default value
described below is not suitable.
The form attribute does not usually have to be specified explicitly, since there are effective heuristic rules for inferring the value of the form attribute from the context. If it is not specified, and there is more than one possible form in the dictionary for an <mo> element with given content, the renderer should choose which form to use as follows (but see the exception for embellished operators, described later):
Note that these rules make reference to the <mrow> in which the <mo> element lies. In some situations, this <mrow> might be an inferred <mrow> implicitly present around the arguments of an element such as <msqrt> or <mtd>.
Opening (left) fences should have form="prefix", and closing (right) fences should have form="postfix"; separators are usually "infix", but not always, depending on their surroundings. As with ordinary operators, these values do not usually need to be specified explicitly.
If the operator does not occur in the dictionary with the specified form, the renderer should use one of the forms which is available there, in the order of preference: infix, postfix, prefix; if no forms are available for the given <mo> element content, the renderer should use the defaults given in parentheses in the table of attributes for <mo>.
There is one exception to the above rules for choosing an <mo> element's default form attribute. An <mo> element which is "embellished" by one or more nested subscripts, superscripts, surrounding text or whitespace, or style changes behaves differently. It is the embellished operator as a whole (this is defined precisely, below) whose position in an <mrow> is examined by the above rules and whose surrounding spacing is affected by its form, not the <mo> element at its core; however, the attributes influencing this surrounding spacing are taken from the <mo> element at the core (or from that element's dictionary entry).
For example, the "+4 " in ![[Graphics:images/3_1.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_1.gif)
should be considered an infix
operator as a whole, due to its position in the middle of an
<mrow>, but its rendering attributes should be taken from
the <mo> element representing the "+", or when those are
not specified explicitly, from the operator dictionary entry for
<mo form="infix"> + </mo>.
The precise definition of an "embellished operator" is:
Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list.
The above rules for choosing operator forms and defining embellished operators are chosen so that in all ordinary cases it will not be necessary for the author to specify a form attribute.
The following notes are included as a rationale for certain aspects of the above definitions, but should not be important for most users of MathML:
An <mfrac> is included as an "embellisher" because of the common notation for a differential operator:
<mfrac>
<mo> ⅆ </mo>
<mrow>
<mo> ⅆ </mo>
<mi> x </mi>
</mrow>
</mfrac>
Since the definition of embellished operator affects the use of the attributes related to stretching, it is important that it includes embellished fences as well as ordinary operators; thus it applies to any <mo> element.
Note that an <mrow> containing a single argument is an embellished operator if and only if its argument is an embellished operator. This is because an <mrow> with a single argument must be equivalent in all respects to that argument alone (as discussed in Section 3.3.1). This means that an <mo> element which is the sole argument of an <mrow> will determine its default form attribute based on that <mrow>'s position in a surrounding, perhaps inferred, <mrow> (if there is one), rather than based on its own position in the <mrow> it is the sole argument of.
Note that the above definition defines every <mo> element to be "embellished" -- that is, "embellished operator" can be considered (and implemented in renderers) as a special class of MathML expressions, of which "<mo> element" is a specific case.
The amount of space added around an operator (or embellished operator), when it occurs in an <mrow>, can be directly specified by the lspace and rspace attributes. These values are in ems if no units are given. By convention, operators that tend to bind tightly to their arguments have smaller values for spacing than operators that tend to bind less tightly. This convention should be followed in the operator dictionary included with a MathML renderer. In TeX, these values can only be one of three values; typically they are 3/18em, 4/18em, and 5/18em. MathML does not impose this limit.
Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in TeX.
Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium.
Four attributes govern whether and how an operator (perhaps embellished) stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator has the attribute stretchy="true", then it (that is, each character in its content) obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. In practice, typical renderers will only be able to stretch a small set of characters, and quite possibly will only be able to generate a discrete set of character sizes.
There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy="true" it should be stretched in each direction for which stretching is possible. It is up to the renderer to know in which directions it is able to stretch each character. (Most characters can be stretched in at most one direction by typical renderers, but some renderers may be able to stretch certain characters, such as diagonal arrows, in both directions independently.)
The minsize and maxsize attributes limit the amount of stretching (in either direction). These two attributes are given as multipliers of the operator's normal size in the direction or directions of stretching, or as absolute sizes using units. For example, if a character has maxsize="3", then it can grow to be no more than three times its normal (unstretched) size.
The symmetric attribute governs whether the height and depth above and below the axis of the character are forced to be equal (by forcing both height and depth to become the maximum of the two). An example of a situation where one might set symmetric="false" arises with parentheses around a matrix not aligned on the axis, which frequently occurs when multiplying non-square matrices. In this case, one wants the parentheses to stretch to cover the matrix, whereas stretching the parentheses symmetrically would cause them to protrude beyond one edge of the matrix. The symmetric attribute only applies to characters that stretch vertically (otherwise it is ignored).
If a stretchy <mo> element is embellished (as defined earlier in this section), the <mo> element at its core is stretched to a size based on the context of the embellished operator as a whole, i.e. to the same size as if the embellishments were not present. For example, the parentheses in the following example (which would typically be set to be strechy by the operator dictionary) will be stretched to the same size as each other, and the same size they would have if they were not underlined and overlined, and furthermore will cover the same vertical interval:
<mrow>
<munder>
<mo> ( </mo>
<mo> _ </mo>
</munder>
<mfrac>
<mi> a </mi>
<mi> b </mi>
</mfrac>
<mover>
<mo> ) </mo>
<mo> ‾ </mo>
</mover>
</mrow>
Note that this means that the stretching rules given below must refer to the context of the embellished operator as a whole, not just to the <mo> element itself.
This shows one way to set the maximum size of a parenthesis so that it does not grow, even though its default value is stretchy="true".
<mrow>
<mo maxsize="1"> ( </mo>
<mfrac>
<mi> a </mi> <mi> b </mi>
</mfrac>
<mo maxsize="1"> ) </mo>
</mrow>
The above should render as ![[Graphics:images/3_2.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_2.gif)
as opposed to the
default rendering ![[Graphics:images/3_3.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_3.gif)
.
Note that each parenthesis is sized independently; if only one of them had maxsize="1", they would render with different sizes.
Most common opening and closing fences are defined in the operator dictionary to stretch by default; and they stretch vertically. Also, operators such as ∑, ∫, /, and vertical arrows stretch vertically by default.
In the case of a stretchy operator in a table cell (i.e. within an <mtd> element), the above rules assume each cell of the table row containing the stretchy operator covers exactly one row. (Equivalently, the value of the rowspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched vertically to cover those table cells which are entirely within the set of table rows that the operator's cell covers. Table cells which extend into rows not covered by the stretchy operator's table cell should be ignored.
By default, most horizontal arrows and some accents stretch horizontally.
In the case of a stretchy operator in a table cell (i.e. within an <mtd> element), the above rules assume each cell of the table column containing the stretchy operator covers exactly one column. (Equivalently, the value of the columnspan attribute is assumed to be 1 for all the table cells in the table row, including the cell containing the operator.) When this is not the case, the operator should only be stretched horizontally to cover those table cells which are entirely within the set of table columns that the operator's cell covers. Table cells which extend into columns not covered by the stretchy operator's table cell should be ignored.
The rules for horizontal stretching include <mtd> elements to allow arrows to stretch for use in commutative diagrams laid out using <mtable>. The rules for the horizontal stretchiness include scripts to make examples such as the following work:
<mrow>
<mi> x </mi>
<mover>
<mo> → </mo>
<mtext> maps to </mtext>
</mover>
<mi> y </mi>
</mrow>
This displays as ![[Graphics:images/3_4.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_4.gif)
.
If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match), then it has the standard (unstretched) size determined by the font and current fontsize.
If a stretchy operator is required to stretch, but all other expressions in the containing element or object (as described above) are also stretchy, all elements that can stretch should grow to the maximum of the normal unstretched sizes of all elements in the containing object, if they can grow that large. If the value of minsize or maxsize prevents this then that (min or max) size is used.
For example, in an <mrow> containing nothing but vertically stretchy operators, each of the operators should stretch to the maximum of all of their normal unstretched sizes, provided no other attributes are set which override this behavior. Of course, limitations in fonts or font rendering may result in the final, stretched sizes being only approximately the same.
The largeop attribute specifies whether the operator should be drawn larger than normal if displaystyle="true" in the current rendering environment. This roughly corresponds to TeX's \displaystyle style setting. MathML uses two attributes, displaystyle and scriptlevel, to control orthogonal presentation features that TeX encodes into one "style" attribute with values \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. These attributes are discussed further in Section 3.3.4 describing the <mstyle> element. Note that these attributes can be specified directly on an <mstyle> element's begin tag, but not on most other elements. Examples of large operators include ∫ and ∏.
The movablelimits attribute specifies whether underscripts and overscripts attached to this <mo> element should be drawn as subscripts and superscripts when displaystyle="false". movablelimits="false" means that underscripts and overscripts should never be drawn as subscripts and superscripts. In general, displaystyle is "true" for displayed math and "false" for inline math. Also, displaystyle is "false" by default within tables, scripts and fractions, and a few other exceptional situations detailed in Section 3.3.4. Thus, operators with movablelimits="true" will display with limits (i.e., underscripts and overscripts) in displayed math, and with subscripts and superscripts in inline math, tables, scripts and so on . Examples of operators that typically have movablelimits="true" are ∑, ∏, and "lim".
The accent attribute determines whether this operator should be treated by default as an accent (diacritical mark) when used as an underscript or overscript; see <munder>, <mover>, and <munderover> (Sections 3.4.4 - 3.4.6).
The separator attribute may affect automatic linebreaking in renderers which position ordinary infix operators at the beginnings of broken lines rather than at the ends (that is, which avoid linebreaking just after such operators), since linebreaking should be avoided just before separators, but is acceptable just after them.
The fence attribute has no effect in the suggested visual
rendering rules given here; it is not needed for properly rendering
traditional notation using these rules. It is provided so that
specific MathML renderers, especially non-visual renderers, have the
option of using this information.
An <mtext> element is used to represent arbitrary text which should be rendered as itself. In general, the <mtext> element is intended to denote commentary text which is not central to the mathematical meaning or notational structure of the expression it is contained in.
Note that some text with a clearly defined notational role might be more appropriately marked up using <mi> or <mo>; this is discussed further below.
An <mtext> element can be used to contain "renderable whitespace", i.e., invisible characters which are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. This is not related to any whitespace in the source MathML consisting of blanks, newlines, tabs, or carriage returns; whitespace present directly in the source is trimmed and collapsed, as described in Section 2.3.5. Whitespace which is intended to be rendered as part of an element's content must be represented by entity references (unless it consists only of single blanks between non-whitespace characters).
Renderable whitespace can have a positive or negative width, as in " " and "​", or zero width, as in "​". The complete list of such characters is given in Chapter 6. Note that there is no formal distinction in MathML between renderable whitespace characters and any other class of characters, in <mtext> or in any other element.
Renderable whitespace can also include characters that affect alignment or linebreaking. Some of these characters are:
| Entity name | Purpose (rough description) |
| NewLine | start a new line -- don't indent |
| IndentingNewLine | start a new line -- indent |
| NoBreak | do not allow a linebreak here |
| GoodBreak | if a linebreak is needed on the line, here is a good spot |
| BadBreak | if a linebreak is needed on the line, try to avoid breaking here |
For the complete list of MathML entities, consult Chapter 6.
See also the warnings about the legal grouping of "spacelike elements" in Section 3.2.6, and about the use of such elements for "tweaking" or conveying meaning in Section 3.3.6.
<mtext> Theorem 1: </mtext> <mtext>   </mtext> <mtext>      </mtext> <mtext> /* a comment */ </mtext>
In some cases, text embedded in math could be more appropriately
represented using <mo> or <mi> elements.
For example, the expression ![[Graphics:images/3_5.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_5.gif)
is equivalent to ![[Graphics:images/3_6.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_6.gif)
and could be
represented as:
<mrow>
<mo> there exists </mo>
<mrow>
<mrow>
<mi> δ </mi>
<mo> > </mo>
<mn> 0 </mn>
</mrow>
<mo> such that </mo>
<mrow>
<mrow>
<mi> f </mi>
<mo> ⁡ </mo>
<mrow>
<mo> ( </mo>
<mi> x </mi>
<mo> ) </mo>
</mrow>
</mrow>
<mo> < </mo>
<mn> 1 </mn>
</mrow>
</mrow>
</mrow>
An example involving an <mi> element
is: ![[Graphics:images/3_7.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_7.gif)
In this example, ellipsis should be represented using an <mi> element,
since it takes the place of a term in the sum (see Section 3.2.2, <mi>).
On the other hand, expository text within MathML is best represented with an
<mtext> element. An example of this is:
![[Graphics:images/3_9.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_9.gif)
![[Graphics:images/3_8.gif]](http://www.w3.org/TR/1998/PR-math-19980224/images/3_8.gif)
However, when MathML is embedded in HTML, the example is probably best rendered with only the two inequalities represented as MathML at all, letting the text be part of the surrounding HTML.
Another factor to consider in deciding how to mark up text is the
effect on rendering. Text enclosed in an <mo> element is
unlikely to be found in a renderer's operator dictionary, so it will
be rendered with the format and spacing appropriate for an "unrecognized
operator", which may or may not be better than the format and spacing for
"text" obtained by using an <mtext> element. An ellipsis
entity in an <mi> element is apt to be spaced more
appropriately for taking the place of a term within a series than if it
appeared in an <mtext> element.
An <mspace/> empty element represents a blank space of any desired size, as set by its attributes. The default value for each attribute is "0em" or "0ex", so it will not be useful without some attributes specified.
| Name | values | default | |
| width | number h-unit | 0em | |
| height | number v-unit | 0ex | |
| depth | number v-unit | 0ex |
h-unit and v-unit represent units of horizontal or vertical length, respectively (see Section 2.3.3).
Note the warning about the legal grouping of "spacelike elements" given below, and the
warning about the use of such elements for "tweaking" or conveying meaning in Section 3.3.6.
See also the other elements which can render as whitespace, namely <mtext>, <mphantom>, and <maligngroup/>;
A number of MathML presentation elements are "spacelike" in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions. For example, spacelike elements are handled specially in the suggested rendering rules for <mo> given in Section 3.2.4. The following MathML elements are defined to be "spacelike":
Note that an <mphantom> is not automatically
defined to be spacelike, unless its content is spacelike. This is
because operator spacing is affected by whether adjacent elements are
spacelike. Since the <mphantom> element is primarily
intended as an aid in aligning expressions, operators adjacent to an
<mphantom> should behave as if they were adjacent to the
contents of the <mphantom>, rather than to an
equivalently sized area of whitespace.
Authors who insert spacelike elements or <mphantom> elements into an existing MathML expression should note that such elements are counted as arguments, in elements which require a specific number of arguments, or which interpret different argument positions differently.
Therefore, spacelike elements inserted into such a MathML element
should be grouped with a neighboring argument of that element by
introducing an <mrow> for that purpose. For example, to allow for
vertical alignment on the right edge of the base of a superscript,
the expression
<msup> <mi> x </mi> <malignmark edge="right"/>
<mn> 2 </mn> </msup>
is illegal, because <msup> must have exactly 2 arguments;
the correct expression would be:
<msup>
<mrow>
<mi> x </mi>
<malignmark edge="right"/>
</mrow>
<mn> 2 </mn>
</msup>
See also the warning about "tweaking"
in Section 3.3.6.
The <ms> element is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems containing "programming languages". By default, string literals are displayed surrounded by double quotes. As explained in Section 3.2.5, ordinary text embedded in a mathematical expression should be marked up with <mtext>, or in some cases <mo> or <mi>, but never with <ms>.
Note that the string literals encoded by <ms> are
"Unicode strings" rather than "ASCII strings". In practice, non-ASCII
characters will typically be represented by entity references. For
example, <ms>&</ms> represents a string
literal containing a single character, '&', and
<ms>&amp;</ms> represents a string literal
containing 5 characters, the first one of which is '&'. (In fact,
MathML string literals are even more general than Unicode string
literals, since not all MathML entity references necessarily refer to
existing Unicode characters, as discussed in Chapter 6.)
Like all token elements, <ms> does trim and collapse whitespace in its content according to the rules of Section 2.3.5, so whitespace intended to remain in the content should be encoded as described in that section.
<ms> elements accept the attributes listed in Section 3.2.1, and additionally:
| Name | values | default | |
| lquote | string | " | |
| rquote | string | " |
In visual renderers, the content of an <ms> element is
typically rendered with no extra spacing added around the string, and
a quote character at the beginning and the end of the string. By
default, the left and right quote characters are both the standard
double quote character ". However, these
characters can be changed with the lquote and rquote
attributes respectively.
The content of <ms> elements should be rendered with
visible "escaping" of certain characters in the content, including at
least "double quote" itself, and preferably whitespace other than
individual blanks. The intent is for the viewer to see that the
expression is a string literal, and to see exactly which characters
form its content. For example, <ms>double quote is
"</ms> might be rendered as "double quote is
\"".