[css-fonts-4] Managing the scaling of font-size within MathML rendering #5389

bkardell · 2020-08-03T20:08:27Z

(Part of #5384 - MathML Core related CSS)

Note: We're very interested in CSSWG feedback on this - it has already changed once based on feedback and tests updated, etc - and there has been some additional feedback that perhsaps this should be a single value instead which indicates that perhaps it should consult another (new property). We're ivery nterested to nail this one down better.

Script levels in MathML are about managing the font-size in subexpressions (like scripts and fractions). This example illustrates and describes some of the concepts/implications. The method for doing this is not quite as simple as inheriting, so the MathML-Core spec introduces a new scriptlevel() function (See example in the MathML Core spec )

Depending on context (exponents, fractions, etc) and particulars of rendering style (compact/inline), the font-size of of parts of expressions scale down at different and fairly well established rates - for example, the scaling factor adjustment of a superscript is not the same as that of a root's prescript. The example below shows several contextual scaling variations.

$rendering of An exponent with an exponent, a root with a prescript and a fraction containing another fraction$

The common rules derive from TexBook, but they are subtle and deserve to be exposed for tweaking and extension by authors. To this end, MathML adds a new scriptlevel function for CSS Fonts Module Level 4 which allows authors to express that the value should be automatically derived (default), or explicitly set to a specific level or that it should be the current level + some integer with rules defined in section 4.5 of the spec

Tests in https://github.com/web-platform-tests/wpt/tree/master/css/css-fonts/math-script-level-and-math-style

The text was updated successfully, but these errors were encountered:

faceless2 · 2020-08-04T10:40:51Z

We'd implemented the original math-script-level property while the core spec was evolving. For what it's worth, this proposal looks a lot better to me. An awful lot better.

Only one suggestion really - would it be an idea to reset the internal script-level to 0 if the font-size is specified as anything other than a scriptlevel() function?

I ask because, as specified, "the internal scriptlevel is 0 on the root element" - that's the root element of the document, not of the math equation?

If so, then my issue is that I can't reset the internal script level and change the font-size at the same time. And I don't see anything that limits the use of this to MathML element only.

<html style="font-size: 16px"> <!-- root element. script-level starts at 0 -->
 <div style="font-size: scriptlevel(1)">
  This text is 11.36px
  <div style="font-size: 16px">
   This text is 16px again, because the font-size was specified as a length, not a `scriptlevel()` function.
   <math>
    <mtext>This is still 16px</mtext>
    <munderover> <!-- user-agent stylesheet increments script-level of 2nd and 3rd children -->
     <mo>&#x220F;</mo>
     <mi>a</mi> <!-- I'd expected 11.36px, but it's actually 8px because scriptlevel is 2, not 1 -->
     <mi>b</mi>
    </munderover>
   </math>
  </div>
 </div>
</html>

I could get around this by adding font-size: scriptlevel(0) to the <math> element. But if I also wanted to set the font-size on the math element to something constant like 20px, I couldn't do both.

It's obviously not very likely, but having a property like internal-script-level that isn't visible to the user, that inherits all the way through the node hierarchy and that can't be reset without also resetting another property feels a little sketchy. The above would be a real pig for an author to debug.

I don't know how often a fixed font-size is used for internal elements in MathML - in our batch of testcases here, only once, within an <mtable>. Resetting the script-level to zero at that point looks reasonable to me.

In short, my only suggestion would be to

Reset the internal-script-level to 0 if font-size is set to anything other than a scriptlevel() function
Add math { font-size: scriptlevel(0) } to the MathML user-agent stylesheet.

The combination shuold ensure that a <math> element always starts with an internal-script-level of 0, whether the user specifies a font-size on the math element or not.

Alternatively, specify that the internal script-level is reset to 0 on a <math> element by some internal means unrelated to the font-size property.

fred-wang · 2020-08-23T12:44:21Z

@faceless2: Merging the scriptlevel property into font-size is known to cause these issues, it is not clear how to address them. This change was a tradeoff between the need of MathML and what integrates better into CSS, so let's see what the WG people say.

The point I'm currently more concerned about after this merge is that fantasai said introducing an "internal property" like we implemented in chromium is a bad idea. However, I still don't know how to make this work for absolute changes of scriptlevel otherwise (incidentally this is not needed for relative changes, which are the only ones required in the default UA sheet). I already asked her by email so we'll wait for her explanation before commenting further.

In any case my two cents:

Setting "math { font-size: scriptlevel(0) }" will scale up the font-size if the internal scriptlevel had been increased on ancestors (a different example from yours: a document with nested math tags). On the other hand, not setting it will make absolute changes like scriptlevel="0" wrong in this case. So I don't know whether there is a clear choice. But I also don't think these use cases are super important. Actually, I think the original proposal also had the same issue and was incorrectly trying to working around that via the "initial" value, see "initial" is not a legal specified value that can be checked mathml#154 (comment)
Resetting scriptlevel to 0 after font-size is also not perfect e.g. <math><mstyle scriptlevel="+1"><mstyle mathsize="16px"><mstyle scriptlevel="3", the third mstyle would scale down font-size by 0.71^3 instead of 0.71^2 according to MathML3. That said, when someone modifies the font-size within a math expression, the rendering will certainly look wrong in any case with a formula having inconsistent size of subexpressions, so I'm not sure we need to worry about the consequences (what happens with absolute scriptlevel, or scriptlevel and font-size set simultaneously on an element) or whether there is a strong preference. I think the only important case is when someone modifies the font-size on the math root... not sure why you have documents modifying the font-size on a <mtable>, probably in "normal" use cases, tables would either set to displaystyle="true" or just let potential automatic font-size increase happen.

faceless2 · 2020-08-23T14:39:05Z

If it's of interest, the test modifying font-size is at https://gist.github.com/faceless2/a592cb2b91c71cc7042f8a8df3b8b7ab

fantasai · 2020-09-10T04:03:46Z

Fwiw, I think my original concern was that the previous iteration of this feature--which used a separate property as the counter--depended on concepts that don't exist in CSS, like whether font-size has a specified value. (It always has a specified value.) Integration with font-size has to be defined in a way that can actually work; however, that doesn't mean necessarily that the entire feature needs to be encapsulated into the font-size property itself.

We could keep the depth counter as its own property, something like

math-depth: auto | add || <integer>
initial: 0
inherited: yes
computed value: integer

Then for

If the specified value font-size is of the form scriptlevel(...) then the computed value of font-size is obtained by multiplying the inherited value of font-size by a nonzero scale factor calculated by the following procedure ...
you could instead have something like

Option A: The used value of font-size is obtained by multiplying the computed font-size by a nonzero scale factor calculated by the following procedure [ insert MathML algorithm, with A=0 ] ...
Option B: If [ math-depth is nonzero | the specified font-size is math ] , the computed value of font-size is obtained by multiplying the inherited font-size by a nonzero scale factor calculated by the following procedure ...
Option C: If math-depth is nonzero, the computed value of font-size is obtained by multiplying what would have been the computed font-size by a nonzero scale factor calculated by the following procedure ...

Here's the side-effects of various options:

Option A: Here, the scale factor is inherited independently of the inherited font size, and they're combined at used-value time. This means that setting font-size to a value doesn't necessarily give you that value: it gives you that value multiplied by the effective scale factor tracked by math-depth. It means that font-relative length units are relative to the base font-size rather than to the effective one; you may or may not want this effect.
Option B: The math-depth calculation overrides the specified font-size. In the first sub-option (“if math-depth is nonzero”) this override is implied, and whatever the author specified on font-size is ignored. In the second (“if font-size is math”), this interaction is explicit; the author can't specify a conflicting value on font-size, since they have to specify the math keyword to explicitly defer the font-size calculation to math-depth.
Option C: In this case, the math scaling operates on the “raw” computed font-size: in most cases, this will be the inherited font-size (as in the previous option), but if the author specifies a font-size on the element, then that value will be used as the basis for scaling instead of the inherited value.

Option D: If you really want a declaration like font-size: <length> to reset the math-depth counter so that you get that absolute size, though, then font-size is essentially a shorthand for a depth counter property and a length tracker property -- your current spec is effectively doing this, but without real longhands for this font-size “shorthand”. I think it's a bit weird to have font-size (which is such a basic property) incorporate this separate concept of a depth counter into its computed value, but maybe it's okay... would definitely want to get the rest of the CSSWG's opinion on that, though.

I'll note that we're running into a similar need for a font-size scaling factor for drop caps, see #4988 ; it would be interesting to note what the similarities and differences are wrt expected behavior. (For example, in the drop caps case, we suspect that font-relative lengths should be unaffected by initial-letter’s scaling effects.)

fred-wang · 2020-09-10T05:17:27Z

Thanks @fantasai !

MathML3 says that an explicit font-size overrides the effect of scriptlevel change, so that excludes option A, B-1 and C.

Option B-2 looks more or less what MathML Core was trying to achieve in the orignal proposal. To make it work, MathML Core would only need to ensure font-size is set to math at least for the default UA stylesheet inheritance and when the scriptlevel attribute is used ; or maybe even on all MathML elements but the <math> root.

Additionally, using this explicit math keyword will allow authors to modify the math-depth without a font-size change as a side effect. In particular, the MathML UA stylesheet could do:

math {
  font-size: inherited;
  math-depth: 0;
}

to ensure the math-depth is 0 on the <math> root and so absolute values of scriptlevel are correctly interpreted.

About option D, I don't think that's necessary for the MathML use case. The reason why I tried to incorporate it into font-size was to simplify the proposal to make it more easily acceptable to the CSSWG but if people are happy with a separate math-depth counter, I wouldn't add more complexity.

fantasai · 2020-09-17T16:48:36Z

Probably 'auto' should have a different, less-confusing name. Maybe 'auto-add'? 'auto-compact'?

css-meeting-bot · 2020-09-17T16:49:45Z

The CSS Working Group just discussed Managing the scaling of font-size within MathML rendering, and agreed to the following:

RESOLVED to spec out the a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue 2b, and open smaller issues for other things

The full IRC log of that discussion

<astearns> topic: Managing the scaling of font-size within MathML rendering
<astearns> github: https://github.com//issues/5389
<fantasai> s/inhertied/inherited 'math-shift'/
<fantasai> s/value/values 'normal' and 'compact'/
<bkardell_> faceless2: fwiw, I think what is there is workable for us, but I don't know how anyone else does it... my question was about how it inherits through elements that aren't math
<fantasai> various options proposed in https://github.com//issues/5389#issuecomment-689965166
<bkardell_> fredw: fantasai has suggested several things at the end, I think they addressed the concerns you had with my initial proposal?
<fantasai> fred explains why one seems better in https://github.com//issues/5389#issuecomment-689989000
<bkardell_> fredw: it seems, imo to resolve all the issues
<bkardell_> faceless2: font-size inherit would probably resolve my worries, that's a good idea
<bkardell_> fredw: the original proposal was to have this counter - it was based on what firefox implements... we tried to modify the proposal to make it simpler, but that just caused more issues. fantasai suggested these -- b2) seems good to me
<emilio> q+
<bkardell_> fantasai: the problem with the original proposal was "if the font-size is not set explicitly" - which isn't a thing we can do. The proposal in the interim was things would be internal, but that causes the font-size property to be more complex than it is already which is bad. I think it makes more sense to keep the counter, and just have the font-size have a seperate keyword that just says "go look at that math-size value"
<bkardell_> fantasai: math-depth: auto adds 1 if the size is cramped and not otherwise...
<fantasai> probably should rename the 'auto' keyword
<bkardell_> fredw: it's not cramped it's math-style - when math-style is compact, the counter is incremented by 1. This is used to cover fractions
<bkardell_> fredw: if you check the example bkardell_ included at the beginning you can see the difference in them
<bkardell_> NeilS: there is that one weird fraction rule
<astearns> ack emilio
<bkardell_> emilio: I don't love the proposed solution because it adds a prop on which font-size depends, which is bad because so many things ultimately depends on font-size. I think that adds another pass on style resolution
<bkardell_> astearns: is it a second pass or just another check?
<bkardell_> astearns: it's only extra stuff you have to do if it is non-zero
<bkardell_> emilio: that might be doable... I will have to think about it... but it means that there is a state where you might have a wrong font size... I will have to think about it...
<bkardell_> emilio: it may be true that we can fix up the font size... I need to double check
<bkardell_> astearns: please double check because I agree that could be bad if it is hard
<bkardell_> fantasai: the other solution was worse?
<fantasai> s/was worse/is to keep the counter as part of the font-size property itself/
<bkardell_> emilio: I will have to go and check what ff does
<fantasai> s/itself/itself, are you thinking that's better??/
<bkardell_> emilio: we fix up the font size after the fact, right?
<bkardell_> fredw: I think the issue in gecko was we were supporting the min font size
<bkardell_> emilio: it might not be such a big issue as I thought it was
<bkardell_> fantasai: it should have no dependency on anything but itself
<bkardell_> emilio: ok, I am not very concerned then
<fantasai> oh, and I guess also dependency on 'math-style'...
<bkardell_> emilio: I will double check it, but I dont think we should block on resolving this actually... I like it better
<bkardell_> proposed: add a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue.
<bkardell_> fredw: it is not like this in any browser, but it isn't too hard to align them on this
<bkardell_> astearns: Let's resolve to get this in a spec and file separate issues on smaller things like 'should we rename the auto value'?
<fredw> this was where min-font-size was removed: https://github.com//issues/3739
<bkardell_> RESOLVED to spec out the a math keyword to font-size which refers to the new math-depth property to get the scaling factor, which acts as a depth counter as described in the issue 2b, and open smaller issues for other things

