**References:**

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

- Firefox 1.5.0.9 treats
`′`(`′`) differently from`″`(`″`) both in Linux and in Windows XP. - The treatment of
`′`can probably be improved by making it parallel to the treatment of`″`. - 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\prime $ and this $y\u2033$ use `′` and `″` as postfix operators,
while `<msup>` is used here:
${x}^{\prime}$ and ${y}^{\u2033}$.

$$x\prime =y+z\u2033\phantom{\rule{2em}{0ex}}\text{(postfix)}$$

$${x}^{\prime}=y+{z}^{\u2033}\phantom{\rule{2em}{0ex}}\text{(superscripted)}$$

These are in 1×1 *mtables* in displaymath:

$$\begin{array}{c}x\prime =y+z\u2033\end{array}\phantom{\rule{2em}{0ex}}\text{(postfix)}$$

$$\begin{array}{c}{x}^{\prime}=y+{z}^{\u2033}\end{array}\phantom{\rule{2em}{0ex}}\text{(superscripted)}$$

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

$$x\prime =y+z\u2033\phantom{\rule{2em}{0ex}}\text{(postfix, no mtable)}$$

$$\begin{array}{c}x\prime =y+z\u2033\end{array}\phantom{\rule{2em}{0ex}}\text{(postfix in mtable)}$$

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:
$$\mathrm{\u057a}=\left(\mathrm{\u057a\prime},\mathrm{\u057a\u2033}\right)\phantom{\rule{1em}{0ex}}\text{?}$$

Various symbols marked up only in *mi* are here:
$H,\mathrm{Hom},\mathrm{H\text{'}},\mathrm{H\text{'}\text{'}},\mathrm{H\prime},\mathrm{H\u2033},\mathrm{H\u2034},\mathrm{H\u2033\prime},\mathrm{H\u2057},\mathrm{H\u2033\u2033}$.

This $H\prime \prime $ involves inline
use of two *prime*s in an *mo* that is styled for
raising, and this $H\prime \prime $
is similar but with two consecutive *mo*s.

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.

- 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*. - The second paragraph of section 3.2.3.1 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.