Remove/Deprecate subscriptshift/superscriptshift attributes of msubsup/msup/msub

[fred-wang]

These are currently defined in MathML 4 and ignored in MathML Core.

Script shifts are currently described via complex TeX / OpenType rules in MathML Core, allowing font designers to provide proper position of scripts.

subscriptshift/superscriptshift allow page authors to override the min script shifts. However, I'm not sure that's really use in practice. I wonder if we should deprecate/remove them to simplify the layout.

[dani31415]

What about using non math fonts? The default choice should be good enough.

[fred-wang]

What about using non math fonts? The default choice should be good enough.

I believe the TeX appendix G has some suggestions for the min shifts and this is what is used in Gecko & WebKit.

[NSoiffer]

I think the spec should say what values to use when using math fonts. Let's make sure there is no confusion by being specific about which should be used.

Similarly, when using fonts without math tables, we need to specific about how to calculate default values for them. I hope it won't be a problem to do so via character-specific bounding boxes (e.g, defining the axis and rule thickness based on the bounding box for "-"). Using generic font-wide info such as x-height will lead to poor layout.

[fred-wang]

What about using non math fonts? The default choice should be good enough.

I believe the TeX appendix G has some suggestions for the min shifts and this is what is used in Gecko & WebKit.

Similarly, when using fonts without math tables, we need to specific about how to calculate default values for them. I hope it won't be a problem to do so via character-specific bounding boxes (e.g, defining the axis and rule thickness based on the bounding box for "-"). Using generic font-wide info such as x-height will lead to poor layout.

Let's not go off-topic, I opened w3c/mathml-core#116 for that.

[fred-wang]

The MathML Core spec already indicates how to use MATH parameters to layout scripted expressions:
https://mathml-refresh.github.io/mathml-core/#scriptsandlimits
We can add fallback values w3c/mathml-core#116

This issue is about whether we actually need subscriptshift/superscriptshift? Gecko interprets them as "minimal shifts" but some people might want that it overrides the whole MATH / TeX rules.

My preference would be that it does not keep in MathML core, that we remove support from Gecko. (AFAIK there is no plan to implement it in WebKit or Chromium) and that people who really want to tweak the shifts (which is probably a bad thing) could use CSS (once we clarify the things about margin/padding/border/width/height) or mspace or mpadded...

[fred-wang]

cc @rwlbuis, @emilio :

This went off topic, but as I understand current status is:

• We still need to collect data and use cases Collect usage statistics for current MathML elements #55 and decide if they should go in core/full or be deprecated/removed.
• We still need to describe how the specified shift values interacts with other shifts described in the layout algorithms of https://mathml-refresh.github.io/mathml-core/#scriptsandlimits (whether or not the OpenType MATH fonts or fallback values are used). Gecko and WebKit interpret as a minimal shift (i.e. a constraint on top of the TeX/OpenType rules not overriding them):
  https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmmultiscriptsFrame.cpp#232
  https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmmultiscriptsFrame.cpp#278
  https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/RenderMathMLScripts.cpp#L264
  Also default values suggested in https://mathml-refresh.github.io/mathml/chapter3.html#presm.scrlim are "automatic" which makes a bit more tedious to interpret/implement the relative values as indicated in WebKit's comment. I would rather replace this with "0" which would match the default behavior if the attributes are interpreted as minimal shifts.

My preference would be:
(1) Remove this attribute from core to remove the extra layout/parsing code.
(2) Or if there is really a strong use case for this, interpret them as minimal shifts with default 0 values, so that it's easy to plug them into the default algorithm.

[physikerwelt]

I would go for (1)

[NSoiffer]

The shifts are not in use for the converters we have data for. However, I'm not sure that is meaningful as the source is mostly TeX and the games people play in TeX to shift a script probably aren't easily translated to these values. I do see mphantom and mpadded have some use in the stats and that for arXiv, there are some (very small) number of scripts that have a class of ltx_phantom. These could be cases where shifting the script more directly represents what they want to do.

[NSoiffer]

FYI... On p179 of the TeXBook, Knuth has an example of resetting the script default shift values for typesetting Chemistry. That's the only case I could see, but he lists this as an alternative to \vphantom so other cases are possibly listed in the TeXBook.

The shift attrs are a higher-level method of doing this. Maybe we add something as mentioned in #92 to handle the Chemistry case and then the use case goes away... if one of the possibilities is easy to implement in a browser.

[NSoiffer]

At the meeting today, the consensus was to remove these from core. A problem does exist for supporting chemical notations as they want sub/superscripts always aligned. @davidcarlisle felt various workarounds could be used ranging from converters adding struts via mphantom to publishers creating their own version of a font where they have tweaked the open math params so they work well with chemical formulas.

[davidcarlisle]

call resolved not to deprecate these

[dginev]

A problem does exist for supporting chemical notations as they want sub/superscripts always aligned.

I do not currently have enough practical experience with CSS Box Alignment, but I was wondering during the call today whether that could be a long-term device to accomplish the script alignments for chemistry.

If other participants here have thoughts on that idea (especially when it comes to MathML Core), it would be interesting to hear.

To clarify David's comment above, the call resolved to keep the attributes in MathML Full, as there is no clear alternative mechanism available today.