Deprecate/Remove namedspaces length values

[fred-wang]

In #5 we decided to remove the attributes veryverythinmathspace,
verythinmathspace, thinmathspace, mediummathspace, thickmathspace,
verythickmathspace, veryverythickmathspace ( https://mathml-refresh.github.io/mathml/chapter3.html#id.3.3.4.2.1 ) which allow users to override the values of the corresponding namedspaces lengths.

In previous meetings we raised the question of what to actually do with these named space ( https://mathml-refresh.github.io/mathml/chapter2.html#type.namedspace ), remove/deprecate them from mathml core/4?

If we decide to keep the spec should not suggest "Recommended default" for namedspaces but explicitly say that they are equivalent to these em values. Then one could write polyfills for these.

Probably #55 is relevant here.

[briansmith]

Here is an example where I've used this:

<math> <!-- Note: Not display="block" -->
 <mrow>
  <mn>0</mn> <mover accent=true><mo>↦</mo><mi>σ</mi></mover>
  <mn>1</mn> <mover accent=true><mo>↦</mo><mi>σ</mi></mover>
  <mn>2</mn> <mover accent=true><mo>↦</mo><mi>σ</mi></mover>
  <mn>3</mn> <mover accent=true><mo>↦</mo><mi>σ</mi></mover>
  <nm>4</nm> <mo lspace="thickmathspace" form="infix">⋯</mo>
  <mtext>,</mtext>
 </mrow>
</math>

My goal was to give the "⋯" the same amount of lspace as "↦" gets by default. I looked up "↦" in the operator dictionary at https://www.w3.org/TR/MathML3/appendixc.html and it told me to use thickmathspace.

If thickmathspace are deprecated and removed then what would the references in the operator dictionary look like? How would one specify that their operator should have the same spacing as another operator, like in my example.

If we decide to keep the spec should not suggest "Recommended default" for namedspaces but explicitly say that they are equivalent to these em values. Then one could write polyfills for these.

I'n not sure this is true. Consider MathML typeset inline in fully-justified text. I'm not conviced that the Math's whitespace should be fixed while the rest of the whitespace on the line is allowed to grow/shrink. And, I'm not sure it is possible to use CSS to emulate growable/shrinkable whitespace.

Usually the font decides how wide each kind of space ( , etc.) should be. It seems to me like the font should have some input in how wide these spaces are.

[fred-wang]

@briansmith In MathML 3, each *mathspace defaults to some value expressed as a multiple of 1/18em. In #5 we decided that they would actually be equivalent to these values (this is how it is implemented in browsers). The operator dictionary values would them be expressed using these em values. Probably, we need to be more explicit so that user can actually specify the same values as the one computed internally without worrying about rounding errors. So e.g. replace thickmathspace with 0.2777777777777778em instead of 5/18em.

TeX has a different spacing algorithm but if I'm not wrong it defines the spacing as multiple of em values too. The   etc maps to unicode characters, we could probably define the *mathspace values using the corresponding glyphs's width. That would be an incompatible change with MathML 3 but at least justify keeping the values since they no longer duplicate existing functionality. If we choose that option, I would prefer that we make a proposal to the CSS WG, so that MathML length values could still just be mapped to CSS (#63). In any case, I don't see how that actually solves the fully-justified text case, it seems to me that it would still be a multiple of em?

Is there any concrete use case for fully-justified text in math?

cc @khaledhosny @jfkthame

[briansmith]

TeX has a different spacing algorithm but if I'm not wrong it defines the spacing as multiple of em values too.

I think it is fine for MathML to have different defaults from TeX but I think it is also reasonable for an author to expect to, relatively easily, override the defaults to match TeX. In particular, I think it is important to be able to conform to the AMS style guide (https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf) which prescribes specific spacing for various constructs but then implies that "whatever TeX does" is right and/or at least acceptable.

Is there any concrete use case for fully-justified text in math?

Many of the math books on my shelf, algebra books in particular, place a lot of math inline in fully-justified paragraphs. (They also do linebreaking in inline math in a way that's similar to what the AMS style guide recommends.) I don't think a lot of effort needs to be spent right away on getting full justification to work well with MathML (it doesn't work well even without MathML in browsers today). However, AFAICT, implementing spacing using CSS padding-left: Xem and padding-right: Xem probably wouldn't work well in any future world where we have good full justification because the justification logic would need to be able to grow-shrink such spacing, but the HTML/CSS justification engine doesn't grow/shrink padding, IIUC.

[NSoiffer]

29/4/19 meeting:
Resolved that we will drop named lengths from core. These will get mapped to fixed number of ems with a few (probably three) digits precision. E.g, thinspace, has a fixed definition of 3/18 of an em, so the value mapped to core will be 0.167em. [Note that one needs to get to a 1000 point font before the rounding even gets close to being one pixel off]

They remain in full because they are being used some.

Note: this simplifies parsing attribute length values (#63).

[fred-wang]

29/4/19 meeting:
Resolved that we will drop named lengths from core. These will get mapped to fixed number of ems with a few (probably three) digits precision. E.g, thinspace, has a fixed definition of 3/18 of an em, so the value mapped to core will be 0.167em. [Note that one needs to get to a 1000 point font before the rounding even gets close to being one pixel off]

They remain in full because they are being used some.

Note: this simplifies parsing attribute length values (#63).

@NSoiffer Just to be clear, they are removed from MathML core and the mapping to em has to be defined in MathML full, right?

[NSoiffer]

Yes. The full spec should make explicit what the values are for the namedspaces and the polyfill should use them. The change to full is that they can't be redefined.

…

On Thu, May 2, 2019 at 3:56 PM Frédéric Wang ***@***.***> wrote: 29/4/19 meeting: Resolved that we will drop named lengths from core. These will get mapped to fixed number of ems with a few (probably three) digits precision. E.g, thinspace, has a fixed definition of 3/18 of an em, so the value mapped to core will be 0.167em. [Note that one needs to get to a 1000 point font before the rounding even gets close to being one pixel off] They remain in full because they are being used some. Note: this simplifies parsing attribute length values (#63 <#63>). @NSoiffer <https://github.com/NSoiffer> Just to be clear, they are removed from MathML core and the mapping to em has to be defined in MathML full, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZM3DZXEKJQUVP6ISHGC3PTNWSNANCNFSM4G7OHDSQ> .

[fred-wang]

Resolution:

• https://lists.w3.org/Archives/Public/public-mathml4/2019Apr/0022.html
• Deprecate/Remove namedspaces length values #75 (comment)

Specification:

• Update length definitions
• Full should map to some numeric values.

Implementation:

• Remove from WebKit/Gecko
• Not implemented Chromium.

Polyfill:

• Map to numeric values as suggested by Full.

Tests:

• Verify that they are not supported

[fred-wang]

namedspaces are no longer mentioned in the core spec.

[fred-wang]

The core spec no longer refers to MathML 3 for the mpadded syntax and namedspace are not mentioned:
https://mathml-refresh.github.io/mathml-core/#adjust-space-around-content-mpadded

[fred-wang]

The MathML core spec now mentions the following values for the operator dictionary lspace/rspace: 0, 0.05555555555555555em, 0.1111111111111111em, 0.16666666666666666em, 0.2222222222222222em, 0.2777777777777778em, 0.3333333333333333em, 0.3888888888888889em

[fred-wang]

Closing since we have tests for that.

[NSoiffer]

Reopening because these need a polyfill and the full spec needs to be changed.

[fred-wang]

cc @emilio

Reopening because these need a polyfill and the full spec needs to be changed.

@NSoiffer what's the status of this? Can the issue be closed?

[fred-wang]

MathML Full still mentions fractional values of em in https://w3c.github.io/mathml/#fund_units. I believe it should instead use #75 (comment)

[davidcarlisle]

@fred-wang It seems to me in human oriented text , as here, 1/18 is preferable. Naturally any such fraction can only be stored up to the precision used, so we could explicitly say ieee double to be used in mathml-core applications but we don't have a requirement for IEEE arithmetic elsewhere for non web-platform implementations. Certainly TeX based MathML renderers will typically not be storing lengths to that precission.

[fred-wang]

@NSoiffer what's the status of this? Can the issue be closed?

Pinging again

[fred-wang]

I can't find anything in https://github.com/mathml-refresh/mathml-polyfills from a quick grep. Anyway, these attributes have been deprecated for a while, so let's go ahead and remove them from WebKit (under a pref) and Firefox...

[NSoiffer]

Sorry for being slow to respond...

It appears that both core and full specs are correct so I'll remove the specification and MathML 4 labels.

Yes, they can be removed from Webkit and Firefox.

I thought I had written a polyfill, but it is not there. I'll add one soon. It should be very easy. Once I do, I'll remove the "needs polyfill label".

Once Firefox and Webkit are updated, the compatibility label can go.

When all the labels are gone, this can be closed.

[fred-wang]

Quick check of the status for some LaTeX converters:

TeXZilla switched to em values in fred-wang/TeXZilla@fcce5a0

itex2MML switched to em values in https://golem.ph.utexas.edu/~distler/code/itexToMML/revision/84

MathJax: I tried $$a \quad \, \: \; \! \qquad b$$ on https://www.mathjax.org/#demo and they now use em instead of named constants. It seems they switched to em values in mathjax/MathJax-src@7f8ccfe although there may be remaining places (e.g. mathjax/MathJax#2902 )

LaTeXML: Not sure how to produce named constants. I see brucemiller/LaTeXML#1801 is still open.

[fred-wang]

@physikerwelt I tried <math>a \quad \, \; \! \qquad b</math> on https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox and I still see some named space values for some of them. Do you know what's the status in MediaWiki?

[physikerwelt]

@fred-wang thank you for bringing this up. There has not been any work toward fixing that so far, but I created a ticket as a first step.