The prime accents


  1. BugZilla # 140439 originally reported by Torsten Bronger on 26 April 2002.
  2. primes in the W3C MathML Test Suite


  1. Firefox treats (′) differently from (″) both in Linux and in Windows XP.
  2. The treatment of can probably be improved by making it parallel to the treatment of .
  3. In some cases the use of the CSS vertical-align property is an acceptable workaround for Mozilla's handling of as a postfix operator.

The primes should by default be postfix accents that are automatically raised.

It corresponds to what mathematical authors expect, and it corresponds to the rendering of these Unicode points in normal HTML text. (There is more on this below in connection with strings of length greater than 1 as the content of an mi element.)

But note: There are two LaTeX commands in which “prime” is a substring of the command name: \prime and \backprime (the latter is provided by the LaTeX package amssymb). When used directly, their display appears to be parallel to the display of an operator like \cdot or \osum, i.e., midline, and, for example, the LaTeX markup $f^{\prime}$ appears to be equivalent to the markup $f'$. The MathML specification should address the possibility of midline use for the Unicode entities prime and backprime as opposed to normal use as raised postfix and prefix accents.

Below here prime and double-prime accents are handled either using <msup> or using the CSS vertical-align property with value “super” along with the attribute specification form="postfix" in postfix operator markup on single prime (but not on double prime) accents.

This x and this y use and as postfix operators, while <msup> is used here: x and y.

These are display mode:

x=y+z (postfix)


These are in 1×1 mtables in displaymath:


x=y+z (superscripted)

In some user agents there are font problems when U-2032 and U-2033 are used directly rather than by entity reference.

x=y+z (postfix, no mtable)

x=y+z(postfix in mtable)

About mi content

First observe that in regular HTML text the characters , , , and should all function in normal parallel fashion (apart from temporary font set mismatching) as postfix text accents. Witness: H′, H″, H‴, H⁗.

Is there any reason why this behavior should not be preserved when these prime accents are used without other markup inside presentation math symbol indicators (<mi>)? That is if one can easily write, using the Armenian letter peh,

պ = (պ′, պ″)

in ordinary HTML text, why should things not flow easily, as the mathematical author would obviously hope, when պ′ or պ″ is the sole content of an mi as in: պ= պ′պ″ ?

Various symbols marked up only in mi are here: H,Hom,H', H'',H′,H″, H‴,H″′, H⁗,H″″ .

This H′′ involves inline use of two primes in an mo that is styled for raising, and this H is similar but with two consecutive mos.

In connection with these examples, note that it is both Mozilla behavior and the long-standing TeX custom that a math symbol denoted with more than one alphabetical character is rendered upright (and, therefore, as if in the HTML namespace). When counting characters in a Unicode string for this purpose, only “word” characters, in the sense of regular expression terminology, should be used.

Tangential Comments:

  1. The entity name Prime is not parallel to the other similarly-purposed entity names (tprime and qprime, as well as prime). It would be good to make dprime a duplicate entity name for Prime.
  2. The second paragraph of section in the MathML specification needs work. While it makes sense to special case various items of CDATA in presentation operators (mo), it may or may not make sense in presentation symbol indicators (mi). If it makes sense, then it should be laid out more systematically.