Consider defining "cramped" as a CSS property?

[fred-wang]

cc @rwlbuis @emilio

See https://mathml-refresh.github.io/mathml-core/#cramped-elements and #134

To know if an element is cramped, we basically need to browse the list of ancestors.

We could maybe instead more efficiently handle this by defining cramped style as a boolean CSS property:

  mroot,
  msqrt,
  mfrac > *:n-child(2),
  msub > *n-child(2),
  msubsup > *:n-child(2),
  munderover > *:n-child(2),
  mover[accent="true" i] > *:n-child(2),
  munderover[accent="true" i] > *n-child(3) {
        cramped: true /* bikeshed on the names... */
  }

This will allow people to force cramped style in MathML or their custom layout.

As discussed in #134 and similarly to the discussion with scriptlevel, this assumes we exclude the case when the "accent" property is determined from the operator dictionary / text content of the core operator.

[NSoiffer]

If we go with my suggestion in #134, the last two lines should be removed and this issue goes away.

[fred-wang]

Consensus from 2019/11/11: Remove special case for overscripts.

This means we can implement it as a CSS property.

In a previous meeting, @bkardell pointed out that we should explain in English what "cramped" means. Apparently there is one cf definition 2 of https://www.dictionary.com/browse/cramped

[fred-wang]

I simplified a bit the way the definition of cramped is written: https://mathml-refresh.github.io/mathml-core/#dfn-cramped

• Current definition uses "second in-flow child" so I don't think that works with CSS (we can probably change it, we have the same issue with script-level increment anyway).
• Current definition does not include (post?)subscripts of mmultiscripts (following Gecko). These are probably more difficult to describe with CSS.

Anyway, I don't think making cramped a CSS property is something urgent.

[fred-wang]

I simplified a bit the way the definition of cramped is written: https://mathml-refresh.github.io/mathml-core/#dfn-cramped

* Current definition uses "second in-flow child" so I don't think that works with CSS (we can probably change it, we have the same issue with script-level increment anyway).

* Current definition does not include (post?)subscripts of mmultiscripts (following Gecko). These are probably more difficult to describe with CSS.

Anyway, I don't think making cramped a CSS property is something urgent.

Even if we don't define cramped as a CSS property yet, addressing the two points above would be helpful to make cramped more aligned with the rest of the LayoutNG code.

[NSoiffer]

[updated]
At the MathML core meeting today, there was some confusion (by me and others) about what cramped style is. Looking at TeX, cramped style:

• only affects super script positioning.
• is (initially) acquired in a sub script, an accent (in TeX, "math accent" and overline), the denominator in a fraction, and in a sqrt/radical.
• is inherited once acquired.

In the meeting, the question arose as to whether multiscripts need to set in a cramped style. I think the answer is "yes", but since multiscripts want to set all of their sub/superscripts at the same vertical offset (respectively), I'm not sure cramped style makes sense for the multiscript superscripts to use a cramped style since they want to be raised a little above normal so that a "+" or other symbol doesn't cause one superscript to shift up but not another. On the other hand, since multiscripts can look at all the scripts, it could set them all in a cramped style if all of them use the same vertical offset. So the answer really comes down to what the layout rules are for multiscripts.

Note: see #134 (comment) for details on how TeX does cramped computation.

[davidcarlisle]

you miss one more case where TeX uses a cramped style, it is used denominators of fractions in display and cramped display style (rule 15a) luatex adds four primitives to explicitly set the four cramped versions of the math styles \crampeddisplaystyle \crampedtextstyle \crampedscriptstyle \crampedscriptscriptstyle these act like the standard \scriptstyle etc, but select the cramped forms.

[fred-wang]

Where Gecko changes the cramped style: https://dxr.mozilla.org/mozilla-central/search?q=NS_MATHML_COMPRESSED

mmultiscripts will definitely use the scriptshiftup parameters for the layout of all the superscripts. However, the question is whether it changes the cramped style for subscripts, and this will then affect how the layout of superscript is done for any descendants (at arbitrary deep level) of these subscripts.

[NSoiffer]

I believe that cramped style should be set for the subscripts in multiscripts. Hopefully that is doable as per @fred-wang's idea in the call today.

After my comment about about looking at all of the children to determine alignment, I looked at the MathML 3 and core specs. One of the few things where MathML 3 says something about layout is that all the sub/superscripts (respectively) are aligned. The core spec respects that, although I think the wording can be improved:

SubShift (respectively SuperShift) is calculated by taking the maximum of all subshifts (respectively supershifts) of each subscript/superscript pair as described in § 3.4.2.4 Base with subscript and superscript.

The rest of the section then uses SubShift (respectively SuperShift). The issue I have is that "SubShift" is defined earlier ($3.4.2.3) and this part of the spec redefines it, which can cause confusion. E.g., here's part of the description of layout:

Place the subscript (respectively superscript) so its alphabetic baseline is shifted away from the alphabetic baseline by SubShift (respectively SuperShift) towards the line-under (respectively line-over).

It is easy to miss that those value's meaning was changed a screen above. I think using "MaxSubShift" (and "MaxSuperShift") would avoid any confusion. The same is true for "line-ascent" and "line-descent".

Returning to this issue, I agree that nothing special wrt to superscript positioning and cramped style needs to happen with mmultiscripts -- the initial layout can follow the rules for msubscript. If taking the max among all the children doesn't change the shift amount from a default cramped layout, that's fine.

[fred-wang]

Here is an example using ~ and n-th child. We can do the same with color replaced with a cramped property.

