Add workarounds for Webkit Native MathML #482

Closed
opened this issue May 24, 2013 · 31 comments

Projects
None yet
4 participants
Contributor

fred-wang 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: Italic with multiple-letters mi. MathJax could force the font-style 

$sin$

 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: 

$7 8 x01 34 56$

 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: 

$x+y$

 Here is a screenshot of the previous examples in a WebKit trunk build (Nightly builds can be downloaded from http://nightly.webkit.org/): (Hopefully we don't have the Opera bug and style changes can be done via Javascript)
Contributor Author

fred-wang commented May 24, 2013

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

$xy$


Member

pkra 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.
Contributor Author

fred-wang 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 assigned fred-wangMay 29, 2013

Contributor Author

fred-wang 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
Contributor Author

fred-wang 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.
Contributor Author

fred-wang 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.
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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
Contributor Author

fred-wang 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.
Member

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

dpvc 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
Contributor Author

fred-wang 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: x+y
Contributor Author

fred-wang 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:  $x+y$ $x+y$ $Li+$ $Li+$ $x+y$  (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)
Contributor Author

fred-wang 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: x+y<** /mrow> Li+ +Li** Li+ I think MathML only says that the lspace/rspace attributes apply in test (mrow) and 2) (inferred mrow). The others are not mrow or inferred mrow, 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
Contributor Author

fred-wang 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
Member

pkra 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?
Contributor Author

fred-wang 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.
Member

dpvc commented Aug 1, 2013

 The code here looks good. A couple of small suggestions: For the  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.
Member

dpvc 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.
Contributor Author

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

 Merge pull request #527 from fred-wang/issue482 
This resolves issue #482.
 4263db9 

pratikkalathiya commented Dec 19, 2013

 10 +11 Can i print this type of operation using MathJax on rendered page ???
Member

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