Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add workarounds for Webkit Native MathML #482

Closed
fred-wang opened this issue May 24, 2013 · 31 comments

Comments

Projects
None yet
4 participants
@fred-wang
Copy link
Contributor

commented May 24, 2013

When Dave Barton's changes are in the WebKit release, we could add some workarounds in the native MathML output.

WebKit default stylesheet is
http://trac.webkit.org/browser/trunk/Source/WebCore/css/mathml.css

Main issues to fix:

  1. Italic with multiple-letters mi. MathJax could force the font-style
   <p><math><mi style="font-style: normal;">sin</mi></math></p>
  1. mmultiscripts. Dave suggested to use nested msubsup. Since scripts are currently shifted by a constant amount in WebKit, the scripts remain aligned. I just realized that I'm not really sure about how Dave suggested to do the prescripts or the none script. But here is an example:
   <p>
     <math>
     <msub>
       <msubsup>
         <mtext></mtext><mtext></mtext><mn>7</mn>
       </msubsup>
       <mn>8</mn>
     </msub>
     <msubsup>
       <msubsup>
         <msubsup><mi>x</mi><mn>0</mn><mn>1</mn></msubsup>
         <mn>3</mn><mn>4</mn>
       </msubsup>
      <mn>5</mn><mn>6</mn>
     </msubsup> 
     </math>
   </p>
  1. operator dictionary/lspace/rspace. Here we can let MathJax use the Operator dictionary to add spaces around the mo element. To implement lspace/rspace, what I said yesterday was not quite correct, the CSS properties to consider are -webkit-margin-start/-webkit-margin-end rather than padding-left/padding-right:
  <p><math><mi>x</mi><mo style="-webkit-margin-start: 2em; -webkit-margin-end: 2em;">+</mo><mi>y</mi></math></p>

