Consider integrating scriptlevel into font-size

[fred-wang]

cc @fantasai

Instead of having a separate math-level property, we could integrate it into font-size as a function.

[NSoiffer]

Could you be more explicit about what you are proposing. I suspect I know what you are getting at, but I could easily be thinking of something else and in either case, I don't know how you would integrate that into font-size without some sort of math-level value.

[fred-wang]

I think the proposal was to introduce new function values for font-size.

[fred-wang]

@rwlbuis has a first implementation of fantasai's proposal in Chromium. But this still needs to be formalized in the spec.

[fred-wang]

The spec has been updated to use an extension of font-size based on @fantasai 's suggestion and @rwlbuis 's implementation. We still need to review and update the tests.

[NSoiffer]

I don't see the proposed changes are valid CSS in either CSS Fonts Module Level 4 or the editor's draft of that WD. Where in the CSS process is @fantasai 's suggestion? Correct me if I'm wrong, but I think the other proposed extensions to CSS can be mapped to internal CSS properties if they don't get accepted by CSS in the near future. Since this uses an existing CSS property, is that approach feasible? If not, what's the fallback?

[fred-wang]

Some notes on the new approach based on fantasai's suggestion.

First although one cannot arbitrarily set the scriptlevel via CSS, it is still possible to nest two math tag so that the inner one has nonzero scriptlevel. Option (1) of w3c/mathml#154 (comment) is essentially chosen here.

Second, it is no longer possible to modify the font-size and scriptlevel at the same time on a given element. In particular:

• Specifying the font-size (via CSS or mathsize) cancels automatic scriptlevel e.g. in <math mathsize="12pt"><msup><mn>0</mn><mstyle mathsize="16pt"><mstyle scriptlevel="0"><mn>1</mn></mstyle></mstyle></msup></math> the 1 would have font-size 16pt while in the previous approach it was 16pt scaled up by the "script size multiplier". Note that in both cases it won't have had the initial 12pt font-size of the math root anyway like Bruce suggested in "initial" is not a legal specified value that can be checked mathml#154 (comment).

• Speciying a font-size cancels explicit scriptlevel change too e.g. in <math mathsize="16pt"><mstyle style="font-size: 12pt" scriptlevel="1"><mstyle scriptlevel="2"><mn>2</mn></mstyle></mstyle></math> the 2 would have font-size 12pt times the square of "script size multiplier" while it was 12pt * "script size multiplier" in the previous approach. Again, in both cases, it won't have had the initial 12pt font-size of the math root times the square of the "script size multiplier".

• When both mathsize and scriptlevel are specified <mstyle mathsize="12pt" scriptlevel="1">, the previous approach said that mathsize wins. As a consequence, this explicit scriptlevel change is ignored in that case too.

However, in the common use case where font-size is set uniformally for the whole formula (on the math tag, or inherited from an ancestor) then there is no behavior change. It is also fine to set font-size on element without children (e.g. token elements). If you really want to change the font-size of a subformula (which I guess will make your formula look bad anyway), you can always add another mrow level to prevent the font-size and scriptlevel from being modified at the same time.

Last but not least, her approach has big advantages to my opinion:

• This greatly simplifies the proposal. No new CSS property, just some new values to the existing font-size and how they affect the computed value. No need to discuss all the edge cases when both properties are specified, the order of resolution, used value, access via JavaScript, etc

• From the previous point, this will also reduce and facilitate the set of WPT tests that are needed to cover that new feature.

• This makes much easier to understand what's happening for users (at least those familiar with CSS, not those biased by MathML3). There is just one property that controls the font-size and no magic side effect by a math-specific property.

• This makes the implementation smaller, cleaner and more understandable, so more acceptable for reviewers, at least from the code I see written by Rob.

So I would lean toward that new approach, for these reasons, for consistency with the main goal of MathML Core (better integration with the rest of the Web Platform) and to increase our change to get this accepted by browser reviewers and the CSS WG.

[fred-wang]

I don't see the proposed changes are valid CSS in either CSS Fonts Module Level 4 or the editor's draft of that WD. Where in the CSS process is @fantasai 's suggestion?

