Script level increment in munder, mover, munderover scripts

[fred-wang]

Script level increment in munder, mover, munderover scripts

When these elements are really drawn as under/over scripts then the script
level increment should not happen when accentunder or accent are specified:

munder[accentunder="false"] > :nth-child(2),
mover[accent="false"] > :nth-child(2),
munderover[accentunder="false"] > :nth-child(2),
munderover[accent="false"] > :nth-child(3) {
  math-script-level: inherit;
}

Unfortunately whether the elements are drawn with under/over scripts as well
as the default values of the accentunder and accent attributes have to be
determined from the MathML DOM and even using an
operator dictionary.
This is not possible to do in the CSS side. Maybe this feature could be removed
from MathML and the authors should explicitly indicate whether they want
to prevent increment in scriptlevel in this case.
Gecko implements it via pseudo-element set in the layout code
but that's causing some issues.

[fred-wang]

cc @rwlbuis @emilio

[davidcarlisle]

<mover><mi>x</mi><mo>&Hat;</mo></mover>

is rather common

<mover accent="true"><mi>x</mi><mo>&Hat;</mo></mover>

is I think what you are suggesting but is a bit verbose..

would a new

<maccent><mi>x</mi><mo>&Hat;</mo></maccent>

work for you?

(I'm not necessarily proposing that and any proposal would (perhaps) need to deal with munder and munderover as well, but just asking.....)

[fred-wang]

@davidcarlisle <munder> and friends behave as <msub> and friends when displaystyle is false and base is a largeop (i.e. increment script level). And as you say the accents are quite common. So I believe the default should be to increment the scriptlevel in the scripts:

munder > *:nth-child(2),
mover > *:nth-child(2),
munderover > *:nth-child(2),
munderover > *:nth-child(3) {
    math-script-level: add(1);
}

Then the proposal would be to add the rules from #76 (comment) to prevent incrementing script level when the script is explicitly said not to be an accent. This can still be done via pure CSS rules in the UA stylesheet.

I'm not sure how introducing a new element will help, it's essentially the same as element with explicit attribute. None of these solve the issue that MathML tools or polyfills would have to change the output sent to the browser.

[davidcarlisle]

None of these solve the issue that MathML tools or polyfills would have to change the output sent to the browser.

True but tools and polyfills don't have feelings so they just generate wherever they need to generate. But as Neil commented in the call, we have somehow failed if we end up with a situation where mathml core is so constrained that practically everyone has to use a javascript wrapper, as that will make explaining the benefits of native mathml support and existing javascript solutions that much harder.

It wasn't a fully fledged proposal but I was just wondering if at the spec level specifying <maccent> might be less objectionable than <mover accent="true"> although it's not really that much shorter...

I guess go with the explicit accent= attribute for now and see how it goes. (that is whether anyone complains...

[fred-wang]

I get that but on the other hand:

• One has to notice that this is not just in the category of "adding duplicate code" or "extra complexity" but it's really a serious violation of web engine design and is causing issues to Mozilla developers. It's the kind of thing that could make Mozilla engineers think this feature (or worse MathML) should be removed in the future. It's also the kind of thing Apple/Google reviewers are unlikely to accept IMHO.
• The MathML 3 specification's design is intentionally not strict about rendering rules, so it's difficult for me to buy the argument that the font-size change is critical when so many rendering rules are missing to get good/interoperable rendering. I wonder if most MathML users would notice the difference.
• MathML already has a mechanism to preserve the behavior: use an explicit attribute. It's not nice to break backward compatibility but authoring tools could be upgraded to solve that issue.

[davidcarlisle]

Yes I am not arguing that you should use the element content I can imagine that causes issues.

I wonder if most MathML users would notice the difference.

I suspect they would, as an accent is already pretty small and setting it scriptsize may make it really hard to spot at some sizes. However it's not a _terrible_ outcome and as you say adding an explicit accent= attribute is an easily documented correction so personally I'm happy to go with this,

[fred-wang]

I suspect they would, as an accent is already pretty small and setting it scriptsize may make it really hard to spot at some sizes.

OK, actually my proposal was wrong it should revert the script level change when accent is true:

munder[accentunder="true"] > :nth-child(2),
mover[accent="true"] > :nth-child(2),
munderover[accentunder="true"] > :nth-child(2),
munderover[accent="true"] > :nth-child(3) {
     math-script-level: inherit;
}

[briansmith]

• The MathML 3 specification's design is intentionally not strict about rendering rules, so it's difficult for me to buy the argument that the font-size change is critical when so many rendering rules are missing to get good/interoperable rendering. I wonder if most MathML users would notice the difference.

Yes, I think most authors publishing using MathML would notice the difference.

• MathML already has a mechanism to preserve the behavior: use an explicit attribute. It's not nice to break backward compatibility but authoring tools could be upgraded to solve that issue.

I personally think the explicit accent attribute is OK. My experience is that I often explicitly shrink the text size even further than what the MathML engine would do by default via the script level. Consider 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>

In Firefox as of today, the σ's above the arrows are rendered way too large. This makes me think that just incrementing scriptlevel by 1 for the overscript may be not the right solution. I suggest:

1. Decide what the optimal rendering of various uses of overscript should be. (In the case above, for screen I manually add style="font-size: 61%" to override Firefox's default sizing; I doubt what Firefox does for operator + with a letter as accent is what anybody wants.)
2. For each each usage pattern discovered in the previous step, decide how you want users to get the optimal rendering.
3. Based on the analysis in the second step, make decisions like what the default rendering and script level should be.

In particular, It doesn't make sense to put a lot of effort into a default rendering that must be overridden by basically everybody to get good results, so if the default rendering is always going to be suboptimal then it makes sense to KISS and rely on manual markup. If the goal is to get good results by default, or with minimal markup additions like accent=true then something even more complicated than the operator dictionary may be needed.

[fred-wang]

I think my preference would be to put this decision on hold. A DOM-based font-size change is not acceptable in CSS engines as @emilio explained during a previous meeting. So I believe the only ways I see to solve this would be either to have an explicit attribute and CSS selectors in the UA stylesheet OR a introduce a text-level mechanism, similar to the ssty one (#19).

Currently the implementation in Gecko is not nice at all as it violates some browser invariants. I don't know what is Mozilla's plan on it, but at Igalia we are unlikely to implement a similar one in WebKit or Chromium as that won't pass review.

In general, MathML's specification/implementation of accents is not as good as TeX IMHO. Having a preliminary cross-browser implementation plus polyfills like @briansmith 's one could help to detect the issues and design something better in the future.

[NSoiffer]

@briansmith: I think you got confused in your example: accent=true prevents the scriptlevel change, so Firefox's not shrinking the sigma is correct.

This seems like potentially one of the biggest breaking changes we have considered. I definitely agree with @fred-wang that we should put this on hold for a while to see if any other ideas come up for dealing with it.

[briansmith]

@briansmith: I think you got confused in your example: accent=true prevents the scriptlevel change, so Firefox's not shrinking the sigma is correct.

Thanks. I agree. accent=true affects where the overscript's baseline is AND affects the scriptlevel; I wanted the lower baseline while still having the scriptlevel change (potentially by more than one increment). I think that my usage of accent=true here is abuse that doesn't need to be supported because I don't think the sigma is actually an "accent". On the other hand, it is unclear how one controls the position of the overscript in a mover and more generally it is unclear how one is supposed to mark up "bar with a function name over it that doesn't change the height of the line(s) of text it appears in when inline in paragraph text."

With this in mind, I left out an important "step 0" in my above suggestion:

0. Decide which markup an author should use for various constructs to decide which use cases need to be supported.

[NSoiffer]

This is closed because the outstanding problem was resolved with #134 being closed.

[fred-wang]

I'm lost with the discussion but #134 is about determining cramped (which originally depended on the accent properties) while this is about determining font-size/scriptlevel (which does not depend on accent properties in core, but MathML3 says it should). I think it should remain open, unless people agree we should just ignore what MathML3 says here.

[faceless2]

We've been implementing based on the MathML4, and have been troubled by variations of this (simplified) test:

<math style="font-size: 100px">
 <mover>
  <mi>x</mi>
  <mover>
   <mo>⏞</mo>
   <mi>y</mi>
  </mover>
 </mover>
</math>

What font-size is the overbrace? Gecko displays it as 100px, but the spec as currently written would require this to be reduced to 71px (roughly - it depends on the font of course). Webkit reduces the font size to 75%. To my eyes, the correct size is the same as the base - 100px.

Just wanted to flag this up as part of this issue, as it seems relevant.

[fred-wang]

@faceless2 I guess the fact that the operator is stretchy complicates things here. And all the operators will be accent by default in MathML core. So I suggest you use explicit accent/stretchy in your example.

[faceless2]

We're implementing a MathML layout engine, so my interest is in the behaviour for a particular XML, rather than how to craft some XML to get a particular output. I mainly wanted to note that the current proposed specification doesn't match the behaviour of Gecko.

[fred-wang]

We're implementing a MathML layout engine, so my interest is in the behaviour for a particular XML, rather than how to craft some XML to get a particular output.

My point was that the size depends on many parameters, so reducing them would help you to understand what the expectation is.

I mainly wanted to note that the current proposed specification doesn't match the behaviour of Gecko.

Yes, this specification is not yet fully implemented in all browsers so that's expected.

[NSoiffer]

The overbrace should be treated as an accent. In MathML 3, it was listed as having the accent property. In MathML 4 we resolved to remove accent from the operator dictionary and make the default be accent="true" for all mo in the spec (#151).

Accents are not shrunk in size, so the width should be close to 100px, depending of course on the font and how the character is designed in it.

As far as I can tell this is resolved. @fred-wang: what do you think is still open about this?

[fred-wang]

As far as I can tell this is resolved. @fred-wang: what do you think is still open about this?

I already explained it in #76 (comment)

Currently cramped is only used in https://mathml-refresh.github.io/mathml-core/#ref-for-dfn-cramped-2 ; it has nothing to do with font-size. So I don't see why you are using #134 as an argument to close this issue.

During discussion in #151 I proposed to remove the accent property on the mo element, which would then have solved this issue. But the CG decided otherwise, so AFAIK this one is still open.

I'm happy to close this if the CG agrees we should depart from MathML3 (regarding scriptlevel depending on accent) and align more on what CSS/browsers allow (i.e. font-size resolution does not depend on the DOM -- besides what is in the UA stylesheet), and then remove the corresponding code from Gecko, but AFAIK we never reached consensus on that. The reason why I've left this opened so far is exactly because I didn't want to force this decision and in case someone find a way to preserve MathML3's behavior while still being aligned with CSS/browser design.

[fred-wang]

closing since mo@accent is no longer part of core and cramped is a CSS property.