As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 140439 - render MathML &prime; as a mathematical prime in contexts other than <msup>
: render MathML &prime; as a mathematical prime in contexts other than <msup>
Status: RESOLVED DUPLICATE of bug 442637
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Depends on:
  Show dependency treegraph
Reported: 2002-04-26 15:07 PDT by Torsten Bronger
Modified: 2013-10-27 07:18 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Torsten Bronger 2002-04-26 15:07:26 PDT
&prime; should result in $'$, not in $\prime$.
Comment 1 User image rbs 2002-04-26 16:39:01 PDT
What do you mean? 'prime' is an overloaded character.
Do you have a testcase/screenshot of what you see?
Comment 2 User image rbs 2002-04-28 11:33:56 PDT
I got the following explanation from the reporter:

> The MathML equivalent of LaTeX's $f'$ should be
> <math><mi>f</mi><mo>&prime;</mo></math>, but
> at the moment it's
> <math><msup><mi>f</mi><mo>&prime;</mo></msup></math>

It makes the bug report clear now. However, it isn't what the spec says. In
fact, the issue came up in the n.p.m.mathml newsgroup and the WG confirmed that
what Mozilla does is OK, though it was suggested that the other behavior could
be an enhancement. So this bug is a RFE.


Post from Robert Miner on the question:

> The question of marking up primes has come up several times with the
> Math WG, and everytime we have decided that in MathML, a prime should
> be attached as a superscript, eg
> <msup> <mi>f</mi> <mo>&prime;</mo>  </msup>
> The strongest argument is that this makes explicit to what the prime
> applies.

Updating the title to reflect the reality:
OLD title was: "MahML entity &prime; is wrongly interpreted"
NEW title is: "[RFE] render MathML &prime; as a mathematical prime in contexts
other than <msup>"

This could become a non-issue if generators become good enough.
Comment 3 User image Hixie (not reading bugmail) 2002-05-12 08:24:27 PDT
What about when the prime is not an operator? e.g. is

   <msup> <mi>k</mi> <mo>&prime;</mo>  </msup>

...preferred over 


...when trying to tell the difference between the variable /k/ and the related
but distinct variable /k'/ ?
Comment 4 User image rbs 2002-05-12 13:35:03 PDT
That's is all quirky... "<mi>k&prime;</mi>" is always understooned means the
identifier k' (i.e., concat of a glyph for k and  a glyph for ' -- nothing
special expected). It is a very bad (MathML) markup for that purpose.

Anyway, I have little interest in seeing this bug fixed (I am tempted to mark
WONTFIX :-) As roc jotted in the other bug 121748, any quirk that is implemented
is likely to last forever, whereas generators can improve -- in which case, this
bug will become a non-issue.
Comment 5 User image rbs 2002-05-12 14:16:17 PDT
s/That's is all quirky... "<mi>k&prime;</mi>" is always understooned means/
 /That's all quirky... "<mi>k&prime;</mi>" is always understood to mean/
Comment 6 User image Hixie (not reading bugmail) 2002-05-12 14:52:38 PDT
Cool, so what should I use instead?

   <msup> <mi>k</mi> <mo>&prime;</mo>  </msup>


   <msup> <mi>k</mi> <mi>&prime;</mi>  </msup>


I'm kinda confused as to which is appropriate... In this context, the &prime; is
not an operator (which would imply differentiation), is it an identifier?
Comment 7 User image rbs 2002-05-12 15:16:50 PDT
>  <msup> <mi>k</mi> <mo>&prime;</mo>  </msup>

yes this is the recommended markup. (if you were to 'hint' at
differentiation, you could do: <msup> <mo>k</mo> <mo>&prime;</mo> </msup>)

>  <msup> <mi>k</mi> <mi>&prime;</mi>  </msup>

In general, there isn't much that is done for '<mi>' (except the special-casing 
of non-stylable characters such as set R, or the italicized rendering in the 
case where the textual content consists of a single character). It is <mo> that 
is heavily overloaded (it is looked-up in the Operator Dictionary, and not only 
its content is significant, its position plays a role too -- whether it is 
prefix, infix, or suffix). So as a rule of thumb, '<mi>' is for things that are 
meant to be (italicized) identifiers while '<mo>' is for other things.
Comment 8 User image Hixie (not reading bugmail) 2002-05-12 15:38:37 PDT
Alrighty. Thanks for the help!
Comment 9 User image Torsten Bronger 2004-12-13 12:56:34 PST
My Firefox 1.0 now shows it as I wanted it to be.  Is this a "meta" bug or has
the policy changed?
Comment 10 User image William F. Hammond 2007-01-06 15:27:50 PST
I doubt if it's still working as Torsten wanted in Firefox

There is inconsistency, both in Linux and WinXP, in the presentation
handling of &prime; and &Prime; (double prime).  The latter works
sanely as a postfix operator, while the former does not.  With
&prime;, however, there is an acceptable CSS workaround using
{vertical-align: super; font-size: 0.6em} for the <mo> container that
mostly -- but not always works.  See the XHTML page
and the pictures and

I say the CSS snippet is an acceptable workaround
because for most purposes &prime is used by mathematical authors
as a superscripted postfix math accent (see Lamport's sample2e.tex).
For GELLMU I am reluctant to step on an author's usage by
superscripting it in the XML behind his back; touching it with CSS
is much less of an infringement.  On the other side, if I tell
the author he must superscript it, he will walk away.

I think the MathML spec at section needs revision.

For Mozilla meanwhile please make &prime; behave like &Prime;.

Also I'm not happy with the response above to Ian Hixie; I think,
in fact, <mi>k&prime;</mi> is a sensible math token.  Otherwise
one is messing with cdata rather arbitrarily.  (The spec provides
for this inside <mo> but mostly not inside <mi>.)

For case distinctions attribute settings on the <mo> container should
be the best way to go -- with postfix superscripting the default --
when the content is one of prime, Prime, tprime, qprime.


Comment 11 User image William F. Hammond 2007-01-13 19:37:46 PST
In case the thrust of my comment a week ago is insufficiently
clear, I have written a slightly more elaborate version of the
first http reference in that comment.  It may be found at:

Comment 12 User image Frédéric Wang (:fredw) 2013-09-06 08:55:44 PDT
The MathJax fonts render the prime at the right size, so that may explain why some people see this bug "fixed". For the STIX fonts, font-feature-settings can be used to select an alternative glyph. Compare

    <math style="font-family: STIX;">
      <msup><mi>x</mi><mo style="-moz-font-feature-settings: 'ss03'">&#x2032;</mo></msup>

(however, this will be font specific)
Comment 13 User image Frédéric Wang (:fredw) 2013-10-27 07:18:17 PDT

*** This bug has been marked as a duplicate of bug 442637 ***

Note You need to log in before you can comment on or make changes to this bug.