fred-wang · 2020-09-21T06:55:38Z

The proposal has been updated to use option B-2:
https://mathml-refresh.github.io/mathml-core/#the-math-script-level-property

This imports the proposal from MathML Core to manage font scaling in math formulas using a new 'math-level' property. This mechanism involves a new 'math-style' property that describes compactness of formulas as well as a new 'math' keyword to specify relative font-size change using the a scale factor calculated from the 'math-level' changes. w3c#5389 w3c#5387

Discussed with the CSSWG at [1]. Syntax changes are - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add The old tests math-script-level-001 and math-script-level-003 are restored and adjusted to check the computed math-level in various situations and that the math-level does not have any effect when the specified font-size is not 'math'. [1] w3c/csswg-drafts#5389

Experimental font-size: scriptlevel(...) syntax was implemented in [1]. This CL updates it to match what was agreed with the CSSWG [2] as well as new WPT tests [3]: - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add This CL also updates the MathML UA stylesheet to use the new syntax. To compute font-size, one need the inherited math-style and the inherited/computed math-depth. So math-style does not need to be High priority. Additionally Blink computes the High priority alphabetically, so math-depth must be handled specially. [1] https://chromium-review.googlesource.com/c/chromium/src/+/2184131 [2] w3c/csswg-drafts#5389 [3] web-platform-tests/wpt#25694 Bug: 6606, 1023292 Change-Id: I8a5bf245fa6158633261ed167800fc5feb0c3564 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2423843 Commit-Queue: Frédéric Wang <fwang@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Rob Buis <rbuis@igalia.com> Cr-Commit-Position: refs/heads/master@{#810610}