<math>
  <mmultiscripts>
    <mn>01</mn>
    <mi>02</mi>
    <mo>03</mo>
    <mtext>04</mtext>
    <mn>05</mn>
    <mo>06</mo>
    <mtext>07</mtext>
    <mn>08</mn>
    <mi>09</mi>
    <mprescripts/>
    <mo>11</mo>
    <mtext>12</mtext>
    <mn>13</mn>
    <mi>14</mi>
    <mo>15</mo>
    <mtext>16</mtext>
    <mn>17</mn>
    <mi>18</mi>
  </mmultiscripts>
</math>
<style>
  mmultiscripts > *:nth-child(even)  {
      color: blue;
  }
  mmultiscripts > mprescripts ~ *:nth-child(even)  {
      color: inherit;
  }
  mmultiscripts > mprescripts ~ *:nth-child(odd)  {
      color: blue;
  }
</style>

[fred-wang]

Proposal for cramped is:

• Initially false.
• Inherited.
• Set to true in the second child of mfrac, msub, msubsup, munder or munderover and in the subcripts of mmutiscripts. This can be done using CSS selectors (I wrote one for mmutiscripts above and the second child should be > *:nth-child(2) ).
• Set to true on the children of root/radical ( > * ).
• Set to true on the first child of 'munderover/mover with accent="true" attribute'

Regarding accent, Firefox does this: https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLmunderoverFrame.cpp#280 ; This is exactly the same situation as #76 ; we can add accent/accentunder attribute selectors if necessary but it's definitely not ok to rely on on mo accent properties. Neil said this is resolved, but I don't remember that we agreed to ignore the mo accent properties. I'm happy to choose that option if that's what the CG want. I would be even happier to remove the accent mo property completely.

[NSoiffer]

We agreed to remove accent from the operator dictionary and change the default value to be true. That shrinks the operator dictionary and avoids the need for a lookup there for that property. But mo still allows the accent property to be set.

[fred-wang]

consensus: do #164 (comment) ; don't handle mo@accent for now.

[fred-wang]

Spec updated, the only difference is that I made the radicals cramped rather than their children in order to avoid one universal selector. This shouldn't make any difference since cramped is not used during their layout.

[NSoiffer]

Our meeting on Monday spent most of the time discussion #164 -- what should be done about cramped style. Fred noted the consensus in earlier in this issue. At the meeting, I volunteered to summarize the discussion so there would be a record of why MathML core differs from standard typesetting.

The beginning of the discussion agreed that because checking for embellished operators was hard and that having an embellished operator in an accent is extremely rare, we should change the rule from looking for an embellished operator (which is basically impossible in CSS) to just looking for an operator. That was tacitly agreed to without a request for consensus.

Then the discussion veered off onto accents on in general and other rules before coming back to cramped style. After 50 minutes of discussion, we agreed that the 1/2 point difference in height between cramped and uncramped for mover/munderover is not much in the grand scheme of things and so we should do the simple thing and ignore this case.

I volunteered to write up the discussion which led me to see that we forgot what we said at the start of the meeting -- just don't worry about embellished operators in the accent . That seems to  have gotten lost at the end of the discussion.

Question: since the goal was to find a simple solution, why:

1. Don't we check the accent property on mover/munderover
2. Don't we check for that property on an (unembellished) mo in the accent position

Both these seem like simple CSS rules to write and catch virtually all cases that were missed. I put the examples into codepen.  Firefox does this correctly, which you can see if you view the codepen in Firefox.

[fred-wang]

Question: since the goal was to find a simple solution, why:

1. Don't we check the accent property on mover/munderover

AFAIK this is already done in the spec.

2. Don't we check for that property on an (unembellished) mo in the accent position

My preference is to remove completely the accent property / attribute on the operator. It duplicates the accent/accentunder feature (since it's not relevant outside mover/munder/munderover) and people could polyfill this with CSS as you said, or at worse JavaScript. I think it's confusing to apply only to unembellished mo. The CSS rule is already complicate enough with universal rules, let's see if we can upstream the the basic support first before making this more complex.

[NSoiffer]

The issue is this is likely a pretty significant breaking change for how the MathML is generated. I tried MathType (for Windows -- the original MathType) and MathType Web (the original WIRIS editor). Neither put added accent="true" to mover. I also tried Word; it did use accent="true". I tried an older version of Mathematica (I very much doubt its MathML support changed), and it doesn't use accent="true" either. I also tried two converters: asciimath and mathjax (its TeX to MathML output). Neither add accent="true".

That seems like a pretty big breaking change... except very few of the renderers do cramped style. That includes MathJax(!) and Firefox. So people likely wouldn't notice the breakage. On the other hand, a one line addition to the CSS makes MathML do better rendering (where "better" = TeX) without requiring a lot of software to change or people having to use a polyfill (which kind of defeats the purpose of having MathML Core).

Update: I created a MathJax issue about cramped style. Turns out it was a bug in the V3 code (i.e., it worked in V2) and the fix has already been pushed. So MathJax, which is what most people see on the web, does/will support cramped styles.

[fred-wang]

That seems like a pretty big breaking change... except very few of the renderers do cramped style. That includes MathJax(!) and Firefox

Firefox definitely supports cramped style.

[NSoiffer]

On the left below is what this codepen displays as in Firefox:

Firefox does display cramped style for fractions and subscripts correctly, but not the overbar or hat. I think Firefox drops the exponent too much when it does do cramped style.

On the right side the same MathML rendered by MathJax (with the bug fixed).

[fred-wang]

There is now https://mathml-refresh.github.io/mathml-core/#the-math-superscript-shift-style which is tested in WPT and implemented in Chromium upstream, so closing