Up: Table of Contents Working Draft 6-Jan-98

3. Presentation elements


3.2 Token elements

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.

3.2.1 Attributes common to token elements

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   (of points) inherited
fontweight plain | bold inherited
fontslant plain | italic plain (except on <mi>)
fontfamily string  inherited
fontcolor #rrggbb  (six hex digits) 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.

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, in particular, by default, those listed above.

The exception to this pattern is the fontslant attribute, whose default value is "plain" (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.

The value of the fontfamily attribute should be the name of a font which may be available to a MathML renderer; acceptable values and their meanings are dependent on the specific renderer and rendering environment in use, and are not specified in MathML. (This attribute value may be case-sensitive, depending on the renderer's mechanism for finding fonts by name.)

If the value of fontfamily is not recognized by a particular MathML renderer, it should never be interpreted an error; rather, the renderer should either use a font which it considers to be a suitable substitute for the named font, or may 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.

Future extensions to MathML should allow for other values for the fontweight and fontslant attributes, and the other attributes listed above, in keeping with whatever standard emerges for specifying font attributes in HTML, since MathML is intended to be as compatible as possible with HTML.

3.2.2 <mi> -- identifier

Description:

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.

Attributes of <mi>:

<mi> elements accept the attributes listed in Section 3.2.1, but in one case with a different default value:
Name  values  default 
fontslant plain | 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 fontslant would (typically) be "plain" (non-slanted) unless the content is a single character, in which case the font slant would be "italic". Note that this rule for fontslant is specific to <mi> elements; the default value for the fontslant attribute of other MathML token elements is "plain".

Examples of <mi>:

  <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 fontslant 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.

3.2.3 <mn> -- number

Description:

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.

Attributes of <mn>:

<mn> elements accept the attributes listed in Section 3.2.1.

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.

Examples of <mn>:

  <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>

Examples of numbers which should not be written using <mn> alone:

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>

3.2.4 <mo> -- operator, fence, separator or accent

Description:

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 to determining 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.

Attributes of <mo>:

<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   (ems) set by dictionary (.2777777)
rspace number   (ems) set by dictionary (.2777777)
stretchy true | false set by dictionary (false)
symmetric true | false set by dictionary (true)
maxsize number | infinity set by dictionary (infinity)
minsize number  set by dictionary (0)
largeop true | false set by dictionary (false)
movablelimits true | false set by dictionary (false)
accent true | false set by dictionary (false)

The values of maxsize and minsize are given as multipliers of the font size.

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> as the characters in its content is 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>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 <=.)

Examples of <mo> elements representing ordinary operators:

  <mo> + </mo>

  <mo> < </mo>

  <mo> ≤ </mo>

  <mo> <= </mo>

  <mo> ++ </mo>

  <mo> ∑ </mo>

  <mo> .NOT. </mo>

  <mo> and </mo>

  <mo> ⁢ </mo>

Examples of expressions using <mo> elements for fences and separators:

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>

Invisible operators

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.

Entity references for other special operators

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".

Detailed rendering rules for <mo> elements

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.

The operator dictionary

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) index by 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.

Default value of form attribute

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>.

Exception for embellished operators

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] 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.

Notes on embellished operators:

The following notes are included for completeness, 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 oprator. This is because an an <mrow> with a single argument should be equivalent in all respects to that argument alone (see Section 3.3.1). This is especially convenient in many situations where MathML is being automatically generated via templates.

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.

Spacing around an operator

The amount of space added around an operator (or embellished operator) can be directly specified by the lspace and rspace attributes. These numbers are given in ems. 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.

Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium.

Stretching of operators, fences and accents

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. These two attributes are given as multipliers of the font's size. 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> &bar; </mo>
     </munder>
     <mfrac>
        <mi> a </mi>
        <mi> b </mi>
     </mfrac>
     <mover>
        <mo> ) </mo>
        <mo> &bar; </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.

Example of stretchy attributes:

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] as opposed to the default rendering  [Graphics: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.

Vertical Stretching Rules:

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 cover exactly one row. (Equivalently, the value of the rowspan attribute is assumed to be 1 for all the table cells in the table 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.

Horizontal Stretching Rules:

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 cover exactly one column. (Equivalently, the value of the columnspan attribute is assumed to be 1 for all the table cells in the table 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].

Rules Common to both Vertical and Horizontal Stretching:

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.

Other attributes of <mo>

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 environment. 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 exception 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.

3.2.5 <mtext> -- text

Description:

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 (other than as single blanks between non-whitespace characters).

Renderable whitespace can have a positive or negative width, as in "&thinspace;" and "&negativethinspace;", or zero width, as in "&zerowidthspace;". 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.

Attributes of <mtext>:

<mtext> elements accept the attributes listed in Section 3.2.1.

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.

Examples of <mtext>:

  <mtext> Theorem 1: </mtext>

  <mtext> &thinspace; </mtext>

  <mtext> &thickspace;&thickspace; </mtext>

  <mtext> /* a comment */ </mtext>

Mixing text and math

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] is equivalent to  [Graphics: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]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]  [Graphics: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, and may or may not render appropriately. By contrast, an ellipsis entity in an <mi> element is apt to render better than three periods inside an <mtext> element.

3.2.6 <mspace/> -- space

Description:

An <mspace/> empty element represents a blank space of any desired size, as set by its attributes. The default value for each attribute is 0, so it will not be useful without some attributes specified.

Attributes of <mspace/>:

Name  values  default 
width number   (ems) 0
height number   (exs) 0
depth number   (exs) 0

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/>;

Definition of spacelike elements

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 exception ways in other MathML expression. 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 to aligning expression, operators adjacent to an <mphantom> should behave as if they were adjacent to the contents of the <mphantom>, and not an equivalently sized area of whitespace.

Legal grouping of spacelike elements

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.

3.2.7 <ms> -- string literal

Description:

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 specified by they can contain 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, they are even more general than that, 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.

Attributes of <ms>:

<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 \"".


Next: Presentation Markup -- General Layout Schemata
Up: Table of Contents