… syntax, a=testonly Automatic update from web-platform-tests Update math-level depth to match the new syntax (#25694) Discussed with the CSSWG at [1]. Syntax changes are - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add The old tests math-script-level-001 and math-script-level-003 are restored and adjusted to check the computed math-level in various situations and that the math-level does not have any effect when the specified font-size is not 'math'. [1] w3c/csswg-drafts#5389 -- wpt-commits: 9614b05463a96ce2cd496dc322ea558c3a3c7909 wpt-pr: 25694

… syntax, a=testonly Automatic update from web-platform-tests Update math-level depth to match the new syntax (#25694) Discussed with the CSSWG at [1]. Syntax changes are - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add The old tests math-script-level-001 and math-script-level-003 are restored and adjusted to check the computed math-level in various situations and that the math-level does not have any effect when the specified font-size is not 'math'. [1] w3c/csswg-drafts#5389 -- wpt-commits: 9614b05463a96ce2cd496dc322ea558c3a3c7909 wpt-pr: 25694 UltraBlame original commit: d32ea8a9512bde0359e35f69fe08d3d8d89f79dd

… syntax, a=testonly Automatic update from web-platform-tests Update math-level depth to match the new syntax (#25694) Discussed with the CSSWG at [1]. Syntax changes are - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add The old tests math-script-level-001 and math-script-level-003 are restored and adjusted to check the computed math-level in various situations and that the math-level does not have any effect when the specified font-size is not 'math'. [1] w3c/csswg-drafts#5389 -- wpt-commits: 9614b05463a96ce2cd496dc322ea558c3a3c7909 wpt-pr: 25694

svgeesus · 2021-06-09T17:09:35Z

Is the new math-depth property being added to MathML, to CSS Fonts 4, or someplace else?

svgeesus · 2021-11-17T15:46:10Z

@fred-wang @bkardell math-depth is going where?

svgeesus · 2021-12-03T18:04:07Z

Ah okay the proposed math-depth property is in MathML core but CSS Fonts 4 gets a new math value which references the value of this property.

fred-wang · 2022-01-18T11:08:43Z

@svgeesus: Sorry for missing your ping, I've been very busy with non-spec work in the past months.

That's a good question and it has also been confusing for me because I initially thought the idea was to add the new properties to the relevant CSS specs but @fantasai suggested to keep stuff in the MathML Core spec when I sent the PR #5536 (comment)

Anyway, I don't have strong preference on my side, I'm fine with "patching" the CSS spec in MathML Core for now. Since you already submitted 09efeb0 I can simplify that part in the MathML Core spec, though. Thanks!

Experimental font-size: scriptlevel(...) syntax was implemented in [1]. This CL updates it to match what was agreed with the CSSWG [2] as well as new WPT tests [3]: - Split scriptlevel(...) into math-depth: ... and font-size: math. - Rename auto to auto-add This CL also updates the MathML UA stylesheet to use the new syntax. To compute font-size, one need the inherited math-style and the inherited/computed math-depth. So math-style does not need to be High priority. Additionally Blink computes the High priority alphabetically, so math-depth must be handled specially. [1] https://chromium-review.googlesource.com/c/chromium/src/+/2184131 [2] w3c/csswg-drafts#5389 [3] web-platform-tests/wpt#25694 Bug: 6606, 1023292 Change-Id: I8a5bf245fa6158633261ed167800fc5feb0c3564 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2423843 Commit-Queue: Frédéric Wang <fwang@igalia.com> Reviewed-by: Rune Lillesveen <futhark@chromium.org> Reviewed-by: Rob Buis <rbuis@igalia.com> Cr-Commit-Position: refs/heads/master@{#810610} GitOrigin-RevId: 0feb1d195c8a413c53e808ed95df7e1b78089703

bkardell mentioned this issue Aug 3, 2020

[Meta] MathML Core related CSS #5384

Open

lcchueri mentioned this issue Aug 5, 2020

[css-lists] Consider new value for counter-reset #5402

Closed

tabatkins added the css-fonts-4 Current Work label Aug 19, 2020

fantasai added the Agenda+ label Aug 19, 2020

fred-wang mentioned this issue Aug 23, 2020

[css-fonts] Add new CSS properties math-script-level and math-style #3746

Closed

css-meeting-bot removed the Agenda+ label Sep 17, 2020

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Sep 17, 2020

fred-wang mentioned this issue Sep 21, 2020

[css-text] text-transform values for MathML #5386

Closed

fred-wang added a commit to w3c/mathml-core that referenced this issue Sep 21, 2020

Update proposal to match Option B-2 of w3c/csswg-drafts#5389

7a7eb14

fred-wang mentioned this issue Sep 22, 2020

[css-fonts] Add font-size: math, math-depth and math-style #5536

Closed

fred-wang mentioned this issue Sep 23, 2020

Update math-level depth to match the new syntax web-platform-tests/wpt#25694

Merged

svgeesus closed this as completed in 09efeb0 Dec 3, 2021

svgeesus removed the Needs Edits label Dec 3, 2021

This was referenced Jan 18, 2022

Consider integrating scriptlevel into font-size w3c/mathml-core#62

Closed

[math] math style (minimizing logical height of an equation) #5387

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-fonts-4] Managing the scaling of font-size within MathML rendering #5389

[css-fonts-4] Managing the scaling of font-size within MathML rendering #5389

bkardell commented Aug 3, 2020 •

edited

Loading

faceless2 commented Aug 4, 2020

fred-wang commented Aug 23, 2020 •

edited

Loading

faceless2 commented Aug 23, 2020

fantasai commented Sep 10, 2020 •

edited

Loading

fred-wang commented Sep 10, 2020

fantasai commented Sep 17, 2020

css-meeting-bot commented Sep 17, 2020

fred-wang commented Sep 21, 2020

svgeesus commented Jun 9, 2021

svgeesus commented Nov 17, 2021

svgeesus commented Dec 3, 2021 •

edited

Loading

fred-wang commented Jan 18, 2022

[css-fonts-4] Managing the scaling of font-size within MathML rendering #5389

[css-fonts-4] Managing the scaling of font-size within MathML rendering #5389

Comments

bkardell commented Aug 3, 2020 • edited Loading

faceless2 commented Aug 4, 2020

fred-wang commented Aug 23, 2020 • edited Loading

faceless2 commented Aug 23, 2020

fantasai commented Sep 10, 2020 • edited Loading

fred-wang commented Sep 10, 2020

fantasai commented Sep 17, 2020

css-meeting-bot commented Sep 17, 2020

fred-wang commented Sep 21, 2020

svgeesus commented Jun 9, 2021

svgeesus commented Nov 17, 2021

svgeesus commented Dec 3, 2021 • edited Loading

fred-wang commented Jan 18, 2022

bkardell commented Aug 3, 2020 •

edited

Loading

fred-wang commented Aug 23, 2020 •

edited

Loading

fantasai commented Sep 10, 2020 •

edited

Loading

svgeesus commented Dec 3, 2021 •

edited

Loading