Here is a screenshot of the previous examples in a WebKit trunk build (Nightly builds can be downloaded from http://nightly.webkit.org/):

tweaked-webkit-mathml

(Hopefully we don't have the Opera bug and style changes can be done via Javascript)

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2013

The mspace element with nonnegative width/depth can also be simulated that way:

   <p><math><mi>x</mi><mtext><span style="background: red; display: inline-block; vertical-align: -4em; width: 3em; height: 6em;"></span></mtext><mi>y</mi></math></p>
@pkra

This comment has been minimized.

Copy link
Member

commented May 24, 2013

Nice! Just so that I don't forget to put it somewhere: tweaking MathML also creates problems. For example, accessibility tools such as MathPlayer, ChromeVox and future tools need a clean MathML. We should create APIs to get/switch tweaked MathML versions.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2013

Yes, but the modifications of the MathML are done during the output phase (native MathML) and we only do that to the relevant rendering engine (the Safari+Webkit version that Dave mentioned). So here that should not be a problem. That could be a problem with ChromeVox if we apply these modifications to Chrome in the future.

@ghost ghost assigned fred-wang May 29, 2013

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 24/05/2013 18:06, pkra wrote:

Nice! Just so that I don't forget to put it somewhere: tweaking MathML
also creates problems. For example, accessibility tools such as
MathPlayer, ChromeVox and future tools need a clean MathML. We should
create APIs to get/switch tweaked MathML versions.

Quick question to Dave: WebKit mathml.css only has
-webkit-margin-start/-webkit-margin-end rules on mo elements that are
children of math/mrow/mo/msqrt/mtd. Is there any reason for this
restriction?

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

I've created a branch with the suggested workarounds. For mspace, I only implemented nonnegative width (the suggestion I made above needed parsing the length and I don't really want to take the HTML-CSS code). Note that the workaround for lspace/rspace also works with negative lengths. Feedback is welcome, especially from Dave as he knows WebKit better than me.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On May 29, 2013, at 4:25 AM, Frédéric WANG wrote:

On 24/05/2013 18:06, pkra wrote:

Nice! Just so that I don't forget to put it somewhere: tweaking MathML also creates problems. For example, accessibility tools such as MathPlayer, ChromeVox and future tools need a clean MathML. We should create APIs to get/switch tweaked MathML versions.

Quick question to Dave: WebKit mathml.css only has -webkit-margin-start/-webkit-margin-end rules on mo elements that are children of math/mrow/mo/msqrt/mtd. Is there any reason for this restriction?

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

Sorry, I should have commented this css. These are the and implicit cases (in webkit MathML so far). There's this sentence in the spec:

3.2.5.7.5 Spacing around an operator

The amount of horizontal space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes.

I'm a little confused by this because of the implicit rule. But it seems that e.g. in Chemistry, where a bare "+" might occur as a superscript for instance, the spec is maybe saying that there shouldn't be any space around it. (I'm cc'ing the spec experts because they may want to comment on this.)

Another note is that I use margins (-webkit-margin-start/-webkit-margin-end) instead of padding partly to allow negative values, as I recall.

Hope this helps, Dave B.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and
implicit cases (in webkit MathML so far).
That's what I suspected, but I'm wondering why you need to list all the
elements and whether just mo { ... } would be ok (assuming the parent is
a flex box). In the MathJax workaround, I always set
-webkit-margin-start/-webkit-margin-end without checking what the parent
is.
I'm a little confused by this because of the implicit rule. But
it seems that e.g. in Chemistry, where a bare "+" might occur as a
superscript for instance, the spec is maybe saying that there
shouldn't be any space around it. (I'm cc'ing the spec experts because
they may want to comment on this.)
For the MathJax workaround I'm not really willing to consider all the
embellished op and implicit mrow stuff, just to put the space given by
the operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

 \( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the
MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On May 29, 2013, at 10:28 AM, Frédéric WANG wrote:

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and implicit cases (in webkit MathML so far).
That's what I suspected, but I'm wondering why you need to list all the elements and whether just mo { ... } would be ok (assuming the parent is a flex box). In the MathJax workaround, I always set -webkit-margin-start/-webkit-margin-end without checking what the parent is.

My reading of the spec sentence I quoted was that space (from lspace/rspace or the operator dictionary or other defaults) should only be added automatically around an operator if it's in an . Hence I didn't add it to all mo elements.

I'm a little confused by this because of the implicit rule. But it seems that e.g. in Chemistry, where a bare "+" might occur as a superscript for instance, the spec is maybe saying that there shouldn't be any space around it. (I'm cc'ing the spec experts because they may want to comment on this.)
For the MathJax workaround I'm not really willing to consider all the embellished op and implicit mrow stuff, just to put the space given by the operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

( \cf{^{227}_{90}Th+} )

(even if I addthe config useMathMLspacing: true or if I remove the MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

I'm not quite sure what the question is. If it is when do you
lspace/rspace/default spacing rules, then the answer is that they only
apply when in an mrow. From
http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount of
horizontal space added around an operator (or embellished operator), when
it occurs in an mrow, can be directly specified by the lspace and
rspaceattributes." Note that it says a bit later on in that section,
"Some
renderers may choose to use no space around most operators appearing within
subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat
an mrowelement containing exactly one argument as equivalent in all
ways to the
single argument occurring alone, provided there are no attributes on the
mrow element."

 Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.fr wrote:

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and
implicit cases (in webkit MathML so far).

That's what I suspected, but I'm wondering why you need to list all the
elements and whether just mo { ... } would be ok (assuming the parent is a
flex box). In the MathJax workaround, I always set
-webkit-margin-start/-webkit-**margin-end without checking what the
parent is.

I'm a little confused by this because of the implicit rule. But it
seems that e.g. in Chemistry, where a bare "+" might occur as a superscript
for instance, the spec is maybe saying that there shouldn't be any space
around it. (I'm cc'ing the spec experts because they may want to comment on
this.)

For the MathJax workaround I'm not really willing to consider all the
embellished op and implicit mrow stuff, just to put the space given by the
operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

\( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the
MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/**blog/frederichttp://maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

Thanks! I think you've answered my question - technically (ideally) the bare superscript mo shouldn't have the spacing added.

I think my old confusion about single-argument is that your equivalence is not symmetric, maybe? That is, an with exactly one argument and no attributes should essentially be converted to just its argument for rendering purposes, so e.g. in this case there would be no spacing added? However, the automatic conversion doesn't go the other direction (because then the spacing would be added)?

For the record, I don't really like this "in all ways" rule. For purposes like applying CSS selectors, handling precedences, and some other things (maybe stretching, embellished op rules, etc.) I've found it convenient for an with one argument to actually be an .

Cheers, Dave B.

On May 29, 2013, at 10:41 AM, Neil Soiffer wrote:

I'm not quite sure what the question is. If it is when do you lspace/rspace/default spacing rules, then the answer is that they only apply when in an mrow. From http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount of horizontal space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes." Note that it says a bit later on in that section, "Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat an mrow element containing exactly one argument as equivalent in all ways to the single argument occurring alone, provided there are no attributes on the mrow element."

 Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.fr wrote:
On 29/05/2013 19:00, Dave Barton wrote:
Sorry, I should have commented this css. These are the and implicit cases (in webkit MathML so far).
That's what I suspected, but I'm wondering why you need to list all the elements and whether just mo { ... } would be ok (assuming the parent is a flex box). In the MathJax workaround, I always set -webkit-margin-start/-webkit-margin-end without checking what the parent is.
I'm a little confused by this because of the implicit rule. But it seems that e.g. in Chemistry, where a bare "+" might occur as a superscript for instance, the spec is maybe saying that there shouldn't be any space around it. (I'm cc'ing the spec experts because they may want to comment on this.)
For the MathJax workaround I'm not really willing to consider all the embellished op and implicit mrow stuff, just to put the space given by the operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

\( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 29/05/2013 18:41, Dave Barton wrote:

My reading of the spec sentence I quoted was that space (from
lspace/rspace or the operator dictionary or other defaults) should
only be added automatically around an operator if it's in an .
Hence I didn't add it to all mo elements.

this however (as almost all mention of mrow) includes implict mrow

the spacing of + in

a+b

should be the same in an implict mrow such as mtd or mroot as in an
explicit mrow.

David

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 29/05/2013 19:57, Dave Barton wrote:

Thanks! I think you've answered my question - technically (ideally)
the bare superscript mo shouldn't have the spacing added.

OK, Gecko always add lspace/rspace so it should instead ignore it in
e.g. superscript

I think my old confusion about single-argument is that your
equivalence is not symmetric, maybe? That is, an with exactly
one argument and no attributes should essentially be converted to just
its argument for rendering purposes, so e.g. in this case there would
be no spacing added? However, the automatic conversion doesn't go the
other direction (because then the spacing would be added)?
I think the conversion goes the other direction because
+ is an embellished operator so you apply the
lspace/rspace rule to the whole mrow rather than the core mo.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

It should be symmetric. If you have an mrow with one argument and no
attrs, then you can just remove the mrow. So no spacing added. If for
some reason you want to add an mrow (e.g., you want the children of
to always be in an mrow since one is implicit), the rule still applies (no
spacing). Adding or removing an mrow is an implementation decision, but
whatever the implementation does, it still needs to follow the equivalence
rule in MathML.

 Neil

On Wed, May 29, 2013 at 10:57 AM, Dave Barton dbarton@mathscribe.comwrote:

Thanks! I think you've answered my question - technically (ideally) the
bare superscript mo shouldn't have the spacing added.

I think my old confusion about single-argument is that your
equivalence is not symmetric, maybe? That is, an with exactly one
argument and no attributes should essentially be converted to just its
argument for rendering purposes, so e.g. in this case there would be no
spacing added? However, the automatic conversion doesn't go the other
direction (because then the spacing would be added)?

For the record, I don't really like this "in all ways" rule. For purposes
like applying CSS selectors, handling precedences, and some other things
(maybe stretching, embellished op rules, etc.) I've found it convenient for
an with one argument to actually be an .

Cheers, Dave B.

On May 29, 2013, at 10:41 AM, Neil Soiffer wrote:

I'm not quite sure what the question is. If it is when do you
lspace/rspace/default spacing rules, then the answer is that they only
apply when in an mrow. From
http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount
of horizontal space added around an operator (or embellished operator),
when it occurs in an mrow, can be directly specified by the lspace and
rspace attributes." Note that it says a bit later on in that section,
"Some renderers may choose to use no space around most operators appearing
within subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat an
mrow element containing exactly one argument as equivalent in all ways to
the single argument occurring alone, provided there are no attributes on
the mrow element."

 Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.fr wrote:

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and
implicit cases (in webkit MathML so far).

That's what I suspected, but I'm wondering why you need to list all the
elements and whether just mo { ... } would be ok (assuming the parent is a
flex box). In the MathJax workaround, I always set
-webkit-margin-start/-webkit-**margin-end without checking what the
parent is.

I'm a little confused by this because of the implicit rule. But
it seems that e.g. in Chemistry, where a bare "+" might occur as a
superscript for instance, the spec is maybe saying that there shouldn't be
any space around it. (I'm cc'ing the spec experts because they may want to
comment on this.)

For the MathJax workaround I'm not really willing to consider all the
embellished op and implicit mrow stuff, just to put the space given by the
operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

\( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the
MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/**blog/frederichttp://maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On May 29, 2013, at 11:02 AM, David Carlisle wrote:

On 29/05/2013 18:41, Dave Barton wrote:

My reading of the spec sentence I quoted was that space (from
lspace/rspace or the operator dictionary or other defaults) should
only be added automatically around an operator if it's in an .
Hence I didn't add it to all mo elements.

this however (as almost all mention of mrow) includes implict mrow

the spacing of + in

a+b

should be the same in an implict mrow such as mtd or mroot as in an explicit mrow.

David

Right, if this whole thing is inside an or implicit , there should be spacing. This is what I wrote in my css rule. - Dave B

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

But this isn't symmetric. The rule is that if you're in an , add the space. - Dave B.

On May 29, 2013, at 11:09 AM, Neil Soiffer wrote:

It should be symmetric. If you have an mrow with one argument and no attrs, then you can just remove the mrow. So no spacing added. If for some reason you want to add an mrow (e.g., you want the children of to always be in an mrow since one is implicit), the rule still applies (no spacing). Adding or removing an mrow is an implementation decision, but whatever the implementation does, it still needs to follow the equivalence rule in MathML.

 Neil

On Wed, May 29, 2013 at 10:57 AM, Dave Barton dbarton@mathscribe.com wrote:
Thanks! I think you've answered my question - technically (ideally) the bare superscript mo shouldn't have the spacing added.

I think my old confusion about single-argument is that your equivalence is not symmetric, maybe? That is, an with exactly one argument and no attributes should essentially be converted to just its argument for rendering purposes, so e.g. in this case there would be no spacing added? However, the automatic conversion doesn't go the other direction (because then the spacing would be added)?

For the record, I don't really like this "in all ways" rule. For purposes like applying CSS selectors, handling precedences, and some other things (maybe stretching, embellished op rules, etc.) I've found it convenient for an with one argument to actually be an .

Cheers, Dave B.

On May 29, 2013, at 10:41 AM, Neil Soiffer wrote:

I'm not quite sure what the question is. If it is when do you lspace/rspace/default spacing rules, then the answer is that they only apply when in an mrow. From http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount of horizontal space added around an operator (or embellished operator), when it occurs in an mrow, can be directly specified by the lspace and rspace attributes." Note that it says a bit later on in that section, "Some renderers may choose to use no space around most operators appearing within subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat an mrow element containing exactly one argument as equivalent in all ways to the single argument occurring alone, provided there are no attributes on the mrow element."

 Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.fr wrote:
On 29/05/2013 19:00, Dave Barton wrote:
Sorry, I should have commented this css. These are the and implicit cases (in webkit MathML so far).
That's what I suspected, but I'm wondering why you need to list all the elements and whether just mo { ... } would be ok (assuming the parent is a flex box). In the MathJax workaround, I always set -webkit-margin-start/-webkit-margin-end without checking what the parent is.
I'm a little confused by this because of the implicit rule. But it seems that e.g. in Chemistry, where a bare "+" might occur as a superscript for instance, the spec is maybe saying that there shouldn't be any space around it. (I'm cc'ing the spec experts because they may want to comment on this.)
For the MathJax workaround I'm not really willing to consider all the embellished op and implicit mrow stuff, just to put the space given by the operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

\( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 29/05/2013 20:16, Dave Barton wrote:

But this isn't symmetric. The rule is that if you're in an , add
the space. - Dave B.
It's not the but the whole that you are considering. And
since that is not in an , you don't add the space.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

The rule is if you are in an mrow with more than one element, you apply
the spacing rules. The symmetry is that adding it or removing it doesn't
affect the rendering.

Neil

On Wed, May 29, 2013 at 11:16 AM, Dave Barton dbarton@mathscribe.comwrote:

But this isn't symmetric. The rule is that if you're in an , add the
space. - Dave B.

On May 29, 2013, at 11:09 AM, Neil Soiffer wrote:

It should be symmetric. If you have an mrow with one argument and no
attrs, then you can just remove the mrow. So no spacing added. If for
some reason you want to add an mrow (e.g., you want the children of
to always be in an mrow since one is implicit), the rule still applies (no
spacing). Adding or removing an mrow is an implementation decision, but
whatever the implementation does, it still needs to follow the equivalence
rule in MathML.

 Neil

On Wed, May 29, 2013 at 10:57 AM, Dave Barton dbarton@mathscribe.comwrote:

Thanks! I think you've answered my question - technically (ideally) the
bare superscript mo shouldn't have the spacing added.

I think my old confusion about single-argument is that your
equivalence is not symmetric, maybe? That is, an with exactly one
argument and no attributes should essentially be converted to just its
argument for rendering purposes, so e.g. in this case there would be no
spacing added? However, the automatic conversion doesn't go the other
direction (because then the spacing would be added)?

For the record, I don't really like this "in all ways" rule. For purposes
like applying CSS selectors, handling precedences, and some other things
(maybe stretching, embellished op rules, etc.) I've found it convenient for
an with one argument to actually be an .

Cheers, Dave B.

On May 29, 2013, at 10:41 AM, Neil Soiffer wrote:

I'm not quite sure what the question is. If it is when do you
lspace/rspace/default spacing rules, then the answer is that they only
apply when in an mrow. From
http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount
of horizontal space added around an operator (or embellished operator),
when it occurs in an mrow, can be directly specified by the lspace and
rspace attributes." Note that it says a bit later on in that section,
"Some renderers may choose to use no space around most operators appearing
within subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat an
mrow element containing exactly one argument as equivalent in all ways
to the single argument occurring alone, provided there are no attributes on
the mrow element."

 Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.frwrote:

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and
implicit cases (in webkit MathML so far).

That's what I suspected, but I'm wondering why you need to list all the
elements and whether just mo { ... } would be ok (assuming the parent is a
flex box). In the MathJax workaround, I always set
-webkit-margin-start/-webkit-**margin-end without checking what the
parent is.

I'm a little confused by this because of the implicit rule. But
it seems that e.g. in Chemistry, where a bare "+" might occur as a
superscript for instance, the spec is maybe saying that there shouldn't be
any space around it. (I'm cc'ing the spec experts because they may want to
comment on this.)

For the MathJax workaround I'm not really willing to consider all the
embellished op and implicit mrow stuff, just to put the space given by the
operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

\( \cf{^{227}_{90}Th+} \)

(even if I addthe config useMathMLspacing: true or if I remove the
MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/**blog/frederichttp://maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2013

On 29/05/2013 20:16, Dave Barton wrote:

But this isn't symmetric. The rule is that if you're in an , add the space. - Dave B.
It's not the but the whole that you are considering. And since that is not in an , you don't add the space.

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

The rule is if you are in an mrow with more than one element, you apply the spacing rules. The symmetry is that adding it or removing it doesn't affect the rendering.

Neil

Thanks! I think I finally get it, an with one (non-space-like) argument is an embellished operator, as Fred says. Sorry for the confusion. - Dave B.

@dpvc

This comment has been minimized.

Copy link
Member

commented May 29, 2013

What about

a + b

Since the inner mrow has only one element, the mo it contains should have no space, but since you are supposed to treat that mrow with one element as though it were jus that mo element without the mrow, it would be in the multi-element outer mrow, and so SHOULD get space. Which rule wins? Or am I misunderstanding?

Davide

On May 29, 2013, at 2:25 PM, Frédéric Wang wrote:

The rule is if you are in an mrow with more than one element, you apply
the spacing rules. The symmetry is that adding it or removing it doesn't
affect the rendering.

Neil

On Wed, May 29, 2013 at 11:16 AM, Dave Barton dbarton@mathscribe.comwrote:

But this isn't symmetric. The rule is that if you're in an , add the
space. - Dave B.

On May 29, 2013, at 11:09 AM, Neil Soiffer wrote:

It should be symmetric. If you have an mrow with one argument and no
attrs, then you can just remove the mrow. So no spacing added. If for
some reason you want to add an mrow (e.g., you want the children of
to always be in an mrow since one is implicit), the rule still applies (no
spacing). Adding or removing an mrow is an implementation decision, but
whatever the implementation does, it still needs to follow the equivalence
rule in MathML.

Neil

On Wed, May 29, 2013 at 10:57 AM, Dave Barton dbarton@mathscribe.comwrote:

Thanks! I think you've answered my question - technically (ideally) the
bare superscript mo shouldn't have the spacing added.

I think my old confusion about single-argument is that your
equivalence is not symmetric, maybe? That is, an with exactly one
argument and no attributes should essentially be converted to just its
argument for rendering purposes, so e.g. in this case there would be no
spacing added? However, the automatic conversion doesn't go the other
direction (because then the spacing would be added)?

For the record, I don't really like this "in all ways" rule. For purposes
like applying CSS selectors, handling precedences, and some other things
(maybe stretching, embellished op rules, etc.) I've found it convenient for
an with one argument to actually be an .

Cheers, Dave B.

On May 29, 2013, at 10:41 AM, Neil Soiffer wrote:

I'm not quite sure what the question is. If it is when do you
lspace/rspace/default spacing rules, then the answer is that they only
apply when in an mrow. From
http://www.w3.org/TR/MathML3/chapter3.html#presm.opspacing, "The amount
of horizontal space added around an operator (or embellished operator),
when it occurs in an mrow, can be directly specified by the lspace and
rspace attributes." Note that it says a bit later on in that section,
"Some renderers may choose to use no space around most operators appearing
within subscripts or superscripts, as is done in TEX."

Note also that the spec says "MathML renderers are required to treat an
mrow element containing exactly one argument as equivalent in all ways
to the single argument occurring alone, provided there are no attributes on
the mrow element."

Neil

On Wed, May 29, 2013 at 10:28 AM, Frédéric WANG fred.wang@free.frwrote:

On 29/05/2013 19:00, Dave Barton wrote:

Sorry, I should have commented this css. These are the and
implicit cases (in webkit MathML so far).

That's what I suspected, but I'm wondering why you need to list all the
elements and whether just mo { ... } would be ok (assuming the parent is a
flex box). In the MathJax workaround, I always set
-webkit-margin-start/-webkit-**margin-end without checking what the
parent is.

I'm a little confused by this because of the implicit rule. But
it seems that e.g. in Chemistry, where a bare "+" might occur as a
superscript for instance, the spec is maybe saying that there shouldn't be
any space around it. (I'm cc'ing the spec experts because they may want to
comment on this.)

For the MathJax workaround I'm not really willing to consider all the
embellished op and implicit mrow stuff, just to put the space given by the
operator dictionary or attributes around mo elements.

It seems that MathJax does not put space around the + exponent in

( \cf{^{227}_{90}Th+} )

(even if I addthe config useMathMLspacing: true or if I remove the
MJX-TeXAtom- classes) but Gecko does.

Frédéric Wang
maths-informatique-jeux.com/**blog/frederichttp://maths-informatique-jeux.com/blog/frederic


Reply to this email directly or view it on GitHub.

@dpvc

This comment has been minimized.

Copy link
Member

commented May 29, 2013

an with one (non-space-like) argument is an embellished operator, as Fred says.

I guess that answers my question, too, since then my example has the inner mrow as an embellished operator and so it gets space that way. Makes sense.

Davide

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

So I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=877563 and
I'm trying to modify the workaround for WebKit. But I'm still not sure
what is the expected behavior. For example:

  1. x+y
  2. <x+y
  3. Li+
  4. +Li
  5. Li+

I think MathML only says that the lspace/rspace attributes apply in test

  1. (mrow) and 2) (inferred mrow). The others are not mrow or inferred
    mrow, 3) is a script and maybe 5) too.

Gecko currently adds space in all cases and MathJax adds space in 1), 2)
3), 4) but not 5). I haven't tried with MathPlayer.

Perhaps the MathML says that the only requirement is in mrow/inferred
mrow and that the implementers are free to choose the spacing in other
cases?

Frédéric Wang
maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

So IIUC the spec, applying MathJax's lspace/rspace to mo element when "p = this.parent; p && p.type === "mrow" && (p.inferred || !p.isEmbellished())" is true and setting it to 0 otherwise could be a reasonable behavior. That will give the correct spacing for all but the last case here:

 <math><mrow><mi>x</mi><mo lspace="2em" rspace="2em">+</mo><mi>y</mi></mrow></math>
 <math><msqrt><mi>x</mi><mo lspace="2em" rspace="2em">+</mo><mi>y</mi></msqrt></math>
 <math><msup><mi>Li</mi><mo lspace="2em" rspace="2em">+</mo></math>
 <math><msup><mi>Li</mi><mrow><mo lspace="2em" rspace="2em">+</mo></mrow></math>
 <math><mi>x</mi><mrow><mo lspace="2em" rspace="2em">+</mo></mrow><mi>y</mi></math>

(however, Gecko and MathJax always add the spacing around the embellished op in all these cases so I'm still not sure exactly about the spec)

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

Yes, spacing rules only apply in cases 1 & 2.

Implementers are free to choose the placement of scripts, etc., but
lspace/rspace should not be a part of that choice since they only apply
when inside of an (implied) mrow (with more than one arg).

Neil

On Thu, May 30, 2013 at 12:55 AM, Frédéric WANG fred.wang@free.fr wrote:

So I've opened https://bugzilla.mozilla.org/**show_bug.cgi?id=877563https://bugzilla.mozilla.org/show_bug.cgi?id=877563and I'm trying to modify the workaround for WebKit. But I'm still not sure
what is the expected behavior. For example:

  1. x+y<**
    /mrow>
  2. <x+y<**
    /math>
  3. Li+</**
    math>
  4. +Li**
  5. Li+</*
    *math>

I think MathML only says that the lspace/rspace attributes apply in test

  1. (mrow) and 2) (inferred mrow). The others are not mrow or inferred mrow,
  2. is a script and maybe 5) too.

Gecko currently adds space in all cases and MathJax adds space in 1), 2)
3), 4) but not 5). I haven't tried with MathPlayer.

Perhaps the MathML says that the only requirement is in mrow/inferred mrow
and that the implementers are free to choose the spacing in other cases?

Frédéric Wang
maths-informatique-jeux.com/**blog/frederichttp://maths-informatique-jeux.com/blog/frederic

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Jun 3, 2013

So from Neil's latest comment, I understand that MathJax/Gecko 's behavior to consider lspace/rspace in scripts is not quite correct. I've updated the issue482 branch to only add space around mo elements that are children of a non-embellished (inferred) mrow.

=> Ready For Review

@pkra

This comment has been minimized.

Copy link
Member

commented Jun 10, 2013

@fred-wang I feel like I'm missing half the conversation. I'm guessing that you cc'ed people on the github emails but their responses only get to you?

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Jun 10, 2013

I think when people replied to me and cc'ed the github emails, their messages were sent with my github account.

@dpvc

This comment has been minimized.

Copy link
Member

commented Aug 1, 2013

The code here looks good. A couple of small suggestions:

  • For the <mi> I'm not sure why you are using style rather than setting mathvariant directly. Wouldn't it be easier to just do

    var mi = parent.lastChild;
    mi.setAttribute("mathvariant",MML.VARIANT.NORMAL);
    

    rather than all the style stuff?

  • I would use MML.VARIANT.NORMAL rather than "normal" to be consistent with other usage.

  • I would use === rather than == for string and numeric checks.

Other than that, it looks ready to go.

@dpvc

This comment has been minimized.

Copy link
Member

commented Aug 1, 2013

I've noticed that the CSS that used to be for Firefox NativeMML (to handle mathvariants) is now supplied for all browsers other than IE. Is that what we want? I don't know the support for mathvariants in other browsers, but noticed that change when I was reviewing the code.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Aug 2, 2013

I've noticed that the CSS that used to be for Firefox NativeMML (to handle mathvariants) is now supplied for all browsers other than IE. Is that what we want? I don't know the support for mathvariants in other browsers, but noticed that change when I was reviewing the code.

Currently no one implements the mathvariant remapping to math alpha num char and just uses CSS style to emulate italic/bold/bold-italic. So I think it's fine to use the MathJax fonts to emulate the other variants, especially this will work when #301 is fixed.

dpvc pushed a commit that referenced this issue Aug 2, 2013

@dpvc dpvc closed this Aug 2, 2013

@pratikkalathiya

This comment has been minimized.

Copy link

commented Dec 19, 2013

10
+11

Can i print this type of operation using MathJax on rendered page ???

@pkra

This comment has been minimized.

Copy link
Member

commented Dec 20, 2013

If you're asking for Elementary math support, then the answer is currently no; see http://docs.mathjax.org/en/latest/mathml.html#supported-mathml-commands. You should write to the MathJax User Group to get advice on hacking this together some other way -- the bug tracker or this thread are not the right place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.