Add scriptsizemultiplier to core

[NSoiffer]

MathML 3 defines scriptsizemultiplier. It can be used for many things, but one important thing it is used for is displaying math for people with low vision. With the standard shrinkage, scripts are hard to read and nested scripts and radical indices are especially difficult to read for people with vision issues.

The CG agreed to remove it and rely on an OpenType value, but we did not think about accessibility and so its exclusion from core should be reconsidered. The usage stats show it being used with a value of 0.85; that larger value (larger than the default of around 0.71) may well be for accessibility reasons.

[NSoiffer]

This was discussed at the Core meeting today.

My suggestion is that scriptsizemultiplier become a CSS attr (with default auto) so that it can be overridden.

@davidcarlisle suggested someone could write CSS rules on msub, msup, etc., that scaled the fontsize of the scripts (etc). You can do this for just first level scripts or with a little more complexity for second level scripts and that would catch almost every case that is not made up.

@bkardell pointed out that user settable style sheets have gone away. He thought a magnifying lens cursor (or similar) could be used to read scripts. This would be a browser extension, as could potentially some CSS modifications.

I did a little investigation as to current practice when people aren't using ZoomText or other similar AT:

• WAI suggests using [settings/options]/appearance in chrome/firefox to set a top level font size and override the page's defaults. There are also settings to adjust the color settings as those can be helpful for reading or just less tiring to read. That doesn't help for math scripts.
• Chromium.org additionally mentions that there are Chrome Extensions that give even more options. Silas Brown (a top hit in google) has a web page that talks about user CSS in Firefox and Chrome extension (which seem to be about overriding CSS values).

Based on this, there appears to be a workaround (a browser extension that implements @davidcarlisle's idea). It's a useful hack that mostly works, but it's not perfect.

Whatever is decided, we probably should contact WAI about adding suggestions for math accessibility to their user-facing pages.

[NSoiffer]

At the Nov 1 meeting, we agreed this is potentially important to accessibility. @NSoiffer will write some text in a note in the core spec with @bkardell @fred-wang to review it. The note should mention the accessibility angle and solicit input from relevant parties.

[fred-wang]

I know this is not for MathML Core Level 1, but just adding some old thoughts from last year (some of them discussed with @emilio on Mozilla's MathML matrix channel):

1. Adding yet-another CSS property on which font-size depends sucks, we should definitely avoid that.

2. It's now pretty easy for users to disable the font-size change caused by math-depth increase using font-size: inherit (alternatively, one can set math-deph: inherit). Put this on a selector like math > * > * > * to stop the increase at the third nested level of elements ; or do something more accurate with actual MathML tag names (probably like David Carlisle suggested above).

3. We could change the semantic of auto-add or add(<integer>) so it stops increasing automatically above a max value. Or better, extend the syntax of math-depth to allow max(add(<integer>), <integer>) and max(auto-add, <integer>) and get the same effect. I expect this to be a small change in the spec and in the CSS parsing/resolution.

4. math-depth is currently using <integer> types and default increase in mathml.css is 1 or 2. It would be straightforward for the CSS spec & implementers to switch to <number> types. Then users could reduce the default math-depth increase (e.g. set it to add(0.75)) so that the scaling down is slower. Extending math-depth to arbitrary decimal values gives the same power as allowing to change the default scale factor for font-size and arguably it's more natural to rely on the log scale (e.g. setting math-depth to 0.25 or 0.5) than the scale factor (e.g. taking fourth root and square root of the default scale factor). It also avoids to decide how to handle conflicts with the default values from the MATH table since the current rule will just apply. I guess the only argument against it is that decimal scriptlevel is "weird" but it's already possible to use negative or large integers that don't correspond at all to the nested math structure so...

I personally don't think adding scriptsizemultiplier is needed, plus it does not sound good to add (back) a MathML attribute for styling purpose. It's better to have the style in a CSS sheet than in the markup.

[dginev]

Re @fred-wang's comment

It's now pretty easy for users to disable the font-size change caused by math-depth increase using font-size: inherit

I am afraid it is also pretty easy for unsuspecting users to run into the issue and wonder what happened. I encountered it today with my continuing fraction example, illustrating HackMD's support for MathML:

https://hackmd.io/@dginev/BJhlco6cj

By default in today's Chrome, in the third and fourth nested <mfrac>, you can find token elements with font-size computed to (on my 27 inch display): 6.248px, 4.43608px, 3.14962px.

To my vision (which used to be excellent and is still "pretty good"), the 6 pixel font-size is just barely acceptable as legible. At the 4 and 3 pixel sizes I can not see anything, and I need to zoom the page to get anywhere. You can remove the <style> element just above the <math> of that page to reproduce my experience.

Would it make sense to pose a size limit on this scaling algorithm by default? In other words

"only scale down if the current size is above X pixels, otherwise inherit"

That would make continuing fractions usable by default, rather than "disappearing by default". Maybe another mechanism fits better?

[NSoiffer]

MathML Full has scriptminsize. This does precisely what @dginev is asking for. The spec says:

However, changes to the font size due to scriptlevel changes should never reduce the size below scriptminsize to prevent scripts becoming unreadably small. The default scriptsizemultiplier is approximately the square root of 1/2 whereas scriptminsize defaults to 8 points;

Looking through the issues, I see the 29/4/19 meeting says

scriptsizemultiplier, scriptminsize: remove them.

However, there is this 2019/03/19 comment by @fred-wang that says

the scriptminsize feature could probably be replaced with CSS's new font-min-size property. Note that this is not exactly the same, since scriptminsize is only supposed to affect the change due to scriptlevel, so we cannot just map to font-min-size. However, I believe it still addresses the use cases for which scriptminsize was introduced.

Unfortunately, that feature never made it into CSS: the basis for making the decision turns out to no longer be true. Hence, the issue should be reopened and the decision reconsidered. Perhaps there is another way to do it with CSS or perhaps we really should have scriptminsize.

[dginev]

Perhaps there is another way to do it with CSS

CSS indeed allows implementing variants of this - and adding one of them to the various browser "user agent stylesheets" could be a way to patch the short-term issue.

But I'm not sure if there is a CSS path to a standard mechanism? Can MathML Core mandate entries that MUST be in the UA stylesheet? Or is this a dead end?

Here's what I got to work by putting together several of Fred's and Neil's comments above:

:root {
  --scriptminsize: 10px;
  --scriptsizemultiplier: 0.75;
}

mfrac > * {
  font-size:max(
    var(--scriptminsize),
    var(--scriptsizemultiplier)*1em
  );
}

demo: https://codepen.io/dginev/pen/bGjxoRK

[Jamesernator]

Can MathML Core mandate entries that MUST be in the UA stylesheet? Or is this a dead end?

There is already a UA style sheet in the spec which is how basically all the MathML elements get styled by default.

I will note though I don't think any UA stylesheet includes any custom properties, and probably shouldn't given they might collide with user's own custom properties (and with CSS.registerProperty any properties may well be registered with incompatible syntax).