This is referring to what she proposed during the breaking out session of the web engines hackfest last October. I'm not sure if we had taken minutes we can share with the group. I have some from Javi Fernandez but they are not very complete (on this point there is only "script-level issues: CSS should control the font's size"). Apparently Brian has notes that I'm mentioning in w3c/mathml#171 (comment) but not sure what they contain about this particular point.

In any case, I don't remember she said she would write/submit any proposal, she was just giving suggestions to improve ours... Well, I expect this work has to be made by the MathML CG :-) Also I would personally not send any proposal to the CSS WG again, until we have at least addressed all her feedback (basically w3c/mathml#154-#155 w3c/mathml#169-#174). Most of them are easy and I can take of it but her proposal to integrate scriptlevel into font-size was the biggest change which is why things have been stalled so far, until we can experiment this in Chromium.

Correct me if I'm wrong, but I think the other proposed extensions to CSS can be mapped to internal CSS properties if they don't get accepted by CSS in the near future. Since this uses an existing CSS property, is that approach feasible? If not, what's the fallback?

New properties can be defined as internal properties (this is what is done in Gecko) but when Rob tried the same in Chromium we noticed some limitations (e.g. AFAIK they cannot be specified in the UA sheet). I'm not even sure we tried that technique for this complicate thing that affects font-size. That said, new properties or extensions to existing properties can be developed under a runtime flag (which is what we are doing) and the Chromium reviewer for CSS was actually not very strict on approving these experimental things. So I guess that's fine for the short-term while MathML is still under a runtime flag.

For the long term, if the CSS WG does not accept our proposal and since the Chromium reviewers would prefer to avoid "hiding the MathML magic", we basically cannot implement something like scriptlevel that affects font-size. That's why I'd try to be flexible and prefer addressing the feedback over finding perfect compability with MathML3.

[fred-wang]

The spec & tests now follow fantasai's suggestion ; and this has been implemented in Chromium upstream, so closing.

[fantasai]

Wow. So, uh, I think you and I did not understand each other very well here. Definitely, I would not have advocated hiding a counter in the computed value of font-size. My suggestion was more that font-size should have a value that does an appropriate lookup. But not be a depth counter.

(Also if you want to get my attention, I suggest email or IRC or even Twitter. GH notifications get buried in the vast amounts of GH notifications, I basically never see them.)

[fantasai]

Also if you want to change how a core property like font-size works, you should really really get the CSSWG to review what you're doing before you do it.

[fred-wang]

Wow. So, uh, I think you and I did not understand each other very well here. Definitely, I would not have advocated hiding a counter in the computed value of font-size. My suggestion was more that font-size should have a value that does an appropriate lookup. But not be a depth counter.

Sorry for the misunderstanding. Seeing the glass half-full, I think the new proposal is much closer to what you had in mind and contains the necessary simplification that makes integration in font-size possible. Now, I agree it would be straightforward to calculate the new font-size without counter for relative changes scriptlevel(auto) and scriptlevel(add(<integer>))...

But I'm not sure how you mean to do that for the absolute change scriptlevel(<integer>)? This case is not important for the UA sheet but at least some people use scriptlevel(0) and scriptlevel(1) in order to implement TeX's \scriptstyle and \scriptscriptstyle and I'm sure others in the CG will say that all scriptlevel(N) are important since this corresponds to MathML3's scriptlevel="N".

(Also if you want to get my attention, I suggest email or IRC or even Twitter. GH notifications get buried in the vast amounts of GH notifications, I basically never see them.)

I'm commenting here so that the rest of the CG is aware but yes, let's follow-up later on this.

Also if you want to change how a core property like font-size works, you should really really get the CSSWG to review what you're doing before you do it.

Agreed and the plan is definitely to open new issues in the CSS WG tracker and put math items on the agenda for review. Last year my colleagues suggested to write small explainers for new CSS features and submit them to the CSS WG tracker for review, which is what I optimistically did. But the feedback was unfortunately not very constructive, with people basically arguing about the usefulness of MathML rather than on the actual technical problems we were trying to address. However, after a long effort on the MathML Core spec, test and implementation side we believe we are close to be able to give another try. But there are still a few things to refine first before...

[fred-wang]

This is done as agreed in w3c/csswg-drafts#5389 so I think we can close it. We can simplify a bit further after w3c/csswg-drafts@09efeb0 though.